by Michael S. Kaplan, published on 2008/02/19 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/02/19/7785815.aspx
Somewhere in between zero and the smallest possible negative number there lies another number.
NEGATIVE ZERO.
I am being facetious here; it is not a number that is any different than zero. In the end,
0 == -0
as just about any normal person in the world will tell you (I learned it in the first day I learned about negative numbers, myself). It has as much meaning as +0 does, in the end. Either way, it is still zero.
But that doesn't stop programmatic folk from coming up with explanations in the BCL Team blog like Decimal Negative Zero Representation, "by design" issues such as In VS2005 C++, Zero reported as negative zero for double type and bugs like Math functions make a distinction between 0 and -0.
We even had an issue in collation, believe it or not!
You see, when people are not using the whole sort digits like numbers functionality brought to you by the StrCmpLogicalW function, then digits and all of the rest of the numbers in Unicode have to get sorted as text.
Conceptually it makes total sense to sort all of the values -- so that ⓴ (U+24f4, aka NEGATIVE CIRCLED NUMBER TWENTY) comes first and then all of the other numbers greater than that like 8 (U+0038, aka DIGIT EIGHT) until at the far end you have ∞ (U+221e, aka INFINITY). And that is how it works in collation -- with numbers that have the same digit values, like
given the same primary weight but alternate other weights, in some kind of weird attempt to give them some kind of numerosoity kind of thing.
But then there is ⓿ (U+24ff, aka NEGATIVE CIRCLED DIGIT ZERO).
It was obviously kind of zeroish. Like 0 (U+0030, aka DIGIT ZERO). But the special extra weight slot for circled digits was already taken up by ⓪ (U+24ea, aka CIRCLED DIGIT ZERO).
Uh oh, what to do?
So in the end, in Vista, because of the notion that -0 somehow (conceptually) needs to come before 0, the weights for the ASCII digits were all incremented a bit so there would be room for NEGATIVE ZERO while still giving the digits consistent weights.
This, as it turns out, was not such a great idea, since it increased the size of sort keys that contain innocent items in them like GUIDs. So in Server 2008 it gets stuck somewhere after 0 (U+0030, aka DIGIT ZERO), where there is lots of room for zero-ish things like this.
This (and a handful of other bugs like this one, only fixed in Server 2008 as I explained here) is why Server 2008 has an updated major sorting version.
All because there was no room in the weights to make -0 < 0!
So in the end, in the real world -0 == 0, in Vista -0 < 0, and in Windows Server 2008 -0 ≮ 0!
This post brought to you by ⓿ (U+24ff, aka NEGATIVE CIRCLED DIGIT ZERO)
Someone on 19 Feb 2008 1:20 PM:
The notion of "minus zero" is quite normal in computers. See for instance <http://en.wikipedia.org/wiki/−0_%28number%29> and <http://www.fourmilab.ch/documents/univac/minuszero.html>
Nitpick:
"Somewhere in between zero and the smallest possible negative number there lies another number"
1) that should be "…and the _largest_ possible negative number".
2) even that is not really true if, as you imply by naming this "negative zero", you consider "minus zero" a negative number.
John Cowan on 19 Feb 2008 2:15 PM:
Man, this is beyond stupid.
The NEGATIVE in the Unicode digits means negative as in photographic negative; they are displayed with white digits on black circles, and certainly they shouldn't have negative numeric values -- and indeed in UnicodeData they don't. So that's just a bug.
As for floating-point -0.0, that is in one sense less than +0.0, because it means "any negative value larger than -FLOAT_MIN" just as +0.0 means "zero, or any positive value less than +FLOAT_MIN". But in another sense, of course, -0.0 = +0.0 = 0. Such is the price of trying to do real arithmetic with inexact numbers.
Dean Harding on 19 Feb 2008 5:42 PM:
"Man, this is beyond stupid."
Dude, lighten up. I'm quite sure Michael knows the difference between negative numbers and photographic negatives. He was just trying to add a bit of spice to the post. Nowhere did he say they had "negative numeric values", so where's the bug, exactly?
Michael S. Kaplan on 19 Feb 2008 6:38 PM:
I suppose I should count myself as lucky that whole "when they are text this is all kind of arbitrary", huh :-)
Good info for a bug report, in any case. Thanks!
John Cowan on 4 Mar 2008 1:23 PM:
Dean Harding:
Michael knows I mean no offense.
In any case, he is saying that in the wonderful world of Microsoft, NEGATIVE CIRCLED NUMBER TWENTY sorts before DIGIT ZERO, which can only reflect someone's mistaken belief that it is a circled -20. It should sort the same as CIRCLED NUMBER TWENTY.
Michael S. Kaplan on 5 Mar 2008 11:14 AM:
In the end, there is a bug here. Though like I said I guess we're lucky about the arbitrary collation rules of symbols....
To that I would add what a bad idea it is to be negative. :-)
referenced by