[racket] RacketCon 2013 videos

From: Neil Toronto (neil.toronto at gmail.com)
Date: Sat Oct 12 17:54:32 EDT 2013

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 ⊥


Posted on the users mailing list.