```On Sep 1, 2007, at 7:50 AM, Calamitas wrote:

> OK, I agree with you. But you can only reasonably do that in every
> step of the calculation. First, you need to represent 0.1 as a
> floating point number and it ends up slightly larger. Then, you do the
> % operation, but because the number turned out slightly larger
> previously, it no longer fits 10 times and 1.0 % 0.1 returns something
> slightly smaller than 0.1. The only way according to your rule above
> that it can return 0.0 as you want it to is if the history of the
> calculation is taken into account, but that is practically infeasible
> for a general purpose language. You get errors along each step of the
> calculation, and 1.0 % 0.1 is really two steps: approximate 0.1 by the
> closest floating point number (done at parse time), and that is
> 0.10000000000000000555, and then you do 1.0 % 0.10000000000000000555
> which is 1.0 - 9 * 0.10000000000000000555 = 0.09999999999999995004
> because 1.0 - 10 * 0.10000000000000000555 (in real arithmetic) is
> -5.55e-17 and negative. What Ruby does is as close to real number
> arithmetic as you can get *in every step of the calculation*.

You may be right, but I am not convinced. That is, I believe there
might be a way to order the calculation so that in general the errors
cancel rather than reinforce.

> The question you ask Ruby is what 1.0 % 0.1 is. That's near a
> discontinuity in %. You know that there is an error in representing
> 0.1, and it can go either side of the discontinuity. As it turns out,
> it goes on the wrong side of the discontinuity as far as you are
> concerned, but from the point of view of Ruby, that side has the
> closest floating point number.

The question is: can Ruby's POV be changed to agree with mine? :) I
understand that you are arguing that it can't.

> Can you accept that Ruby does % as an atomic operation as well as
> possible?

Not yet. I have submitted the problem to Wolfram Research tech