I have written about this tool four times: the geometry that makes it possible, three occasions when the physics contradicted what I was building, what it does and does not do, and a working compass that pointed south.
This one is shorter and more embarrassing than any of those.
Eighty one square kilometres, no address
The recurring argument of this blog is systems that return a well formed answer that happens to be false. I went looking for usability problems and found something worse than a false answer, which is a true one the program declines to say out loud.
The panel reported this:
11.2 x 9.2 km SEARCH ELLIPSE
81 km2 AREA TO WALK
And nowhere, in any section, a position. Not a latitude. Not a longitude. Not a bearing from anywhere to anything. The whole output of this program is a place on the ground, and the only way to find that place was to squint at a rotating three dimensional globe and guess.
The worst part is that it already knew. Every impact point was being computed, converted to latitude and longitude, and handed to the renderer to draw as a dot. The numbers existed, passed through a function that returned them in degrees, and were then used exclusively to colour some pixels.
The digits are a claim, and I nearly made a false one
Writing the coordinate out took ten minutes. Deciding how many figures to print took considerably longer, and it is the part worth the post.
A degree of latitude is about 111 kilometres. So six decimal places is a tenth of a metre.
Printing 47.651051, -91.304043 next to an ellipse eleven kilometres long states a position five orders of magnitude more precisely than anything that produced it. It is not a lie exactly. Every one of those digits really did come out of the arithmetic. It is worse than a lie, because there is nothing on the screen to tell a reader that the last four digits are noise, and the number looks exactly like a surveyed point.
So the figure count is derived from the size of the search area rather than from what a float happens to hold. One step of the last digit is one percent of the span:
| Search area | Printed as | Step |
|---|---|---|
| 300 m | 47.68931, -91.50214 | 1.1 m |
| 3 km | 47.6893, -91.5021 | 11 m |
| 11.2 km | 47.689, -91.502 | 111 m |
| 300 km | 47.69, -91.50 | 1.1 km |
The number of digits is itself a measurement. A reader who knows nothing about the tool can see that a coarse answer is coarse.
I tried a tenth of a percent first, which sounds more careful and is useless: it gives four decimals to everything from a three hundred metre field to an eighty kilometre one, so the digits stop carrying information and become a tenth of a metre wearing a disguise. The ladder is also required to be monotonic, because a larger search area earning more digits would be the same failure the scoring code exists to prevent.
Two smaller decisions in the same block.
The link is a geo: URI and not a maps website, because the coordinates are inside the link. A maps application with offline tiles opens the right place with no signal at all, which is the only condition this ever gets used in. And a position that is not a real number returns no link rather than a broken one, because a link that opens at zero, zero is worse than no link. Null island looks like an answer.
The coordinate is where to start, not where the rock is. The strewn field is a line, not a point: on the worked example the ten kilogram fragments land 14.6 km downrange and the ten gram ones 3.4 km. One pair of numbers cannot be the answer, and the caption says so rather than letting the big green box imply otherwise.
The second observation could not travel
The same pass turned up a gap of the same shape. This method needs two ground stations. Nothing in the program had ever moved one between phones.
Two people standing in two fields at two in the morning were expected to read eight numbers down a phone and retype them in the dark. That is the single most likely place in the entire workflow for a digit to move, the least likely place for anyone to notice, and it had no code in it whatsoever.
A station is now a link, 112 characters, which fits in a text message.
Three rules, and the middle one is the one that matters.
The link carries measurements and never the answer. Angles, a position, a duration. No entry point, no strewn field, no impact. The receiving phone works it out again. A link carrying the solved answer would be asking somebody to trust a figure another device produced, in a program whose entire argument is that a well formed number proves nothing. There is a test asserting the exact set of fields, so nobody can add one without the test naming it.
A magnetic bearing stays magnetic across the link. This is the compass bug from the last post, wearing a new hat. A phone compass reads magnetic north, and the correction to true north is a local number this program does not carry, so an uncorrected capture is labelled magnetic. If that label did not travel, Station A would receive Station B's magnetic azimuths and read them as true. The error is under a degree in some places and over twenty in others, which is the difference between the right field and the next county. So the reference is required rather than defaulted, because neither default is safe: assume true and an uncorrected capture is read as corrected, assume magnetic and the correction gets applied twice.
The sender states it and the program does not guess, because it cannot. A typed azimuth is whatever the person meant. A pointed one is magnetic only when no declination was set.
A link a messaging application cut short is refused rather than solved. This is the failure I expect to actually happen. Applications wrap and break long URLs, and a truncated link still parses perfectly well as a plausible observation with a smaller elevation. The checksum catches every truncation tested and all twenty seven single digit substitutions, one at a time, across every value in the link.
And then I shipped the same bug again, within the hour
Field mode strips the page down for standing outside. It hides every explanatory paragraph, which is most of the remaining length.
I gave the new sharing control a feedback line, and I gave it the same CSS class as the explanatory paragraphs.
It passed the first check, which is the interesting part. The element does not exist until you press the button, so it was not there when the hiding ran and it escaped. It only fails on the second render, and the effect re-runs whenever the solve recomputes, which is any keystroke in any field. Measured before and after editing one altitude: visible, then gone.
So in field mode you pressed Send, saw a confirmation, adjusted a number and watched the confirmation disappear. And the refusal message shares that element, which means a link the program declined to build could have reported nothing at all. A silent failure, in the feature I had just written to prevent silent failures, inside the program whose whole subject is silent failures.
The rule was already written in a comment four lines above the bug: the verdict boxes stay, because those are results and not explanations. I had simply put a result in the prose bucket.
While fixing it I also made a refusal look like a refusal. Both messages had been sharing one colour, so "Copied, send it to the other observer" and "refusing to build a link" read identically at a glance.
The part that has not moved
Same as last time.
The suite is now a bit over sixteen hundred assertions and it checks the code against physics. That remains necessary and insufficient. The list of real recovered falls to validate against is still empty, deliberately, because filling it from memory would compute a figure of merit from invented inputs and that would look exactly like a validation.
What today added is not accuracy. The answer is no better than it was yesterday. It is just finally written down somewhere a person standing in a field can read it, to a number of digits that does not lie about how well anyone knows it.