[Openmcl-devel] Double precision Floor bug?

[Gary Byers]

There are entire disciplines - numerical methods and numerical analysis -
devoted to investigating these issues.

I still have vivid memories of having been awakened from a pleasant nap
in high school math class.  After only a few minutes, it became clear
that the person screaming at me was not only real but was in fact the
teacher and that she seemed to be upset about something.  I did my best
to calm her down, but asserting that I'd never need to know any of this
seemed to have exactly the opposite of the intended effect.  When her
anger finally subsided, she spoke clearly and calmly, and I still vididly
remember her exact words: "40 years from now, you'll be having an email
(never mind what that is) conversation, and you'll wish that you had
the mathematical sophistication to back your intuition."

It must be extremely satisfying for a teacher to finally get through
to a student.  I had one of those moments of insight that seem to come
all too rarely, and I resolved that from that day forward I'd try to find
someplace to sleep where I wouldn't be bothered by anyone like this.

That said: yes, since floating-point arithmetic is inherently
imprecise in general, different mathematically equivalent expressions
can produce different results.  Some times, some approaches are
clearly better than others (in that they are more likely to be more
accurate or avoid triggering arithmetic exceptions or by some other
metric.)  A metric that involves arbitrary alegebraic constraints
(like "the remainder should never be greater than the denominator")
can be very hard to satisfy when the quantities involved are imprecise
approximations of the numbers we think they are.

? (= 1/100 .01d0)
NIL
? (< 1/100 .01d0)
T

As Brian Hayes suggested, if you care about things like "the laws of
algebra", you probably don't want to use these imprecise approximations
(floats) at all.  If you do use floats, you have to be very careful to
avoid confusing artifacts with implementation strategies that satisfy
algebraic constraints, even when the numbers involved can't be represented
precisely.

(Either that, or the people who study numerical methods have it all wrong,
and this stuff isn't nearly as complicated and subtle as they seem to think
it is.  The world might be a better place if that were true.  Seriously.
Have you looked at their textbooks ?  They're full of math!)



On Mon, 4 Jun 2012, Scott L. Burson wrote:

> On Sun, Jun 3, 2012 at 3:44 PM, Brian Hayes <bhayes at amsci.org> wrote:
>>
>> This isn't really a Lisp issue; it's an IEEE-754 floating-point issue.
>
> I'm not sure it's quite that simple.  Yes, FP arithmetic is
> approximate and produces results that are sometimes counterintuitive.
> But the lesson there is precisely that subtle changes to FP arithmetic
> _can_ produce more desirable results.
>
> In the case before us, it seems entirely possible that the second
> implementation of FLOOR has better properties in all or most cases
> than the first.  I haven't analyzed it sufficiently to convince myself
> of that, but I agree that its behavior on the given example is closer
> to what I would want.  (As Sudhir points out, one would naively expect
> the remainder always to be less than the divisor.)
>
> I'd wager a little digging would turn up a text on FP algorithms that
> would answer the question authoritatively.
>
> -- Scott
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>