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. 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. 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
