Re: Rob's going to hate me... (Remainder bug)
kbochert at copper.net wrote:
> It seems to me that given that fmod(a,b) is defined as returning a value
> which is less than b, failure to do so is not just inaccurate but a real bug.
I'm sure it *does* return a value less than b.
But when you print a result such as 0.01 - 99 * epsilon
to 10 significant digits, like Euphoria does by default,
you see: 0.01
>>From a Google search:
> http://www.boic.com/b1mnum.pdf. (dated Nov 3 2003 !!)
>
> QUOTE:
> Appendix
> Microsoft Modulo Bugs
> Over the years of testing of the Number Class, we've discovered nasty bugs in
> Microsoft's fmod()
> function, which you can easily confirm for yourself. For example, using the
> Windows
> 95 Calculator
> accessory (evidently built on the same fmod function) try this simple
> calculation:
> 5.5 mod 1.1
> Instead of giving the correct result, which should be 0,
> it shows the result as 1.1.
> ...
This person obviously is not aware of the pitfalls of
binary, limited-precision floating-point.
> We were unable to find any reference to this
> disturbing bug in the
> Microsoft Knowledge Base.
Because it's not really a bug in the library.
It's a limitation of the floating-point hardware.
> ... For some versions, the bug did NOT appear in the calculator
> program, but
> using fmod() ALWAYS produces this bug.
No doubt because the calculator program uses
*decimal* floating-point, where numbers like 0.1, 0.01 etc.
*can* be represented with perfect accuracy (but then
lots of other numbers can't, so this is not a
perfect solution either.)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
