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).

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.

Ah. I think I understand now. Thanks for catching my error. I have no idea why I didn't consider that initially. Back to the drawing board.

Edit: What do you think the best way of representing the degree:min:sec is? I am leaning to simply converting everything to seconds, doing the arithmetic, and then converting to deg:min:sec format as Anomalous Monk did. I planned on extending the calculator to accept decimals anyway. But if I wanted to accept integer input, what would be the best way of representing this situation of small negatives?

If you want to avoid "-0", my order of prefence would be: 1) store it as decimal; 2) store it as [$sign, $deg, $min, $sec] where all four are integers, with sign taking on -1 for negative angles; 3) store it as [$deg, $min, $sec, $sign] (but I don't like that order as much).

For accepting integer input, I'd just only allow sign on the degrees... so if you wanted to allow "-0 1 0", that would be interpreted as -1min. Since "input" implies "text" in my mind, you can just check for (and strip) the sign using text processing, and then re-apply the sign once you are done:

$input = "-0 1 0"; 
my $sign = ($input =~ /^\s*-/) ? -1 : 1; 
my ($d,$m,$s) = map abs, split / /, $input; 
my $decdegrees = $sign * ($d + $m/60 + $s/3600);
print $decdegrees
[download]

... or maybe ...

$input = "-0 1 0"; 
my ($sign, $d, $m, $s) = ($input =~ /(-{0,1})(\d+)\s+(\d+)\s+(\d+)/); 
my $decdegrees = (($sign)?-1:1) * ($d + $m/60 + $s/3600); 
print $decdegrees
[download]

.

update: fix missing code tags