At Stef's request, I've opened case 19629 on this issue. On 01/27/2017 11:14 PM, Andres Valloud wrote:
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.
That's ISO 10967. However, IEEE-758-2008 specifies implementations shall provide isSignMinus(x). This operation is true if and only if x has negative sign, and applies to zeros and NaNs.
IMO, values that operate according to IEEE-758-2008 should behave as specified by IEEE-758-2008 by default. The ISO 10967 standard seems more of a layer on top of things like IEEE-758-2008, because it's a standard for language agnostic arithmetic.
So, shouldn't #sign behave as in IEEE-758-2008?
^self isSignMinus ifTrue: [-1] ifFalse: [1]
I think that defining #sign this way would add to the confusion. IEEE-754 does not define a "sign" operation. ANSI Smalltalk and ISO/IEC 10967 do, so it makes sense to provide a #sign that conforms to those standards -- answering -1, 0, or 1. IEEE-754 does define an isSignMinus operation, answering true or false, so it makes sense to provide that operation in addition to the ones specified by the other standards.
It looks like the real question is whether Float's methods are merely renaming IEEE-758-2008 functionality (if yes, why rename at all and add to the confusion?), ISO 10967 functionality, or are something else entirely (e.g. Smalltalk provided behavior in the context of the Smalltalk experience).
First and foremost, Smalltalk. The ANSI Smalltalk numeric spec is based on 10967, but that standard lacks some operations found in IEEE-754. But those have different names anyway, so it's easy in this case to comply with *both* standards. Regards, -Martin