From: Calamitas <calamitates@...>
Date: 2007-09-03T08:57:49+09:00
Subject: Re: Bug in % (Float)?

On 02/09/07, Morton Goldberg <m_goldberg@ameritech.net> wrote:
> On Sep 2, 2007, at 7:32 AM, Calamitas wrote:
> I'm not too surprised. It was bound to break for some sufficiently
> small n;  the discontinuities become denser as n -> 0. My horror over
> Ruby's (actually I suspect the underlying C math library) result with
> n = 0.1 is 0.1 is so large. Even 0.00032 is rather a larger n than I
> would like.

Well, the smallest n for which m_mod_n(1.0, 1.0 / n) is way off is n =
93. If it's any consolation though, among the first million n, there
are only 78161 for which m_mod_n doesn't give something zeroish. There
are 497886 such n for which Ruby's built-in % is off.

> > You can change Ruby's POV, sure. It depends on what you want. The best
> > result for every atomic operation, or the best result overall. The
> > latter sounds ideal, but I don't believe it can be done in general.
> > (If you can do that, I'm pretty sure you'll be famous.)
>
> Yeah. But someday when you tell your grandchildren about the eminent
> mathematicians you once knew, my name isn't going to come up :)

Dang. I don't know any eminent mathematicians, and I thought now
here's my chance... Yeah well ;-)

> All too true. That's why I use Mathematica rather than a general-
> purpose language such as Ruby for serious numerical work. Because
> there are things like Pisot numbers lurking in the mathematical
> bushes, there will always be seemingly innocuous computations that go
> sour when IEEE floats are used. I never meant to imply that I thought
> otherwise. I am just wondering if there isn't a better way to do %
> with IEEE floats.

That all depends on what 'better' means I guess.

Will you let me know what Wolfram Research answers?

Regards,
Peter