2009/7/9 David Goehrig <[email protected]>: > > > On Thu, Jul 9, 2009 at 3:49 AM, Nicolas Cellier > <[email protected]> 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 > [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
