Issue 940: (13/10) = 1.3 returns false
Locked
12345
12345
Re: Issue 940: (13/10) = 1.3 returns false
 
|
2009/7/8 Hernan Wilkinson <[hidden email]>:
> 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. > If you like the late binding, and if you are using a set of functions which having no side effects , then you can, instead of computing the result , store the numerical operations (in same fashion as Fraction stores division) and compute the exact value(s) only when you really need them. Then you can bring in the power of mathematical apparatus/trigonometry rules and use them at full scale. Think, how many things we can add (in parallel to Fraction) SquaredNumber SquaredRootNumber CosFn SinFn TanFn PiFraction and so on.. limited only by your own limits/knowledge... But again, all of this stuff is more related to predicting than exact computing , which is happens to be inexact because of hardware limitations :) > On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <[hidden email]> wrote: >> >> 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 > > _______________________________________________ > 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
|
|
The question is why do you want Floats to be the default implementation of reals instead of ScaledDecimals?
On Wed, Jul 8, 2009 at 4:29 PM, Igor Stasenko <[hidden email]> wrote:
-- 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 David Goehrig
Dave, I certainly share your opinion about these german discussions.
They are ridiculous indeed. But then mathematics are ridiculous too. Who cares about maths in real life? And IT, except among these circles of geeks, common, isn't it a wonderful way to waste our time? In squeak kernel, it happens that floats are used in graphics (and sounds but who cares) Not sure the optimization is premature but yes, we don't need them: we have a rectangular grid of pixels after all, so the most elementary Morphic geometry problem that don't have a solution in Q as you might have learned in your 18 years of studying math, will have an approximate solution in Q, and that's what we are interested in to just draw a Form. Now I challenge you to solve all these little geometry problem in integer arithmetic and remove Float from a Squeak image. If brave enough, you can attempt to use the AlgebraicNumber from MathMorph, just for beauty, then approximate with a Fraction and let BitBlt round to the nearest pixel at the end. I guess you gonna miss pretty soon those imperfect inexact Float of the unreasonnable people. Then you will realize that these pixels are just hardware detail and that you should better work at a higher level where you need those algebraic and other irrational numbers. Unfortunately, even if you manage to create a beautiful computer algebra system with exact representation of these mathematical beings, it will still be a pain to descend to hardware. Of course, if you just want to use your math strength to add decimal numbers, as your examples show, that's were these ScaledDecimal fit perfectly. If you just want to tell every body to use ScaledDecimal where they expect ScaledDecimal, that's a good point, and I join my voice. But if you consider Float are unecessary optimizations except for some engineers like me, I can't agree. You must be using Squeak in console mode ;) Nicolas 2009/7/8 David Goehrig <[hidden email]>: > 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 > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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 David Goehrig
David Goehrig wrote:
> IEEE754 run contrary to all of my 18 years of sudying math and using > rational numbers. I find that a bit difficult to accept because numerical analysis courses in colleges and universities describe floating point arithmetic as a basis for the material. Really: without knowing how floating point arithmetic works, then it's going to be considerably harder to do applied math work. Also, I don't see how anybody could mount an argument against floating point arithmetic on math grounds when e.g.: Knuth devotes a significant number of pages of The Art of Computer Programming to them. Not to say that Knuth has to be right, but... Andres. _______________________________________________ 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
This kind of approach will introduce discontinuity problems when the FPU
is asked to calculate sin(x) when x is close to zero... IME, most platforms offer a different answer to that kind of stuff. IIRC, SGI was the only platform I found with "natural" tan(x) behavior. If you introduce "better" behavior, then the work somebody else did to ensure smoothness of results could be broken. Then, people will ask "why does my algorithm give result x when written in C, but y when written in Squeak?". Hernan Wilkinson wrote: > > > > > [...] 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 > > > > > R > - > > > _______________________________________________ > 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
|
|
> Then, people will ask "why does
> my algorithm give result x when written in C, but y when written in > Squeak?". It happens already... :-) > > Hernan Wilkinson wrote: >> >> >> >> > [...] 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 >> >> >> >> >> R >> - >> >> >> _______________________________________________ >> 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 > _______________________________________________ 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
On Wed, Jul 8, 2009 at 5:30 PM, Nicolas Cellier <[hidden email]> wrote:
Nicolas please read what I wrote: 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. The case of the core drawing engine is a special case. You would optimize this case specially, knowing full well that it is a critical system loop that affects the performance of everything else. But turning around and saying that because this core loop requires optimization, that this optimization technique should be the default is a total non sequitur. One special case does not define what the general case should be. When making a fundamental design decision as to what a sane default is, you need to look at what the non-expert using the system will expect. Saying that "you should know IEEE 754 float math" isn't helpful. Skilled professionals
make mistakes with floating point math every day. Telling a child in grammar school that their program doesn't work because they don't understand IEEE 754 math is equally absurd. Design decisions should not be driven by implementation optimization requirements. Doing so only places the incidental preferences of the system implementors over the needs of those who will use it.
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
|
|
2009/7/9 David Goehrig <[hidden email]>:
> > > On Wed, Jul 8, 2009 at 5:30 PM, Nicolas Cellier > <[hidden email]> wrote: >> >> I guess you gonna miss pretty soon those imperfect inexact Float of >> the unreasonnable people. > > Nicolas please read what I wrote: > > 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. > > The case of the core drawing engine is a special case. You would optimize > this case specially, knowing full well that it is a critical system loop > that affects the performance of everything else. But turning around and > saying that because this core loop requires optimization, that this > optimization technique should be the default is a total non > sequitur. One special case does not define what the general case should be. > But still the're not giving the answer why (13/10) should be equal to 1.3 I can see the only exit, which may meet your (inexperienced users) expectations: - replace the Float binding in SystemDictionary with ScaledDecimal - and rename current Float class to InexactFloat and deal & live with all consequences of such refactoring.. >When making a fundamental design decision as to what a sane default is, you need to look at what the non-expert using the system will expect. Saying that "you should know IEEE 754 float math" isn't helpful. Skilled professionals > make mistakes with floating point math every day. Telling a child in grammar school that their program doesn't work because they don't understand IEEE 754 math is equally absurd. > Design decisions should not be driven by implementation optimization requirements. Doing so only places the incidental preferences of the system implementors over the needs of those who will use it. > > Dave > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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
|
|
In reply to this post by David Goehrig
Hi dave
thanks for your email because it makes me realizing something important: Computer float numbers are NOT math float numbers. Let us accept it. > I guess you gonna miss pretty soon those imperfect inexact Float of > the unreasonnable people. > > Nicolas please read what I wrote: > > 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. > The case of the core drawing engine is a special case. You would > optimize this case specially, knowing full well that it is a > critical system loop that affects the performance of everything > else. But turning around and saying that because this core loop > requires optimization, that this optimization technique should be > the default is a total non sequitur. One special case does not > define what the general case should be. I did not read the fix of nicolas as an optimization, more like a way to fix the wrong behavior of abstraction we offers. I would be in favor to remove = on floats to raise the awareness that it does not make sense. > When making a fundamental design decision as to what a sane default > is, you need to look at what the non-expert using the system will > expect. as programmer we should be expert to the point we understand float = is nonsense. > Saying that "you should know IEEE 754 float math" isn't helpful. > Skilled professionals > make mistakes with floating point math every day. Exact this is why we should not confort them in this attitude by having a system that make them think that float equality make sense. > Telling a child in grammar school that their program doesn't work > because they don't understand IEEE 754 math is equally absurd. But telling a kid: Floats are not real float numbers so do not use them as such. Once my math teacher asked us to computer a function limit and funnily when you type it on a computer at that time you would got a factor 7 between the math and computer. So we learned that there is a difference between math and computer. > Design decisions should not be driven by implementation optimization > requirements. Doing so only places the incidental preferences of > the system implementors over the needs of those who will use it. Exact. What nicolas is doing is not an optimization: this is fixing reality. Your hardware is real and it dictactes all the errors **you** will do, if the language does not offer you the right hardware abstraction. Computer float numbers are NOT math float numbers. Let us accept it. > > Dave > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > _______________________________________________ > 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 David Goehrig
Dave,
I plainly agree about 1.3, it doesn't need to be approximated. Our opinion diverge because I pretend you can't go very far with exact computations. I want elementary users to know that the diagonal length of the square has to be approximated for practical means. sqrt(2) is not a rational, this is independent of any implementation. This happens as soon as our users draws a triangle and want to measure perimeter. I think that the notion of error bounds is essential and I prefer to have grown up users. Even without knowing details of Floating point operations, they'll have to know about inexact approximated computations. That certainly won't prevent our skilled "experts" making mistakes everyday with FPU, but education might reduce level of false assumptions, and enlighten sources of encountered problems. Smalltalk is a good tool for such a deeper education. You can stay at the surface, but you can also always peel the onion and discover another level. And if you are more advanced and not satisfied, you can also implement AlgebraicNumber, isn't that just beautiful? My point is to have a good floating point model underneath, as consistent as possible mathematically, reducing unecessary rounding errors introduced at image level, and reflecting state of the art, be it the imperfect IEEE 754. Smalltalk does not have to waste ULPs just because we consider this stuff as dirty wrt to the "pure" integers and decided not to care ;) Exact vs inexact comparison is just a piece of this puzzle. It is nonetheless a good point that the discussion switches to: where should we use Float and where should we use ScaledDecimal. I did not decide to use Float for representing 1.3, it was there at the origin. Even st80 did not have ScaledDecimal. You see, my change is very good after all because half of our highly educated users are surprised to re-discover (13/10) ~= 1.3e0 :) The next step will be to change ScaledDecimal ugly specifications, because no one will be satisfied very long with 0.5s*0.5s -> 0.3s. Nicolas 2009/7/9 David Goehrig <[hidden email]>: > > > On Wed, Jul 8, 2009 at 5:30 PM, Nicolas Cellier > <[hidden email]> wrote: >> >> I guess you gonna miss pretty soon those imperfect inexact Float of >> the unreasonnable people. > > Nicolas please read what I wrote: > > 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. > > The case of the core drawing engine is a special case. You would optimize > this case specially, knowing full well that it is a critical system loop > that affects the performance of everything else. But turning around and > saying that because this core loop requires optimization, that this > optimization technique should be the default is a total non > sequitur. One special case does not define what the general case should be. > When making a fundamental design decision as to what a sane default is, you need to look at what the non-expert using the system will expect. Saying that "you should know IEEE 754 float math" isn't helpful. Skilled professionals > make mistakes with floating point math every day. Telling a child in grammar school that their program doesn't work because they don't understand IEEE 754 math is equally absurd. > Design decisions should not be driven by implementation optimization requirements. Doing so only places the incidental preferences of the system implementors over the needs of those who will use it. > > Dave > > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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
|
|
> It is nonetheless a good point that the discussion switches to: where
> should we use Float and where should we use ScaledDecimal. > I did not decide to use Float for representing 1.3, it was there at > the origin. Even st80 did not have ScaledDecimal. > You see, my change is very good after all because half of our highly > educated users are surprised to re-discover (13/10) ~= 1.3e0 :) indeed I'm one and I would like the language interface to help him not forgetting that :) > The next step will be to change ScaledDecimal ugly specifications, > because no one will be satisfied very long with 0.5s*0.5s -> 0.3s. > > 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
2009/7/8 Ignacio Vivona <[hidden email]>:
> The question is why do you want Floats to be the default implementation of > reals instead of ScaledDecimals? > Ignacio, This is a good question, and I don't have the answer. It would be worth experimenting. Newspeak project wanted to follow this road AFAIK, unfortunately they died before they did it, so we won't benefit from their work... Michael proposed this earlier in the thread. Unfortunately, current ScaledDecimal implementations will reserve more surprises like 0.5s1 * 0.5s1 -> 0.3s1 We should better have the number of decimal digits undefined 0.5s*0.5s -> 0.25s But still limit number of printed characters 1.0s / 3.0s -> 0.3333333s.... Or maybe use a special notation for repeated pattern 1.0s / 3.0s -> 0.3333333(3) 1.0s / 7.0s -> 0.(142857) > On Wed, Jul 8, 2009 at 4:29 PM, Igor Stasenko <[hidden email]> wrote: >> >> 2009/7/8 Hernan Wilkinson <[hidden email]>: >> > 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. >> > >> >> If you like the late binding, and if you are using a set of functions >> which having no side effects , then >> you can, instead of computing the result , store the numerical >> operations (in same fashion as Fraction stores division) and compute >> the exact value(s) only when you really need them. >> Then you can bring in the power of mathematical apparatus/trigonometry >> rules and use them at full scale. >> >> Think, how many things we can add (in parallel to Fraction) >> SquaredNumber >> SquaredRootNumber >> CosFn >> SinFn >> TanFn >> PiFraction >> and so on.. limited only by your own limits/knowledge... >> >> But again, all of this stuff is more related to predicting than exact >> computing , which is happens to be inexact because of hardware >> limitations :) >> >> > On Wed, Jul 8, 2009 at 3:59 PM, Igor Stasenko <[hidden email]> >> > wrote: >> >> >> >> 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 >> > >> > _______________________________________________ >> > 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 > > > -- > 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 > _______________________________________________ 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
Stephane,
> Computer float numbers are NOT math float numbers. Let us accept it. > > I agree with your sentiment. At the risk of being overly precise, I'd state that computer float numbers are not our everyday decimal numbers. I'd avoid the reference to "math" because computer floating point numbers do have significant math behind them. Andres. _______________________________________________ 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
|
|
So, Stef, what do we do? :-)
I think we have discussed very interesting things is this thread. My conclusions are: 1) Nicolas made a change to avoid confusion when comparing "exact numbers" with "inexact numbers" (among others) 2) This change surprised some people (me in the first place) because it is not how other Smalltalks behave, it is a change in the philosophy of Smalltalk and thus it logically generates disagreements 3) It is clear that Floats are needed due to performance issues, and it is also clear that when performance is not a problem Smalltalk numbers should behave as close as possible (if not equal to) arithmetic. So, I devise these paths: 1) Leave things as they are now in the latest Pharo image, and wait to see if Nicola's change affects real applications (not just tests as it was my case) 2) Same as 1 but making float equals work only when comparing between floats 3) Change the Number hierarchy and make a clear distinction between exact numbers and inexact numbers. Make exact numbers behave as one expects in real math 4) Go back to how things were I think they are pretty much the options... My vote goes for 1 right now. To make 2 we need to experiment more and see how it behaves. I really like 3, I'd love to see that implemented in Smalltalk but doing that model is not easy, it will take time (hey, you have a research track there!), and 4 does not make sense after Nicolas explanations Bye, Hernan. On Thu, Jul 9, 2009 at 6:04 AM, Andres Valloud<[hidden email]> wrote: > Stephane, >> Computer float numbers are NOT math float numbers. Let us accept it. >> >> > > I agree with your sentiment. At the risk of being overly precise, I'd > state that computer float numbers are not our everyday decimal numbers. > I'd avoid the reference to "math" because computer floating point > numbers do have significant math behind them. > > Andres. > > _______________________________________________ > 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
On Thu, Jul 9, 2009 at 3:49 AM, Nicolas Cellier <[hidden email]> wrote: I want elementary users to know that the diagonal length of the square True, but when you deal with a numbers that are irrational, uncomputable, or the rest you expect them not to be represented cleanly. What throws people for a loop is when you
do something like type the following in a python interpreter: >>> 0.2 0.20000000000000001 These sorts of simple rounding errors, do weird things when added with iterative processes.
What most elementary school users expect is something more along the lines of floating point math that is BCD encoded. Intel has had BCD math operators in their chips since the 8 bit days. It only takes 1 bytes to represent .2 or .1 in 4bit packed
BCD. With the exception of numbers that cannot be represented in decimal, the BCD scheme directly mimics what most non-computer science/ non-computer math people expect :)
My point is to have a good floating point model underneath, as consistent as possible mathematically, reducing unecessary rounding And I'm not arguing that at all. I think IEEE754 support is necessary, there is too much useful data encoded in that format. All I am saying is that it is not necessarily the correct design
decision to make it the default representation of numbers. There's a lot to be argued in favor of Ocaml and SML NJ's approach of having entirely separate operators for IEEE754 math. Instead of + you use +. instead of - you use -. etc. SML NJ doesn't even let you test
equality on floats. Really the sticky bit is do you go to this extent, or do you decide your representation of numbers require encoding suffixes as well. Even st80 did not have ScaledDecimal. st80 didn't have IEEE754 floats in it either technically. (IEEE754 wasn't published until 1985). The next step will be to change ScaledDecimal ugly specifications, I agree here as well. There's no good reason that should be the case, other than an excessive attention to significant digits :)
-- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernan.wilkinson
On 9-Jul-09, at 5:58 AM, Hernan Wilkinson wrote: > So, Stef, what do we do? :-) > I think we have discussed very interesting things is this thread. My > conclusions are: > 4) Go back to how things were +1 Frankly I think you could reuse '==' for the *exact* compare between two items in the Number hierarchy and leave '=' as the yes they are *equal* but not the same.... then you could really rummage about and fix/explain/justify why 29347921734912734927349279273499274 == (29347921734912734927349279273499274-1+1) is false and explain why in the same manner as saying (1/10) == 0.1 is false, & resolve why 0.1 == (0.1-0.01+0.01) is false yet 10 == (10-1+1) is true. And yes people do things like use '==' for numbers, for the strangest reasons. -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ 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 9, 2009, at 2:58 PM, Hernan Wilkinson wrote: > So, Stef, what do we do? :-) > I think we have discussed very interesting things is this thread. My > conclusions are: > > 1) Nicolas made a change to avoid confusion when comparing "exact > numbers" with "inexact numbers" (among others) > 2) This change surprised some people (me in the first place) because > it is not how other Smalltalks behave, it is a change in the > philosophy of Smalltalk and thus it logically generates disagreements I do not think that this is a change in philosophy. Clearly you cannot hide the limited nature of float compare to their intellectual/math counterpart. > 3) It is clear that Floats are needed due to performance issues, and > it is also clear that when performance is not a problem Smalltalk > numbers should behave as close as possible (if not equal to) > arithmetic. > > So, I devise these paths: > 1) Leave things as they are now in the latest Pharo image, and wait to > see if Nicola's change affects real applications (not just tests as it > was my case) > 2) Same as 1 but making float equals work only when comparing > between floats Why not. I would like to have a consistent behavior: not true if this is 0.5 and false in 0.3 > 3) Change the Number hierarchy and make a clear distinction between > exact numbers and inexact numbers. Make exact numbers behave as one > expects in real math > 4) Go back to how things were yeap > I think they are pretty much the options... > My vote goes for 1 right now. To make 2 we need to experiment more and > see how it behaves. I really like 3, I'd love to see that implemented > in Smalltalk but doing that model is not easy, it will take time (hey, > you have a research track there!), and 4 does not make sense after > Nicolas explanations We learned all something today :) So this is a positive experience. > > Bye, > Hernan. > > > On Thu, Jul 9, 2009 at 6:04 AM, Andres > Valloud<[hidden email]> wrote: >> Stephane, >>> Computer float numbers are NOT math float numbers. Let us accept it. >>> >>> >> >> I agree with your sentiment. At the risk of being overly precise, >> I'd >> state that computer float numbers are not our everyday decimal >> numbers. >> I'd avoid the reference to "math" because computer floating point >> numbers do have significant math behind them. >> >> Andres. >> >> _______________________________________________ >> 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 David Goehrig
2009/7/9 David Goehrig <[hidden email]>:
> > > On Thu, Jul 9, 2009 at 3:49 AM, Nicolas Cellier > <[hidden email]> wrote: >> >> I want elementary users to know that the diagonal length of the square >> has to be approximated for practical means. >> sqrt(2) is not a rational, this is independent of any implementation. > > True, but when you deal with a numbers that are irrational, uncomputable, or > the rest you > expect them not to be represented cleanly. What throws people for a loop is > when you > do something like type the following in a python interpreter: >>>> 0.2 > 0.20000000000000001 > These sorts of simple rounding errors, do weird things when added with > iterative processes. I guess this happens because they want a guaranty the number will be read back the same. Java do it too AFAIK. Smalltalk has an absPrintExactlyOn:base: which is not used (it should be!) but is far better if I remember and avoid these extra decimals (it comes from scheme). > What most elementary school users expect is something more along the lines > of > floating point math that is BCD encoded. Intel has had BCD math operators > in their > chips since the 8 bit days. It only takes 1 bytes to represent .2 or .1 in > 4bit packed > BCD. With the exception of numbers that cannot be represented in decimal, > the BCD > scheme directly mimics what most non-computer science/ non-computer math > people > expect :) > My point is to have a good floating point model underneath, as >> >> consistent as possible mathematically, reducing unecessary rounding >> errors introduced at image level, and reflecting state of the art, be >> it the imperfect IEEE 754 > > > And I'm not arguing that at all. I think IEEE754 support is necessary, > there is too much useful > data encoded in that format. All I am saying is that it is not necessarily > the correct design > decision to make it the default representation of numbers. There's a lot to > be argued in > favor of Ocaml and SML NJ's approach of having entirely separate operators > for IEEE754 > math. Instead of + you use +. instead of - you use -. etc. SML NJ doesn't > even let you test > equality on floats. Really the sticky bit is do you go to this extent, or > do you decide your > representation of numbers require encoding suffixes as well. Maybe that's worth a try, but this is independent of my change and the same in every Smalltalk dialect. This part of the discussion is a good spin off of the change. My plan would be to differentiate the literals (1.3e or ~1.3, I don't care), but keep the same selectors +,-,*,/ This would enable algorithms to work with both kind of numbers (at your own risks). Eventually, yes, additional selectors could be added meaning exact addition or inexact addition, and those would cause DNU if you don't provide the right number. For paranoid only :) >> >> Even st80 did not have ScaledDecimal. > > st80 didn't have IEEE754 floats in it either technically. (IEEE754 wasn't > published until 1985). > >> >> The next step will be to change ScaledDecimal ugly specifications, >> because no one will be satisfied very long with 0.5s*0.5s -> 0.3s. > > I agree here as well. There's no good reason that should be the case, > other than an > excessive attention to significant digits :) > -- > -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/ > > _______________________________________________ > 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/9 John M McIntosh <[hidden email]>:
> > On 9-Jul-09, at 5:58 AM, Hernan Wilkinson wrote: > >> So, Stef, what do we do? :-) >> I think we have discussed very interesting things is this thread. My >> conclusions are: > >> 4) Go back to how things were > > +1 > > Frankly I think you could reuse '==' for the *exact* compare between > two items in the Number hierarchy > and leave '=' as the yes they are *equal* but not the same.... > > then you could really rummage about and fix/explain/justify why > > 29347921734912734927349279273499274 == > (29347921734912734927349279273499274-1+1) is false and explain why > in the same manner as saying (1/10) == 0.1 is false, & resolve why 0.1 > == (0.1-0.01+0.01) is false yet 10 == (10-1+1) is true. > The reason why I would stick to = meaning exactly and some other symbol meaning approximately, is because I expect = to be transitive, while I can very well understand that approximatelyEqual: is not. I would also avoid == because some IdentitySet and the like would start to hate Numbers... unfortunately ~= means different... =~= or using some unicode symbol... (latex \approx) > And yes people do things like use '==' for numbers, for the strangest > reasons. > Yes, most because one thought it would be faster (?), but not only... An example is the hackish pattern for enumerating objects that would not work anymore :( like http://bugs.squeak.org/view.php?id=2788 > -- > = > = > = > ======================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > 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
Regarding the == instead of =, the only thing I can think of is identity
checking of small integers, where in VW you get some improvement by using == instead of =. IIRC, I measured 25% faster in a loop that just did == as opposed to =. But, of course, using that kind of code is asking for trouble. John M McIntosh wrote: > On 9-Jul-09, at 5:58 AM, Hernan Wilkinson wrote: > > >> So, Stef, what do we do? :-) >> I think we have discussed very interesting things is this thread. My >> conclusions are: >> > > >> 4) Go back to how things were >> > > +1 > > Frankly I think you could reuse '==' for the *exact* compare between > two items in the Number hierarchy > and leave '=' as the yes they are *equal* but not the same.... > > then you could really rummage about and fix/explain/justify why > > 29347921734912734927349279273499274 == > (29347921734912734927349279273499274-1+1) is false and explain why > in the same manner as saying (1/10) == 0.1 is false, & resolve why 0.1 > == (0.1-0.01+0.01) is false yet 10 == (10-1+1) is true. > > And yes people do things like use '==' for numbers, for the strangest > reasons. > > -- > = > = > = > ======================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ 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 |