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
