On 10/12/2013 07:28 AM, Konrad Hinsen wrote:
Neil Toronto writes:
> In case Asumu doesn't ask us for them, mine are here:
>
>
https://github.com/ntoronto/writing/raw/master/2013rcon-floating-point/toronto-2013rcon-floating-point.pdf
Thanks!
A nice tutorial, and behind it a nice set of libraries, not only for
computing with floating-point numbers but also for understanding
what's going on there. I wish other languages had an equivalent.
Thanks! I tried to not keep the goodies all to myself. :)
Something I haven't been able to figure out, from your tutorial and
from reading the Racket documentation, is how Racket positions itself
on the IEEE 754 compliance vs. optimization scale. Most languages
don't promise much IEEE compliance and thus leave compilers much
freedom to do optimizations even when they change the result. As a
result, floating-point maths is a major source of non-reproducible
computations because different compilers effectively make different
programs out of identical source code.
So how about Racket? Can a programmer rely on a given program producing
the exact same result on all platforms, and with any Racket version?
In almost everything, PLT and Racket prioritize correctness over speed.
With regard to floating point, I'll attempt to speak for both myself and
Matthew Flatt. (He'll correct me if I promise too much. :D) On all of
our supported platforms, Matthew has made Racket's flonum functions as
compliant as possible without reimplementing them from scratch.
More precisely, on every supported system whose FPU and C libraries'
flonum functions (arithmetic, sqrt, exp, log, pow, trig) return
correctly rounded results when given non-special values, every
`racket/flonum' export should be perfectly IEEE 754-2008 and C99
compliant. On all such systems, starting about two Racket versions ago,
functions that use `racket/flonum' directly or indirectly should always
produce exactly the same results.
If you want to test Racket's compliance on your system, run this:
#lang racket
(require math/utils)
(test-floating-point 10000)
If it returns '(), your system is either compliant or close to it. The
argument is the number of random tests (use 1000 for a quick test); it
also tests every combination of special values, and many extreme,
boundary and exact cases. Some of the tests are very sensitive. All of
the tests are against `math/bigfloat', which wraps MPFR, whose
floating-point function implementations are *proved* to be correctly
rounded, and which takes great pains to be compliant in every other way.
We know Racket is compliant because our automated testing machine DrDr
runs the above test every time someone pushes a change to Racket.
I added that test with the math library, Matthew fixed a few errors it
found, and it has passed every time since.
Some unordered details:
* Special values are -inf.0, -0.0, 0.0, +inf.0 and +nan.0, and
sometimes 1.0 and other integers (depending on the function).
* If `test-floating-point' reports a flonum function does something
wrong w.r.t. a special value (input or output), please report it.
* Don't be surprised if trig functions on Windows or Mac OS X are a
bit inaccurate (1-3 ulps instead of 0.5 ulps). Linux seems very solid.
* FPUs made in the last 10 years or so should always compute correctly
rounded arithmetic and square root.
* Functions in `math/special-functions' and `math/distributions' may
become more accurate in future releases.
Also, I just had an idea about how to automate at least half the
debugging I talked about at RacketCon. I'm going to try it today.
Don't worry, Jay: it's another use for preimage computation. :D
Neil ⊥
____________________
Racket Users list:
http://lists.racket-lang.org/users
