Hi Nicolas, when you say "We'd better not lie about what the hardware really does." does it mean that if the hardware changes the behavior of the program changes too? if that is true, I'm a bit concern about that. I understand your point and it is a good one, but I still disagree with you in something. You say that 13/10 is a different number than 1.3, and as I said, that is true if you think in programing (representation) terms. For me (and that is what I've been taught), 13/10 and 1.3 are different symbols that represent the same number. It is like expresing 3 in roman numbers, III. They are not different numbers but the same written with different symbols. So, I would like my programing language to be aware of this because most of the programers do not have such a good skill on numbers as you do, and I think programing language should be closer to people than to hardware. Andres made a good point too, I think the solution goes that way... Maybe this is a crazy idea and breaks more code as you say, but maybe Float should not be on the Number hierarchy, and if you write 1.3, the object that represents that number is not going to be an instance of float but of scaledecimal or fraction or whatever, but not float... and all operations are made with exact representation. And, if you need performance, well, switch to another hierarchy, to one that you explicitly select, that means that you are aware of its limitations.
On Wed, Jul 8, 2009 at 12:08 AM, Nicolas Cellier < [email protected]> wrote: > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
