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 <nicolas.cellier.aka.nice@gmail.com>:
2009/7/8 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.