In article <[EMAIL PROTECTED]>, Tim Peters <[EMAIL PROTECTED]> writes: |> |> Well, just about any technical statement can be misleading if not qualified |> to such an extent that the only people who can still understand it knew it |> to begin with <0.8 wink>. The most dubious statement here to my eyes is |> the intro's "exactness carries over into arithmetic". It takes a world of |> additional words to explain exactly what it is about the example given (0.1 |> + 0.1 + 0.1 - 0.3 = 0 exactly in decimal fp, but not in binary fp) that |> does, and does not, generalize. Roughly, it does generalize to one |> important real-life use-case: adding and subtracting any number of decimal |> quantities delivers the exact decimal result, /provided/ that precision is |> set high enough that no rounding occurs.
Precisely. There is one other such statement, too: "Decimal numbers can be represented exactly." What it MEANS is that numbers with a short representation in decimal can be represented exactly in decimal, which is tautologous, but many people READ it to say that numbers that they are interested in can be represented exactly in decimal. Such as pi, sqrt(2), 1/3 and so on .... |> > and how is decimal no better than binary? |> |> Basically, they both lose info when rounding does occur. For example, Yes, but there are two ways in which binary is superior. Let's skip the superior 'smoothness', as being too arcane an issue for this group, and deal with the other. In binary, calculating the mid-point of two numbers (a very common operation) is guaranteed to be within the range defined by those numbers, or to over/under-flow. Neither (x+y)/2.0 nor (x/2.0+y/2.0) are necessarily within the range (x,y) in decimal, even for the most respectable values of x and y. This was a MAJOR "gotcha" in the days before binary became standard, and will clearly return with decimal. Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list
