2009/7/8 Hernan Wilkinson <[email protected]>: > 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.
Well, I happen to program, but my base job is engineer. And I want my engineers to be aware of such problem and not rely on (cos(pi/2)==0). > 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. On the other hand, it confuses users and then abuse them. This is because the implementation is not neutral but strongly influence the behavior. Every one expects (13/10)=1.3, but the fact is that is not true, these are two different numbers. Try (1.3) fractionPart = (13/10) fractionPart asFloat in Pharo VW Squeak etc... Pretending they are the same is fragile. The model cracks quite fast. > 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. Yes but you then have (0.5,1/2) unordered and probably break more code. Current implementation is a compromise that reflects that these numbers can casually have equal representation. We'd better not lie about what the hardware really does. > 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... Well, Newspeak wanted to follow that route and use ScaledDecimal in first place. But then there are speed tradeoffs... Unfortunately, the stream of money has vanished before we get experimental results... > Anyway, as I said before, I'm not sure this change is a good decision, time > will tell I guess, those are my two cents. > Bye, > Hernan > That's true that this is an important change of the semantic of equality. It's reasonnable to doubt, and I thank you for raising the subject, this was necessary. Your opinion is as valuable as mine: inexact equality leads to a simpler model for the user, least surprising because hiding gorry details. I prefer a better mathematical model (= transitive etc...) and to advertise soon about dangers of Float. I say other communities have this behaviour for long (lisp scheme) and it's worth a try . It is also very easy to revert anyway, just replace adaptToXXX:andCompare: with adaptToXXX:andSend:. I have given enough arguments and should let other people express their opinion without fearing an agressive response :) Nicolas _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
