[Ann] Calypso update: method browser and better UI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Ann] Calypso update: method browser and better UI

Denis Kudriashov
Hi.

I glad release new version of Calypso:
  • white toolbar (according to theme background color)
  • separators between radio button groups
  • clickable labels instead of buttons
  • method browser 
    • view modes
    • scopes
    • window tabs for following navigation requests

Best regards,
Denis
Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

HilaireFernandes
It looks great!

The tabs on the MessageBrowser really reduces the window noise.
I see these error when asking for implementors:
"Instance of AColorSelectorMorph class did not understand
#localMethodNamed:ifAbsent:"


Something really cool, will be the implementors and sender button to
work too for selected method in the source code area.
I know we can get it from the contextual menu 'Code search...', but it
is so common to search for implementor and senders of methods used in
the source code itself. And of course it should open in new tab too.

Hilaire

Le 12/01/2017 à 12:07, Denis Kudriashov a écrit :
> Hi.
>
> I glad release new version of Calypso:

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

Denis Kudriashov

2017-01-12 15:08 GMT+01:00 Hilaire <[hidden email]>:
The tabs on the MessageBrowser really reduces the window noise.
I see these error when asking for implementors:
"Instance of AColorSelectorMorph class did not understand
#localMethodNamed:ifAbsent:"

You need latest version of Pharo 6. New method is there. 
 


Something really cool, will be the implementors and sender button to
work too for selected method in the source code area.
I know we can get it from the contextual menu 'Code search...', but it
is so common to search for implementor and senders of methods used in
the source code itself.

But how you suggest to distinguish user intention? what to use as query source: method from method view or current message in code editor?
 
And of course it should open in new tab too.

Yes. Problem that I not hook into text editor yet. So any navigation from source code is standard Pharo "global commands". But I need to use Calypso commands instead. And it is not trivial task to hack this place.
Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

HilaireFernandes
Le 12/01/2017 à 15:29, Denis Kudriashov a écrit :
> You need latest version of Pharo 6. New method is there.

Ok

> But how you suggest to distinguish user intention? what to use as query
> source: method from method view or current message in code editor?

Easy: if no text selected in code editor -> query from method view,
otherwise -> query from selected method in code editor.
Tools tips of the implementors and senders buttons should document it to
make the feature discoverable by user.


>     And of course it should open in new tab too.
>
>
> Yes. Problem that I not hook into text editor yet. So any navigation
> from source code is standard Pharo "global commands". But I need to use
> Calypso commands instead. And it is not trivial task to hack this place.

I guess so, but you will be real winner.


--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

Denis Kudriashov

2017-01-12 15:44 GMT+01:00 Hilaire <[hidden email]>:
>     And of course it should open in new tab too.
>
>
> Yes. Problem that I not hook into text editor yet. So any navigation
> from source code is standard Pharo "global commands". But I need to use
> Calypso commands instead. And it is not trivial task to hack this place.

I guess so, but you will be real winner.

And this is done. I just upload new stable version:
- source code shortcuts are managed by Calypso. I found simple hook how to achieve this
- senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window.
- no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors
bpi
Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

bpi
Am 20.01.2017 um 14:12 schrieb Denis Kudriashov <[hidden email]>:
>
> And this is done. I just upload new stable version:
> - source code shortcuts are managed by Calypso. I found simple hook how to achieve this
> - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window.
> - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors
This is really great. I love the Method Browser.

Thank you!

Bernhard
Reply | Threaded
Open this post in threaded view
|

Odd (and wrong) implementation of Float>>sign

Martin McClure-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Nicolas Cellier


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

Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

Denis Kudriashov
In reply to this post by bpi

2017-01-26 21:09 GMT+01:00 Bernhard Pieber <[hidden email]>:
> - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors
This is really great. I love the Method Browser.

I also forgot to show in demo that it is possible to drag window tab to get normal separate window (just drag it to free space in World).
I hope it will be enough because to my mind tabs are most suitable approach but when you really need separate window you will just drag tab out.
Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

