In the end, perhaps the issue is: * When users see 1.3, they think decimal floating point.
* When programmers see 1.3, they should think binary floating point, but would like to assume decimal floating point. At the end of the day, insisting on seeing 1.3 as decimal floating point runs contrary to what the hardware is doing (I don't know what Groovy's implementation is). This should not be an issue of liking or not liking because we don't get to rewrite or reinterpret the IEEE-754 standard to match our preferences. Ignacio Vivona wrote: > I like Groovy: > 1.3 == 13/10 -> true > 1.3*1.3 == 169/100 -> true > 0.1 == 1/10 -> true > 9.9999731e20 < 9.9999730e20 -> false > 0.5 == 1/2 -> true > > > 2009/7/7 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. > 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... > > 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 > > > > > On Tue, Jul 7, 2009 at 7:37 PM, Nicolas Cellier > <[email protected] > <mailto:[email protected]>> wrote: > > 2009/7/7 Stéphane Ducasse <[email protected] > <mailto:[email protected]>>: > > > > On Jul 7, 2009, at 11:21 PM, Hernan Wilkinson wrote: > > > >> ok, but can you be sure that your objects are not handling > floats? > >> maybe the same code handles floats when you want speed and > fractions > >> when you want precision, I remember we did that once but I > don't > >> remember if we had to compare the numbers... > >> I understand your point and I agree with you that erratic > behavior > >> should be avoided as much as possible, new programmers > always get > >> confused when two floats print the same but return false when > >> compared, but do you agree with me that this new behavior make > >> floats "less polymorphic" with numbers? and code more > odd?... you > >> see, people will have the same question as me, why (13/10) > = 1.3 > >> returns false but (1/2) = 0.5 returns true? > >> Maybe the solution has to be more drastic, and if we want > to avoid > >> people for comparing floats for equality, just not let them or > >> return false always... or take the other road as Smalltalk > had after > >> now, that is: make the implementation detail as hide as > possible, > >> and if the programmer really cares about representation > problems let > >> him compare the numbers with a difference... > >> Smalltalk has almost 30 years old and I have not seen any big > >> problem related to comparing numbers, so why changing that? > what do > >> we gain with the change?... I'm still not sure that this > change is > >> for the better :-) > > > > :-) > > yes I understand that point too :) > > So please continue to discuss that we understand the deep > pros and > > cons. I think this is extremely healthy > > > > Stef > > > > Except the polymorphism argument, this is more a principle of > inertia. > "Why did you change the browser, I want it back..." > > IMO, Smalltalk had not so many problems because it is not used for > number crunching. > Financial apps use ScaledDecimal where due and avoid the problem. > I used it for crunching numbers, but I feel a bit alone :) > > Concerning polymorphism, I hope I demonstrated this is a false > polymorphism because you get non transitive equality and > numbers not > well ordered. > > Anyway: > | a b | > a = 13/10. > b= a asFloat. > self assert: (a = b) ==> (a squared = b squared). > self assert: (a = b) ==> (a fractionPart = b fractionPart). > etc... > They behave differently, really. > > Concerning (0.5) ~= (1/2) that might be a good idea. > What stopped me was the implications it would have on > inequality tests... > 0.5 < (1/2). -> false > 0.5 = (1/2). -> false > 0.5 > (1/2). -> false > So they are unordered... I prefer 0.5 = (1/2). -> true > strategy mainly > for this reason. > > 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] > <mailto:[email protected]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Hope is for sissies (Gregory House, M.D.) _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
