2017-01-27 0:15 GMT+01:00 Martin McClure <mar...@hand2mouse.com>: > On 01/26/2017 12:47 PM, Nicolas Cellier wrote: > > > > > > 2017-01-26 21:22 GMT+01:00 Martin McClure <mar...@hand2mouse.com > > <mailto:mar...@hand2mouse.com>>: > > [...] > > > 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? > > This addition makes sense to me. > > The standards help a *little* and suggest on alternative. > > ANSI Smalltalk acts like NaNs don't exist (basically, it lets > implementers do what they want for those values). > > ANSI Smalltalk relies on ISO/IEC 10967 of 1994 for numerics (even when > it *cannot* rely on 10967, it does, sigh). That spec only defines a > "sign" operation for floats with a definite numeric value, and says that > operations are *permitted* to accept infinities and NaNs, but does not > require this, nor say what the answer should be. > > The 2007 update of 10967 is somewhat more helpful. It replaces the > "sign" operation with one called "signum" which returns 1, -1, or NaN. > It returns 1 for positive zero and positive infinity, and -1 for > negative zero and negative infinity. If given a qNaN, it returns a qNaN. > If given a signaling NaN, it returns a qNaN but notifies the application > of an "invalid" situation. > > If we extend this to Smalltalk, I *think* this would have us answer qNaN > for qNaN, and for a sNaN signal a resumable exception (a Notification, > perhaps?) that if resumed would answer qNaN. This also seems to make > some sense -- NaNs are supposed to propagate, and asking the just plain > "sign" (as opposed to signBit or isSignMinus) of a NaN is more or less > nonsense. But if you prefer (-1 raisedTo: self signBit) I won't complain. > > I'm OK with answering NaN, it was just a question. An incomplete specification is an open door to useless differences
> > > > That means that we'd have to refactor most (all?) senders of sign... > > > > Certainly should audit senders of sign, but I'd expect that most senders > don't really care about what the sign of -0.0 or NaNs are. The answer > would remain the same for all other receivers. > > Regards, > > -Martin > > -0.0 sign is answering -1 at least since 1998, so we might have get used to it ;) I've done the job on Squeak trunk, the answer is we need to revise some senders....
