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