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. 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 isSignMinus ^((self at: 1) bitShift: -31) = 1 Which would restore symmetry, as well as conforming to all the relevant specs. -Martin
