(That having been said, representing negative integers with infinite 9s to the left is fun and natural, not contrived to this task. Every other value of the form x/10^n for integer x and n has two decimal representations (and vice versa), and in particular, every positive integer x has two decimal representations (and vice versa) with integer components x and x - 1, so why not continue this pattern through 0 and the negatives? It’s standard notation that is disjointed in its treatment of the crossover from positive to negative…)
[Which is not to deny that standard notation (directly representing only semipositive values, and tacking on a separate sign bit to disjunctively handle negatives) is A) standard, and B) natural and useful for its own purposes. Just, uh, continuing the joke into “Haha, but seriously…” territory, I guess.]
Since we’re just speaking of decimal notation, it seems simplest to extend the non-negatives to the reals by prepending a {+,-} sign. In this way, two representations of zero arise automatically.
[off-topic from the trivia desk]
The earliest CDC6600 functions to save/restore registers were found to be buggy: the programmer expected instructions like
SX6 B1 // compiles to SX6 B1**+B0 (B0 is always zero)
to copy B1. In fact, however it replaced negative zero with positive zero. Some manager’s perverse hatred of negative zero had prevented the obvious workaround
SX6 B1 // should compile to SX6 B1-**B0
Wau
Huh!
What is it good fau?
Even more off topic…
In the early 1970s I was using the PLATO system at the University of Illinois, one of the earliest Computer Assisted Instruction systems. Passwords were up to 10 characters, stored in a 60-bit word (6 bits per character). The “root” password that protected system resources was actually well known, but was considered safe because it contained some invalid characters, so it couldn’t be typed in.
To validate a password, the system did an XOR (or you can think of it a subtract if you don’t know XOR) of the typed-in password with the stored password, and if the result was zero, the password was assumed to match. But someone discovered that, since this was a 1s complement machine, typing in the bitwise complement of the actual password would also work, because the XOR of the actual password with its bitwise complement resulted in negative zero, which was equal to zero as far as the machine was concerned. There was a quick scramble to patch this hole when it was discovered.
Absolutely nothing!
No wait, that’s zero, not one…