Issue 940: (13/10) = 1.3 returns false
Locked
12345
12345
Re: Issue 940: (13/10) = 1.3 returns false
 
|
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 <[hidden email]> ok, let me start again. -- Hope is for sissies (Gregory House, M.D.) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by hernan.wilkinson
2009/7/8 Hernan Wilkinson <[hidden email]>:
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Ignacio Vivona-2
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 <[hidden email] > <mailto:[hidden email]>> > > 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 > <[hidden email] > <mailto:[hidden email]>> wrote: > > 2009/7/7 Stéphane Ducasse <[hidden email] > <mailto:[hidden email]>>: > > > > 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 > [hidden email] > <mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Hope is for sissies (Gregory House, M.D.) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by hernan.wilkinson
On Jul 8, 2009, at 4:07 AM, Hernan Wilkinson wrote: > 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... May be this would be good in fact. I was wondering why we could not have = comparison always been false? Stef > 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 <[hidden email] > > wrote: > 2009/7/7 Stéphane Ducasse <[hidden email]>: > > > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Nicolas Cellier
> I have given enough arguments and should let other people express > their opinion without fearing an agressive response :) In my opinion the behavior should exactly match the underlying binary representation of floats, otherwise I get results where I feel the system is 'fuzzing' while I didn't tell it to do so and I start to feel uneasy. So where VisualWorks does (13/10) = 1.3 "true" it makes me cringe, OTOH where it does 1.3 = 1.3d "false" it makes me feel right at home. At the heart of the matter is that we use /decimal/ floating point notation to represent /binary/ floats, and the issues (surprises for some people) of approximation should be put at exactly that conversion place and not compensated elsewhere -- this way we get a system with the least surprises. I am too new at Squeak to know how well separated #displayString (application behavior) and #printString (tools behavior) are, but it might help if the tools clearly show when the #printString of a float is approximate by prepending a ~ for example: 1.3 printString "~1.3" 1.0 printString "1.0" Regarding #asExactFraction I'd say that is an ugly pleonasm but more importantly it is confusing (it suggests that #asFraction is fuzzing), hence it should be deprecated; #asFraction should do an exact conversion IMO. R - _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Igor Stasenko
>>
>> I repeat here my arguments: >> Anyone depending on (13/10) = 1.3 is plain wrong... >> > +1. > I dealt with 3D rendering/linear algebra using floats in the past , > and i can say just one: > - never write the code which compares the floats to be equal to some > exact value. > It makes no sense in practice, because of inexact nature of floats. +1 me too Code like '(13/10) = 1.3' just jumps at you if you have been bitten by this before. In languages of APL branch (which are traditionally used for intensive calculations) the comparison of real numbers is 'tolerant': that is two numbers are considered equal if their relative difference is less than some predefined small value: a = b isTrue if: |a-b|/max(a,b) < Epsilon http://www.jsoftware.com/help/primer/tolerance.htm http://jsoftware.com/help/dictionary/d000.htm Creators of these languages put a lot of considiration into this and it I think they got it right. It may be too radical to redefine comparison of real values in Smalltalk (although it still makes sense to do so in practical terms) but the discussed test is just a blind shot into a sky. The user should be discouraged to rely on a such comparison. regards, Danil > As we know, if two vectors is perpendicular, then their dot product is zero. > But it is almost always non-zero on hardware, especially when you > transform vectors or compute them using data, which already contains a > degree of precision error! > So, i learned that comparing dot product with zero makes no sense, > instead you'd better test it with something like: > > abs(float) < epsilon > where epsilon is very small number. > > So, i don't understand, why its so important for such kind of equality > tests to work right at all - because you hardly will use such tests in > practice. > >> Either you want fast and inexact floating point operation and should >> not rely on exact equality (use #closeTo:). >> Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal. >> That's the deal, and it's quite independant from the language. >> >> The false assertions that people are trying to push does not matter: >> it's high time to educate. >> My proposition has at least the merit to put a light on these >> dangerous floating point strict equality tests >> (I saw so many bugs like testing cos(pi/2) == 0). >> >> And I'm still waiting for the hypothetical application that would >> break because of this change. >> That's the main point of interest. >> In this case, we'll see if patching is necessary and easy. >> >> Nicolas >> >> P.S. concerning behaviour of conversion binary<->decimal >> representation, I'm rather the one trying to unify Smalltalk. >> Dolphin, gst and Pharo adopted some of my changes to behave as exactly >> as we can, and thus behave the same. >> Try this in your prefered dialect, I guess you will have some surprise. >> 123.4567890123d3 = (1234567890123/10000000). >> 123.4567890123d3 = (1234567890123/10000000) asFloat. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Reinout Heeck
I have the impression that we see the problem of representation of
what we manipulate. In the mathematical world it makes sense to write 1.3 to mean 13/10 now since in computer world 1.3 is not 13/10 may be we should have ~1.3 or something like that. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Stéphane Ducasse
2009/7/8 Stéphane Ducasse <[hidden email]>:
> > On Jul 8, 2009, at 4:07 AM, Hernan Wilkinson wrote: > >> 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... > > May be this would be good in fact. > > I was wondering why we could not have > = comparison always been false? > > Stef > {(1/2) < 0.5. (1/2) = 0.5. (1/2) > 0.5.}. -> {false. false. false.} We cannot order these two numbers. Well, this will break some other expectations... Like (a >= b) = (a < b) not... IMO, we would be shifting the model from inexact Floating point to Interval arithmetic. Again, this is a possibility, but I'd rather see this Behaviour in a separate class, and let user select his own model. IMO we must provide traditional Floating point arithmetic reflecting the state of the art. Nicolas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Danil Osipchuk-2
2009/7/8 danil osipchuk <[hidden email]>:
>>> >>> I repeat here my arguments: >>> Anyone depending on (13/10) = 1.3 is plain wrong... >>> >> +1. >> I dealt with 3D rendering/linear algebra using floats in the past , >> and i can say just one: >> - never write the code which compares the floats to be equal to some >> exact value. >> It makes no sense in practice, because of inexact nature of floats. > > +1 me too > Code like '(13/10) = 1.3' just jumps at you if you have been bitten by > this before. > In languages of APL branch (which are traditionally used for > intensive calculations) the comparison of real numbers is 'tolerant': > that is two numbers are considered equal if their relative difference > is less than some predefined small value: > a = b isTrue if: |a-b|/max(a,b) < Epsilon > Sorry, I can't help talking :) Of course, this model does not preserve good properties like = being transitive. a := 1.0 - (0.5*Epsilon). b := 1.0. c := 1.0 + (0.5*Epsilon). self assert: (a = b) & (b = c) ==> (a = c). So I'd rather stick to a keyword selector like fuzzyEqual: Again, this definition corresponds more to an Interval arithmetic model. RealInterval >> fuzzyEqual: b ^(self intersectionWith: b) notEmpty Smalltalk has both exact (Integer/Fraction/ScaledDecimals) and inexact (Float) arithmetic, and the semantic of = will vary from exactEqual: to fuzzyEqual:. RealInterval >> exactEqual: b "always false, if a or b are inexact" ^a isExact and: [b isExact and: [a bounds exactEqual: b bounds]] RealInterval >> isExact "self is exact if Card(self) = 1" ^a bounds min exactEqual: a bounds max Don't confuse with = that could simply mean that they represent the same interval RealInterval >> = b ^a bounds exactEqual: b bounds I did not care much of polymorphism (coercion, double dispatching or whatever), but you get the idea. You can also use probability distributions if it better fits your model, but mathematical background might be a bit short... Nicolas > http://www.jsoftware.com/help/primer/tolerance.htm > http://jsoftware.com/help/dictionary/d000.htm > > Creators of these languages put a lot of considiration into this and > it I think they got it right. > It may be too radical to redefine comparison of real values in > Smalltalk (although it still makes sense to do so in practical terms) > but the discussed test is just a blind shot into a sky. The user > should be discouraged to rely on a such comparison. > > regards, > Danil > >> As we know, if two vectors is perpendicular, then their dot product is zero. >> But it is almost always non-zero on hardware, especially when you >> transform vectors or compute them using data, which already contains a >> degree of precision error! >> So, i learned that comparing dot product with zero makes no sense, >> instead you'd better test it with something like: >> >> abs(float) < epsilon >> where epsilon is very small number. >> >> So, i don't understand, why its so important for such kind of equality >> tests to work right at all - because you hardly will use such tests in >> practice. >> >>> Either you want fast and inexact floating point operation and should >>> not rely on exact equality (use #closeTo:). >>> Or you want (13/10) = 1.3 EXACTLY, and then should better use ScaledDecimal. >>> That's the deal, and it's quite independant from the language. >>> >>> The false assertions that people are trying to push does not matter: >>> it's high time to educate. >>> My proposition has at least the merit to put a light on these >>> dangerous floating point strict equality tests >>> (I saw so many bugs like testing cos(pi/2) == 0). >>> >>> And I'm still waiting for the hypothetical application that would >>> break because of this change. >>> That's the main point of interest. >>> In this case, we'll see if patching is necessary and easy. >>> >>> Nicolas >>> >>> P.S. concerning behaviour of conversion binary<->decimal >>> representation, I'm rather the one trying to unify Smalltalk. >>> Dolphin, gst and Pharo adopted some of my changes to behave as exactly >>> as we can, and thus behave the same. >>> Try this in your prefered dialect, I guess you will have some surprise. >>> 123.4567890123d3 = (1234567890123/10000000). >>> 123.4567890123d3 = (1234567890123/10000000) asFloat. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Nicolas Cellier
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 <[hidden email]> wrote: 2009/7/8 Hernan Wilkinson <[hidden email]>: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Stéphane Ducasse
exactly! and programing languages should help us not hardware.
On Wed, Jul 8, 2009 at 7:03 AM, Stéphane Ducasse <[hidden email]> wrote: I have the impression that we see the problem of representation of _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
What do we mean when we write 1.3 in a computer language, most of the time?
Again, looking at VW just because I'm most familiar with it these days, doubles (what Squeak calls floats) are written as 1.3d. Floats (single precision IEEE-754) are written 1.3, but can also be written 1.3e. Hernan Wilkinson wrote: > exactly! and programing languages should help us not hardware. > > On Wed, Jul 8, 2009 at 7:03 AM, Stéphane Ducasse > <[hidden email] <mailto:[hidden email]>> wrote: > > I have the impression that we see the problem of representation of > what we manipulate. > In the mathematical world it makes sense to write 1.3 to mean > 13/10 now > since in computer world 1.3 is not 13/10 may be we should have ~1.3 or > something like that. > > Stef > > _______________________________________________ > Pharo-project mailing list > [hidden email] > <mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by hernan.wilkinson
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 > <[hidden email] > <mailto:[hidden email]>> wrote: > > 2009/7/8 Hernan Wilkinson <[hidden email] > <mailto:[hidden email]>>: > > 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 > [hidden email] > <mailto:[hidden email]> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by hernan.wilkinson
On Jul 8, 2009, at 1:31 PM, Hernan Wilkinson wrote: > > 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. As a counterexample: we readily accept that precedence rules in smalltalk are different than in mathematical notation, 1 + 2 * 3 is interpreted differently in the two notations. So IMO we should lean towards writing programming syntax, not shoe- horning mathematical expectations in there too much. (Mainly because trying to impose mathematical notation will give wrinkling and ripping in all kinds of unexpected places in the system). > [...] 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... That only solves the issue of representing literals because: > and all operations are made with exact representation. cannot be done for all operations: obvious ones like square root, log, sin, etc and less obvious ones like #squared where you run out of enough bits to maintain precision (in fixed-width implementations). R - _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
Yes.
I have the impression that the representation should give the indication of the fuzzyness of the numbers. Now it would be nice that we are of a kind of fix point around this nice discussion :) From what I heard I would like to give a try to the solution proposed by nicolas and also see if we could improve the user experience. I should reread my scheme Stef > > On Jul 8, 2009, at 1:31 PM, Hernan Wilkinson wrote: >> >> 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. > > As a counterexample: we readily accept that precedence rules in > smalltalk are different than in mathematical notation, > 1 + 2 * 3 > is interpreted differently in the two notations. > > So IMO we should lean towards writing programming syntax, not shoe- > horning mathematical expectations in there too much. > (Mainly because trying to impose mathematical notation will give > wrinkling and ripping in all kinds of unexpected places in the > system). > > >> [...] 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... > > That only solves the issue of representing literals because: > > >> and all operations are made with exact representation. > > > > cannot be done for all operations: obvious ones like square root, log, > sin, etc and less obvious ones like #squared where you run out of > enough bits to maintain precision (in fixed-width implementations). > > > R > - > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by johnmci
2009/7/8 John M McIntosh <[hidden email]>:
> > On 7-Jul-09, at 6:40 PM, Nicolas Cellier wrote: > >> I'm waiting the answer why 1.3*1.3 is different from 169/100. When >> you'll have discovered this, we'll talk about 13/10 = 1.3 on more >> serious bases. >> >> Nicolas > > Well for Fraction I do (1.3*1.3 ) asApproximateFraction (169/100) > because people have expectations about (1.3*1.3) = 169/100 > the same expectations they likely had for (1/10) = 0.1 > > noting that > (1/10) = 0.1 false > (1/10) = (0.1 asApproximateFraction) true > > > Personally I think here the issue is more what the different smalltalk > think and do for various float to faction conversions > not perhaps what is correct. Unless of course you want to drop any > numerical compatibility? > Hi John, I missed this one, Yes, numerical compatibility is an issue and I'm fighting to restore it. FYI, Smalltalks are just not compatible at very first step: converting literal decimals to Float... This is because conversion algorithms cumulate several rounding errors... ... all with a different algorithm... ... and because of ANSI laxism about implementation. I corrected Integer>>asFloat, Fraction>>asFloat, Number>>readFrom: and maybe a few others to obtain a uniform behaviour: round to the nearest Float (IEEE 754 default mode round to nearest even). I proposed patches to Squeak/Pharo, gst, Dolphin, ST/X and VW, AFAIK they are integrated in Pharo, gst, Dolphin; partially in Squeak. All is MIT, so other dialects just have to cherry pick. Concerning the exact vs inexact comparison, I raised the subject regularly on various mailing list, but yes it would be great to come to an agreement. Its on the pending bugfix list for Squeak 3.11 at least and Paolo has an opened issue for gst i think. Nicolas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
I love these sorts of ridiculous arguments, because the problem is fundamentally a question of design.
Do you design accounting for the expectations of reasonable people, or do you design for programmers :) Seriously, there's a bigger question here than should you or should you not compare fractions and reals. The question is "for whom is Pharo written?" IEEE754 run contrary to all of my 18 years of sudying math and using rational numbers. I expect the semantics 1/10 = 10/100 = 100/1000 = 1/2*1/5 = 0.5 * 0.2 based on math in Q. This is no different from expecting 0.1 + 0.2 = 0.3 and not 0.29999999.... If you're building software intended for ordinary people, programmers who rarely do computational mathematics, and for
educational use, then defaulting to arbitrary precision scaled math is the right way to go, as it matches the expectations of the audience. If you're defining the default behavior of numbers in the system, the principle of "thou shall not commit premature optimization" should come into play. If you're that desperately in need of floating point speed, you're also probably capable of applying that and other optimization techniques accordingly, as befits your problem.
Consider IEEE754 floats as optimization for a specific class of application, but a de-optimization for all other uses. Now if you're only designing Pharo for people who program IEEE754 float intensive applications, then by all means, go right ahead and make them the default.
Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
In reply to this post by Reinout Heeck
not really... root, log, sin, etc could be messages that only inexact numbers know how to answer , so you want "2 sqrt", do "2 asFloat sqrt", but for +, *, /, etc. they work as expected. We can also have better representations for number like pi. Why pi is instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) = 0 could be true... just a quick hack: Pi>>/ aNumber ^ Fraction numerator: self denominator: aNumber "Or maybe an object representing that Pi has been divided/multiplied, etc Fraction>>cos ^ numerator cosDividedWith: denominator Pi>>cosDividedWith: denominator ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] and so on
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
2009/7/8 Hernan Wilkinson <[hidden email]>:
> >> >> >> > [...] 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... >> >> That only solves the issue of representing literals because: >> >> >> > and all operations are made with exact representation. >> >> >> >> cannot be done for all operations: obvious ones like square root, log, >> sin, etc and less obvious ones like #squared where you run out of >> enough bits to maintain precision (in fixed-width implementations). > > not really... root, log, sin, etc could be messages that only inexact > numbers know how to answer , so you want "2 sqrt", do "2 asFloat sqrt", but > for +, *, /, etc. they work as expected. > We can also have better representations for number like pi. Why pi is > instance of Float and not Pi? If pi is instance of Pi, then cos(pi/2) = 0 > could be true... just a quick hack: > Pi>>/ aNumber > > ^ Fraction numerator: self denominator: aNumber "Or maybe an object > representing that Pi has been divided/multiplied, etc > > Fraction>>cos > > ^ numerator cosDividedWith: denominator > > Pi>>cosDividedWith: denominator > > ^denominator = 2 ifTrue: [ 0 ] ifFalse: [ ... ] > > and so on > don't forget to add Pi>>mantisOfLength: numBits to compute the Pi up to given precision. :) But your examples is not about computing a result, but rather predicting it. So why bother writing so much stuff , while you can just implement : Number>>cosPiHalved ^ 0 :) >> >> >> >> R >> - >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 940: (13/10) = 1.3 returns false
|
|
it was just an example where you can "bind" as "late" as possible a combination of symbols with its value... I like late binding :-) in this example allows you to get rigth results... and of course
cosPiHalved is not the same as "a/b cos" where a is bound to pi and b to 2... it is not only for literals. On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |