- Pharo-dev - lists.pharo.org

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Nicolas Cellier

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > FWIW... VW has two choices... a) fail the primitives when the answer is > INF or NaN, or b) return whatever the FPU says. Â Also, NaN and INF are > regular instances of Float and Double... > What if some part of the code rely on signalling an Exception , and another part rely on answering exceptional values? Nicolas

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Nicolas Cellier

2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: > 2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >>> Well, but on the other hand, what happens when you do things like 1.0 + >>> NaN or NaN + 1.0? Â It should work... >>> >> >> Easy with double dispatching. >> More boring is to coerce a (Float nan) created by a call to an >> external library into a (Smalltalk at: #Nan). >> > I don't think so. > The are few places where you need to change things, like in > Â Interpreter>>floatObjectOf: aFloat > to test against Nan, and return a NotANumber singleton instead of > creating a new Float instance. > As I don't use VMMaker every day, last time it took me 3 hours to produce a VM (retrieving links, downloading, working around Monticello 1.5 initialization problem, and messing with directory structure and configure options). Just to apply an existing change... That's what I call boring :) But in theory, I agree, that should be easy. Nicolas >>> Igor Stasenko wrote: >>>> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >>>> >>>>> Would NaN be polymorphic with floats? >>>>> >>>>> >>>> Do you mean , be a part of Number/Float class hierarchy? >>>> Answer is: no. >>>> Because NotANumber is not a number :) >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 8, 2009

Re: [Pharo-project] NaN thoughts

by Igor Stasenko

2009/7/8 Torsten Bergmann <astares(a)gmx.de>: > When cleaning up things would it be useful to have > infinit arithmetic too? > > See http://www.squeaksource.com/Infinity.html > Yes, sure :) > Bye > Torsten > -- > Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate > fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Nicolas Cellier

2009/7/8 Reinout Heeck <reinz(a)desk.org>: > > On Jul 8, 2009, at 12:53 PM, Andres Valloud wrote: > >> Well, but on the other hand, what happens when you do things like >> 1.0 + >> NaN or NaN + 1.0? Â It should work... > > It will break further down the line though: > > (1.0 + NaN) < (1.0 + NaN) > > should that return NaB (not a Boolean)? > > > Shouldn't obtaining NaN from arithmetic be modeled as a resumable > exception, so the calling code can decide what kind of object to > return as the value? (Instead of only one choice being hardwired in > the system). > > IMO, that's the main interest in NaN class: make the Exception behaviour programmable from within the image. Nicolas > > R > - > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Andres Valloud

FWIW... VW has two choices... a) fail the primitives when the answer is INF or NaN, or b) return whatever the FPU says. Also, NaN and INF are regular instances of Float and Double... Reinout Heeck wrote: > On Jul 8, 2009, at 12:53 PM, Andres Valloud wrote: > > >> Well, but on the other hand, what happens when you do things like >> 1.0 + >> NaN or NaN + 1.0? It should work... >> > > It will break further down the line though: > > (1.0 + NaN) < (1.0 + NaN) > > should that return NaB (not a Boolean)? > > > Shouldn't obtaining NaN from arithmetic be modeled as a resumable > exception, so the calling code can decide what kind of object to > return as the value? (Instead of only one choice being hardwired in > the system). > > > > R > - > > >

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Igor Stasenko

2009/7/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> Well, but on the other hand, what happens when you do things like 1.0 + >> NaN or NaN + 1.0? Â It should work... >> > > Easy with double dispatching. > More boring is to coerce a (Float nan) created by a call to an > external library into a (Smalltalk at: #Nan). > I don't think so. The are few places where you need to change things, like in Interpreter>>floatObjectOf: aFloat to test against Nan, and return a NotANumber singleton instead of creating a new Float instance. >> Igor Stasenko wrote: >>> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >>> >>>> Would NaN be polymorphic with floats? >>>> >>>> >>> Do you mean , be a part of Number/Float class hierarchy? >>> Answer is: no. >>> Because NotANumber is not a number :) >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Reinout Heeck

On Jul 8, 2009, at 12:53 PM, Andres Valloud wrote: > Well, but on the other hand, what happens when you do things like > 1.0 + > NaN or NaN + 1.0? It should work... It will break further down the line though: (1.0 + NaN) < (1.0 + NaN) should that return NaB (not a Boolean)? Shouldn't obtaining NaN from arithmetic be modeled as a resumable exception, so the calling code can decide what kind of object to return as the value? (Instead of only one choice being hardwired in the system). R -

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Nicolas Cellier

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Well, but on the other hand, what happens when you do things like 1.0 + > NaN or NaN + 1.0? Â It should work... > Easy with double dispatching. More boring is to coerce a (Float nan) created by a call to an external library into a (Smalltalk at: #Nan). > Igor Stasenko wrote: >> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> >>> Would NaN be polymorphic with floats? >>> >>> >> Do you mean , be a part of Number/Float class hierarchy? >> Answer is: no. >> Because NotANumber is not a number :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Igor Stasenko

2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: > Well, but on the other hand, what happens when you do things like 1.0 + > NaN or NaN + 1.0? Â It should work... > Sure, it should. What prevents you from implementing it as: NotANumber>>+ number ^ self NotANumber>>adaptToNumber: rcvr andSend: selector selector == #+ ifTrue:[^self]. selector == #* ifTrue:[^self ]. selector == #- ifTrue:[^self ]. selector == #/ ifTrue:[^self]. ^super adaptToNumber: rcvr andSend: selector and so on.. > Igor Stasenko wrote: >> 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> >>> Would NaN be polymorphic with floats? >>> >>> >> Do you mean , be a part of Number/Float class hierarchy? >> Answer is: no. >> Because NotANumber is not a number :) >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

July 8, 2009

Re: [Pharo-project] NaN thoughts (Was: Re: Issue 940: (13/10) = 1.3 returns false)

by Nicolas Cellier

There was a Parcplace package extending VW with such classes (NaN, Infinity, Infinitesimal), and I liked it (can't remember if inheriting from Magnitude though). The main difference I see with state of the art FPU practice is Exception handling: that does force Exception handling where users might prefer traditional exceptional values... Nicolas 2009/7/8 Igor Stasenko <siguctua(a)gmail.com>: > 2009/7/8 Andres Valloud <avalloud(a)smalltalk.comcastbiz.net>: >> Would NaN be polymorphic with floats? >> > Do you mean , be a part of Number/Float class hierarchy? > Answer is: no. > Because NotANumber is not a number :) > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 8, 2009