Would NaN be polymorphic with floats? Igor Stasenko wrote: > Btw, Nicolas, > > in some past, i have proposed to exclude NaN from Float(s) at all by making: > NaN is a singleton instance of class NotANumber > and change all VM floating point primitives to return such singleton > in case if computation result is NaN. > > NotANumber says for itself: > > NaN isNumber == false > > What do you think about it? (Opinion of others is valuable too). > > 2009/7/8 Nicolas Cellier <[email protected]>: > >> 2009/7/8 Stéphane Ducasse <[email protected]>: >> >>> On Jul 8, 2009, at 4:07 AM, Hernan Wilkinson wrote: >>> >>> >>>> ok, let me start again. >>>> 1) I created the issue because 13/10 = 1.3 works different in the >>>> new pharo image that in vw, va, dolphin, squeak and the previous >>>> pharo version, so I thought it was a bug >>>> 2) I understand that comparing floats is not good and I also >>>> understand the representation problems of floats >>>> 3) I'm in favor of making changes. Changes are needed to make >>>> progress although not all changes make progress >>>> >>>> But, Nicolas when you say >>>> >>>>> Anyone depending on (13/10) = 1.3 is plain wrong... >>>>> >>>> I do not completely agree. You say that because you are thinking >>>> like a programmer and you know that 1.3 is a float, but if you ask >>>> the same question to an accountant, engineering, etc. they will say >>>> that 13/10 is equal to 1.3. So, outside computers, 13/10 is equal to >>>> 1.3, the same as 1/2 equals to 0.5 and so on. >>>> Dan Ingalls followed a good design principle: to hide as much as >>>> possible implementation details from the user and that is why >>>> Smalltalk has such a great Number model that I did not see in >>>> another language. >>>> From my point of view, the implementation you are providing is not >>>> quite following this principle or at least is making the float >>>> representation problem more evident. If the last is the intention, I >>>> think it should be consistent (i.e. 1/2 = 0.5 should return false >>>> also) and provide specific messages to handle that decision too. >>>> Or maybe the change has to be more profound, maybe changes like the >>>> one suggested by Michael van der Gulik >>>> are necessary, maybe we have to print ScaledDecimals as float are >>>> printed now and print floats with a special representation to make >>>> evident that is not a "normal" number... >>>> >>> May be this would be good in fact. >>> >>> I was wondering why we could not have >>> = comparison always been false? >>> >>> Stef >>> >>> >> {(1/2) < 0.5. >> (1/2) = 0.5. >> (1/2) > 0.5.}. -> {false. false. false.} >> >> We cannot order these two numbers. >> Well, this will break some other expectations... Like (a >= b) = (a < b) >> not... >> IMO, we would be shifting the model from inexact Floating point to >> Interval arithmetic. >> Again, this is a possibility, but I'd rather see this Behaviour in a >> separate class, and let user select his own model. >> IMO we must provide traditional Floating point arithmetic reflecting >> the state of the art. >> >> Nicolas >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > . > >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
