2017-01-26 21:22 GMT+01:00 Martin McClure <[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...
