Fortunately, there's a standard for floating point arithmetic... hopefully we'll get hardware support for decimal floating point some day --- although I can see how somebody might complain because 12765275237652375367328763862.34876387628726872368276823 got rounded to 12765275237652375000000000000...
Hernan Wilkinson wrote: > 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] > <mailto:[email protected]>> wrote: > > 2009/7/8 Hernan Wilkinson <[email protected] > <mailto:[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] > <mailto:[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
