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 <hernan.wilkin...@gmail.com> > 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 < > nicolas.cellier.aka.n...@gmail.com> wrote: > >> 2009/7/7 Stéphane Ducasse <stephane.duca...@inria.fr>: >> > >> > 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 >> Pharo-project@lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Hope is for sissies (Gregory House, M.D.)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
