Hi,
i wonder what is the reasoning that "Float nan sign" returns anything
else than Float nan?
werner
On 01/26/2017 09:47 PM, Nicolas Cellier wrote:
2017-01-26 21:22 GMT+01:00 Martin McClure <[email protected]
<mailto:[email protected]>>:
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...
