Category: Musings

Here’s another puzzle that had me occupied all of my bike ride home yesterday:

While stopped at an intersection, I noticed how the windows on the building across the street allowed me to see oncoming traffic from the side from farther away than I had turned my head.  And so I wondered, what relation and how much of a reduction in neck strain does such a situation promote?

Clearly you need to turn your head only b degrees instead of a degrees, but that relationship can be anywhere from a negligible difference when the target is right against the mirror to a near complete reduction if the mirror was at infinity.  What’s the actual relationship though?

The target is at some x and y position away from us the viewer, and in the case of a building where the reflection is always ideally positioned, it only matters the y’ distance of the building from the target (the image will be the same distance behind the mirror).

With all of three of these values, we can find the angle of the triangles formed in the diagram by arctan(y/x) and arctan((y+2y’)/x).

The angle I must turn to look at a car then is (90º – arctan(y/x)), while I only need to turn (90º – arctan((y+2y’)/x)).

Wolfram alpha can help us with the rest of the work here in visualizing this relationship, and we can choose to look at all three as variables or arbitrarily set certain one’s as constants.

For example, if we are interested in how the ratio of the reduction behaves as a function of the distance of the mirror, see the following graph.  The ratio of the image in the mirror angle to the object angle is y and the distance of the mirror from the object is x in this case.  (as expected, mirror farther away means you have to turn your head less)

Or, if we are interested in how the ratio of the reduction behaves as a function of the x position of the object (the farther away it is, the closer the angle is between the mirror image and it):

Or we can vary both the position of the object and the mirror at the same time (reflected in the top right quadrant of the below graph since both values can only be positive):

ADDITIONAL:

By the way, if you were wondering about the ideal positioning of a mirror to see an object at your side, the relationship is governed by (y+y’)/(x-x’) = y’ / x’ where x and y are the position of the desired target object to your side and x’ and y’ are the position of the mirror relative to that object.

x’ and y’ have an expected asymptotic relationship where they start right on top of the target to halfway between you and the target in x while infinitely far away in y. Per Wolfram Alpha below (setting y=1 and x=2).

Here’s a question that I’ve wondered about:  What’s actually a safe load to put on paracord in case of it slipping and dynamic loading?  Paracord should be a shock cord since it was originally for parachutes, but it’s always rated by a static load weight.

Here’s the best I’ve gathered (internet, please correct me if any of this is wrong):

An approximate equation for shock load is:  shock load = weight * ((fall distance / elongation) + 1)

Properly rated paracord should elongate at minimum 30% (more is better so let’s use 30% as a worst case).

If are you dropping something with the cord, the fall distance is the cord length or 100%.  The equation reduces to weight * (1/0.3 + 1) or weight * (13/3).  A weight being dropped on paracord can generate a shock force of about 4.333 times it’s weight.

So going in reverse, if we take the static load of paracord as it’s net breaking strength, do not load it with more than the inverse of that factor in weight, 3/13 or 23% of it’s rated strength.

Inverse kinematics today.

So here’s another random geometrical situation that caught my attention while I had some downtime at work today.

Imagine we have two monitors that we would like to pivot so that they always stay in contact; however, we don’t want to install and ugly hinge along the front surfaces so we build an arm attachment in the back.  Of course, it can’t be one arm because that doesn’t physically work, but two arms hinged to each other and to the monitors will.  This raises interesting questions about how the arms need to move together to pivot the screens, especially if we would like the system to be automatically driven and move at an even and smooth speed.

I haven’t yet figured out all the equations and differentials that govern the relative movements of the arms, but some quick thought on the ideal case can get us in the right direction.  Imagining a perfectly equilateral triangle setup, and also ignoring the thickness of the screens, we see that every 3° rotated by the screen requires a 1° rotation on each internal angle of the hinges.  Twisting each hinge at a fixed speed will result in the screen pivoting at 3 times that speed.

Of course, this becomes less true as the arm lengths vary: an armature with a √2 ratio with the short arm being the length of the distance between the two screen hinges (starts off in a 90°, 45°, 45° triangle) will not be able to rotate the screens to a full 90°.  But to get to a 45° angle, must rotate ~27.0°, ~4.4°, ~22.3° respectively.

Or, think of an armature that can just get to a 90° screen rotation by having a long arm that is the distance between the two screen hinges and a short arm that is 1/√2 times that.  It starts off in a ~69.3°, ~69.3°, ~41.4° triangle, rotating ~24.3°, ~24.3°, 41.4° respectively.

Of course, the correct way to do this is clearly just to build the darn setup, manually rotate the screens, have sensors record the movement, and then feed those movement curves back into the motors.

If you’re spreadsheet is meant to be looked at by other people, you should just about nest everything in an IFERROR([formula],).  The nothing after the comma means that in the case that your formula throws an error (#VALUE, #N/A, #REF!, et cetera), nothing shows up in the cell.  No distracting error text.

Now, this doesn’t mean you shouldn’t debug your formulas first, but if there are normal cases where they might throw some of these errors, IFERROR() is invaluable.  (e.g. I have a dynamically updating query list and I know that sometimes the query will return nothing).

I’ve been working on a self-updating bi-weekly deliverables calendar / dashboard in Google Spreadsheets for my office the past few days.  Our Traffic Manager can simply add projects and their various deliverables to other sheets which serve as databases. Then another sheet, which one of our animator a painstakingly organized for aesthetics, will search those databases to pull deliveries to their correct dates and color-coding based on other information associated with those projects.  This sheet updates itself based on the current day and week.

Recently, a switch I made from INDEX(FILTER(SORT(…))) to INDEX(QUERY(…)) for minimization purposes resulted in some peculiar behavior.

But first a preface as to why I am using INDEX for array formulas that are perfectly capable of expanding themselves down multiple rows.  Our animator has used the spreadsheet as a grid to help align elements, merging some cells and leaving some as borders.  This means that the cells no longer behave like a sequential spreadsheet.  For example, merged cells behave as only their top left cell.  Net result is that I need to write a specific formula for each identified locus of data.  Somewhat more time-consuming but not un-doable.

Anyway, so I was using INDEX() to return whole rows from my QUERY() via INDEX(QUERY([array], “select Col[#],Col[#] where …”),1).  This worked fine when the QUERY() pulled more than one row; however, when the QUERY() only pulled a single row, INDEX() only pulled the first entry where I wanted the whole first row, and where it would have pulled the non-existent second r0w, it pulled the single entry from the second column.

I cannot confirm my suspicion, but I surmise that QUERY(), as written by the programmer returns a one dimensional array when there is only one row of results and a two dimensional array when there are more.  This inconsistency means that INDEX(), when passed only a single number, pulls that index from an array, resulting in a single element from a one-dimensional array, and a whole row (or sub-array) in a two-dimensional array.

Unfortunately, to a naive user on the front-end who expects that number of their INDEX() function to always refer to a row, this is confusing and un-beneficial. I have not figured out how to solve this problem yet, and instead have broken up my QUERY() to multiple ones that only query single columns, thus guaranteeing that the dimensions of returned arrays are always 1xN.  It has maximized rather than minimized my formulas, but is more robust for the time being.