...

...

2.4x -> x That's supposed to be 2.4x -> 2, of course. Ah, damn it. I was hoping for a long discussion on just what math would look like with rounding like that ;-)

I think it has a name... "modulo" maybe? Stefan

Felipe Lessa wrote:

On Mon, Oct 27, 2008 at 8:30 AM, Janis Voigtlaender wrote:

...

Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding.

Nobody rounds in passes, of course =).

Oh, Mrs. "I forgot her name" actually did ;-) -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

Ketil Malde wrote:

Janis Voigtlaender writes:

...

...

If you round to odd instead of round to even, then 4.5 rounds to 5,

...

Well, of course I did not learn to round to odd. I learned to round .5 to above, but not to do repeated rounding.

Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life.

Of course. But that was not the point of the discussion... -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

Ketil Malde wrote:

Janis Voigtlaender writes:

...

...

Since just about every floating point operation involves some sort of loss of precision, repeated rounding is a fact of life.

...

Of course. But that was not the point of the discussion...

Well, allow me to contribute to keeping the discussion on topic by stating that when I was in school, I was taught to round up. Now if you will excuse a momentary digression:

The point *I* wanted to make is that we have two qualitatively different rounding modes: round up on 0.5, or round to even (or randomly, or alternating), and they make sense in different contexts.

Doing computations with fixed precision, you keep losing precision, and rounding bias accumulates - thus the need to use some non-biased rounding.

Doing (small scale) calculations on paper, you can avoid repeated rounding, and only round the result. In which case rounding up is okay, you don't introduce the amount of bias as with repeated rounding. And if your input happens to be truncated, rounding up becomes the right thing to do.

Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do.

Yes, that all makes sense. And I did not intend to cut you short. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

On Mon, 27 Oct 2008, Ketil Malde wrote:

Of course, Haskell should discard the rather tasteless IEEE754 crud, and do its calculations on infinite streams of digits. Then, rounding upwards after 'take'ing a sufficient amount of decimals will be the right thing to do.

When I implemented just this in http://darcs.haskell.org/numericprelude/src/Number/Positional.hs I used redundant sets of digits. In a base-n number I use the digits 1-n to n-1. That is, the truncated number abc.def actually represents the interval [abc.def-0.001, abd.def+0.001]. This representation is not unique (more non-unique than standard base-n representation), but testing numbers with infinitely many places for equality is not possible anyway. So (==) is obsolete, just like for floating point numbers. The advantage is that carries are reduced considerably. It allows to compute (sqrt 2)^2, which is not possible in standard representation, because one can never decide whether the result is 2.00000... or 1.99999.... (Pentium's division algorithm also uses digits -1, 0, 1 (we could call them mone (minus one), none, one) for reduced carries.) In this redundant representation one could simply round by truncation, the result depends on the particular sequence of digits used to represent a number, and the rounding would not become worse by repeated rounding (also because it is already worse than the Haskel 98 rounding since the error with respect to the last digit is not only 0.5 but up to 1 :-).