http://qs321.pair.com?node_id=1226401


in reply to Re^7: How to write testable command line script?
in thread How to write testable command line script?

I appreciate your input, and I generally agree my representation is not optimal for extension, but I want to clarify what my algorithm does, because this is not a correct understanding of the representation.

The algorithm is based on complement arithmetic, which is why I didn't give it too much thought. The Japanese soroban is based upon it; ie. When subtracting 2 - 8, you add the complement of 8, in base 10 is 2, because 2+8 = 10. The problem of 2-8 becomes (2+2)-10 = -6. In base 60, we would add the complement of 60 and subtract a 1 from the column on the left, until we get to the degrees, which are in decimal format.

For the very reasons you outlined (Perl's representation of small negatives), I represent -0.1 as an equivalent polynomial (-1 + 9/10), or in this case 0 -1 0 as (-1 + 59/60 + 0), with the denominator implied as (-1 59 0).

Algebraically, a + (-a) = 0. If (0 -1 0) + (0 1 0) = (0 0 0), then we must treat -1 59 0 as equivalent to 0 -1 0, because (-1 59 0) + (0 1 0) = (-1 60 0) = (0 0 0).

Replies are listed 'Best First'.
Re^9: How to write testable command line script?
by pryrt (Abbot) on Nov 27, 2018 at 14:27 UTC

    Okay, I understand better where you're coming from. For an internal representation, that's fine.

    However, don't expect users to work in that same system for input and output: in my experience, people thinking in terms of DMS will usually be thinking in terms of London's longitude as -0°7′39″ = -(0°7′39″), not as = (-1°) + 52′ + 21″. If your program outputted -1 52 21, someone looking at a map of England would be forgiven for assuming you were printing the longitude of (... /me searches a map for an example location...) slightly west of Swindon, not the longitude of London -- and if I entered -1 52 21, I would expect your program to interpret that as being near Swindon, not London.

    For internals, I'm now in agreement with AnomalousMonk's post, where it was recommended to do everything internally as arc-seconds. I now like a that a lot more than doing everything in decimal degrees: the fractions 1/60 and 1/3600 don't get represented well in internal binary floating-point notation, whereas -459 arc-seconds is stored quite simply as an integer; this also makes the internal angle representation more like the time representation (seconds since the epoch); I also think that would make all the internal math much simpler.