wernerk
In reply to this post by Nicolas Cellier
Hi,
i wonder what is the reasoning that "Float nan sign" returns anything else than Float nan?
werner
 
On 01/26/2017 09:47 PM, Nicolas Cellier wrote:


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


Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Martin McClure-2
In reply to this post by Nicolas Cellier
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
>
>
> 2017-01-26 21:22 GMT+01:00 Martin McClure <[hidden email]
> <mailto:[hidden email]>>:

[...]

>     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.

>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

Ben Coman
In reply to this post by Denis Kudriashov
On Fri, Jan 27, 2017 at 5:33 AM, Denis Kudriashov <[hidden email]> wrote:

>
> 2017-01-26 21:09 GMT+01:00 Bernhard Pieber <[hidden email]>:
>>
>> > - no Spec text model anymore. Rubric widgets are used directly. It
>> > improves speed of building text editors
>> This is really great. I love the Method Browser.
>
>
> I also forgot to show in demo that it is possible to drag window tab to get
> normal separate window (just drag it to free space in World).
> I hope it will be enough because to my mind tabs are most suitable approach
> but when you really need separate window you will just drag tab out.

Cool! This should be intuitive enough from peoples experience with web browsers.
cheers -ben

Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Nicolas Cellier
In reply to this post by Martin McClure-2


2017-01-27 0:15 GMT+01:00 Martin McClure <[hidden email]>:
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
>
>
> 2017-01-26 21:22 GMT+01:00 Martin McClure <[hidden email]
> <mailto:[hidden email]>>:

[...]

>     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....
Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Martin McClure-2
On 01/26/2017 05:12 PM, Nicolas Cellier wrote:
> -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....

Thanks for looking into it. I'm afraid I don't have time to dig into
this one further. A GemStone user noticed the difference between Pharo
and GemStone behavior, and in this case it looked like it was the Pharo
behavior that made less sense.

Regards,

-Martin

Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Ben Coman
In reply to this post by Nicolas Cellier


On Fri, Jan 27, 2017 at 9:12 AM, Nicolas Cellier <[hidden email]> wrote:


2017-01-27 0:15 GMT+01:00 Martin McClure <[hidden email]>:
On 01/26/2017 12:47 PM, Nicolas Cellier wrote:
>
>
> 2017-01-26 21:22 GMT+01:00 Martin McClure <[hidden email]
> <mailto:[hidden email]>>:

[...]

>     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. 

What is the next step for Pharo?

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Andres Valloud-4
In reply to this post by Martin McClure-2
> 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]

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).

For example, does it make sense -0.0 < 0.0 to answer false (because
zeros must be numerically equivalent) while -0.0 ~= 0.0 sign answers
true?  That depends on where #sign belongs to.  This is very important
because if #sign isn't IEEE-758 or ISO 10967, then why use it or care
about how it behaves?  And if there's no good explanation, then why is
#sign there in the first place?

Andres.

Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

HilaireFernandes
In reply to this post by Denis Kudriashov
This specific point is terribly super cool!

Thanks

Le 20/01/2017 à 14:12, Denis Kudriashov a écrit :
> - senders/implementors by source code shortcuts in method browser are
> now opened in new tabs instead of separate window.

--
Dr. Geo
http://drgeo.eu


Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

stepharong
In reply to this post by Martin McClure-2
Hi martin

open a ticket so that we do not lose this point.
Stef

> [...]
>
>>     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.

what is a qNan?

>
> 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.
>
>>
>> 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
>


--
Using Opera's mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: [Ann] Calypso update: method browser and better UI

Stephan Eggermont-3
In reply to this post by Denis Kudriashov
On 12/01/17 12:07, Denis Kudriashov wrote:
> I glad release new version of Calypso:

Nice!

>   * white toolbar (according to theme background color)

That doesn't work well. Don't mix styles like this, that is
confusing.

Stephan




Reply | Threaded
Open this post in threaded view
|

Re: Odd (and wrong) implementation of Float>>sign

Martin McClure-2
In reply to this post by Andres Valloud-4
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

12