On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier < [email protected]> wrote:
> > > 2017-01-27 0:15 GMT+01:00 Martin McClure <[email protected]>: > >> On 01/26/2017 12:47 PM, Nicolas Cellier wrote: >> > >> > >> > 2017-01-26 21:22 GMT+01:00 Martin McClure <[email protected] >> > <mailto:[email protected]>>: >> >> [...] >> >> > 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.... > For reference here are the Squeak changes. http://forum.world.st/The-Trunk-Kernel-nice-1054-mcz-td4931787.html http://forum.world.st/The-Trunk-KernelTests-nice-317-mcz-td4931795.html What is the next step for Pharo? cheers -ben
