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 <[email protected]>: > > > On Wed, Jul 8, 2009 at 5:30 PM, Nicolas Cellier > <[email protected]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
