From: Calamitas Date: 2007-09-01T09:57:40+09:00 Subject: Re: Bug in % (Float)? On 31/08/2007, Morton Goldberg wrote: > On Aug 30, 2007, at 5:56 PM, Calamitas wrote: > > I don't think you can really ask for anything better. > > The above def suggests I can. I'm not saying it's a plug-in > replacement for %, but it shows that a better answer can be obtained > for the case in question. But what is better? I think we disagree on that. > > In Ruby 0.1 > > really is 0.10000000000000000555 as that is the floating point > > number closest to 0.1 ... > > That's true ... > > > ... and it doesn't fit 10 whole times in 1.0. This has nothing to do > > with the algorithm used. > > ... but Ruby appears to think otherwise > > sprintf("%.25f", 1.0/0.1) # => "10.0000000000000000000000000" > > causing me to conclude something is amiss in the % operator algorithm. But that is a different question... It seems to me that you are looking for a way to make % and / obey a mathematical equation that is true for reals but that simply isn't for floats. You can change the definitions of % and / slightly to obey the rule you want it to obey (although I'm not entirely sure that your "fix" works in general,) but you can't change it to satisfy all mathematical equations that are true for reals, and any change probably makes other calculations more imprecise. I can understand your feeling though. You expect 1.0 % 0.1 to be 0.0 and you get 0.1, which is a big difference, a lot bigger than the one between 0.1 and 0.10000000000000000555. This is a consequence of the fact that % is a discontinuous function. Any discontinuous function is dangerous in floating point arithmetic, but only when used near its discontinuities. The only general solution to this is either not to use discontinuous functions near their discontinuities, or take into account the large imprecision. This is really a well-understood problem. It's not the algorithm used that is the problem, it's the question asked that is the problem. Regards, Peter