2009/7/7 Stéphane Ducasse <[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] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
