# Bug in % (Float)? **URL:** \ **Category:** Ruby\ **Created:** [August 30, 2007, 2:02am UTC](https://www.ruby-forum.com/t/bug-in-float/113340 "2007-08-30T02:02:54Z")\ **Posts on this page:** 5\ **Page:** 2
**Author:** ![chuck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/8e7dd6/32.png) [@chuck](https://www.ruby-forum.com/u/chuck)\ **Post date:** [September 2, 2007, 1:33pm UTC](https://www.ruby-forum.com/t/bug-in-float/113340/21 "2007-09-02T13:33:52Z")
On 01/09/07, Morton G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On Sep 1, 2007, at 7:50 AM, Calamitas wrote: > 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. Sure. That’s what every numerical algorithm designer tries to do. But it is far from easy to do in general, and I am not at all sure if it is really possible to have the errors cancel in every case. But even if it is possible, figuring out what the best order is will likely be very expensive to do programmatically and thus not suited for a general purpose language. BTW, I just found an example where your m\_mod\_n function still gives the “wrong” result. 1.0 / 3125.0 == 0.00032 # =\> true m\_mod\_n(1.0, 0.00032) # =\> 0.000319999999999876 In this case, 1.0 / 0.00032 is not exactly 3125.0, i.e., / does not counter the approximation of 0.00032 anymore. > > 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. 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.) The former is something that can be done and that I believe modern processors’ floating point units do or try to do. It does req ---
**Author:** ![chuck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/8e7dd6/32.png) [@chuck](https://www.ruby-forum.com/u/chuck)\ **Post date:** [September 2, 2007, 6:18pm UTC](https://www.ruby-forum.com/t/bug-in-float/113340/22 "2007-09-02T18:18:33Z")
On Sep 2, 2007, at 7:32 AM, Calamitas wrote: > very expensive to do programmatically and thus not suited for a > general purpose language. > > BTW, I just found an example where your m\_mod\_n function still gives > the “wrong” result. > > 1.0 / 3125.0 == 0.00032 # =\> true > m\_mod\_n(1.0, 0.00032) # =\> 0.000319999999999876 > > In this case, 1.0 / 0.00032 is not exactly 3125.0, i.e., / does not > counter the approximation of 0.00032 anymore. 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. > 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 🙂 > The former is > something that can be done and that I believe modern processors’ > floating point units do or try to do. It does require the programmer > to think about error propagation, and that’s not easy, but unless you > can obtain the ideal of the best overall result, the programmer still > needs to think about error propagation, which may be harder because > the more magic that happens the more unpredictable things become. > Also, it will be tempting to not think about error propagation > and the software could run correctly for a long while, pass all > tests, but then break in the most unexpected and horrible way. 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. Regards, Morton ---
**Author:** ![chuck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/8e7dd6/32.png) [@chuck](https://www.ruby-forum.com/u/chuck)\ **Post date:** [September 3, 2007, 1:59am UTC](https://www.ruby-forum.com/t/bug-in-float/113340/23 "2007-09-03T01:59:08Z")
On 02/09/07, Morton G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![chuck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/8e7dd6/32.png) [@chuck](https://www.ruby-forum.com/u/chuck)\ **Post date:** [September 3, 2007, 4:23am UTC](https://www.ruby-forum.com/t/bug-in-float/113340/24 "2007-09-03T04:23:20Z")
On Sep 2, 2007, at 7:57 PM, Calamitas wrote: > 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. That is a real consolation 🙂 Seriously, to me, this is the most convincing argument you’ve come up with in support of your position that finding a better method for computing % with floats is a lost cause. > Will you let me know what Wolfram Research answers? Certainly. I’ll pass it on directly to your gmail account. It may be some time before I get an answer since they are a bit swamped right now with problems arising from their new Mathematica 6 release, and my query is a minor side-issue from their POV. Regards, Morton ---
**Author:** ![chuck](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/8e7dd6/32.png) [@chuck](https://www.ruby-forum.com/u/chuck)\ **Post date:** [September 3, 2007, 12:30pm UTC](https://www.ruby-forum.com/t/bug-in-float/113340/25 "2007-09-03T12:30:10Z")
On 03/09/07, Morton G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > computing % with floats is a lost cause. > In theory, I think it’s possible to do % in a way that enforces that > 1.0 % (1.0 / n) equals 0.0 or something close to it. This could be > done by shifting the discontinuity slightly. But it creates a bias > that may be detrimental to other applications. > > Will you let me know what Wolfram Research answers? > > Certainly. I’ll pass it on directly to your gmail account. It may be > some time before I get an answer since they are a bit swamped right > now with problems arising from their new Mathematica 6 release, and > my query is a minor side-issue from their POV. Ok, thanks. Regards, Peter [Previous page](https://www.ruby-forum.com/t/bug-in-float/113340.md?page=1)