2017-01-26 21:22 GMT+01:00 Martin McClure <martin@hand2mouse.com>:
Pharo's implementation of Float>>sign is very odd, and rather disturbing.
It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct.
Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do.
OK, I think you are right
The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN).
The current implementation of #sign is
self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0
I'd propose factoring this into two simpler methods:
sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0
maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too?
isSignMinus ^((self at: 1) bitShift: -31) = 1
Which would restore symmetry, as well as conforming to all the relevant specs.
-Martin
Or just
signBit ^(self at: 1) bitShift: -31) That means that we'd have to refactor most (all?) senders of sign...