[racket-dev] long double for racket

That's how I avoid a lot of pain in testing `math/flonum'.

First, though: Michael, really good work on this. I'm looking forward to 
using it!

To randomly test the functions in isolation, you need:

  * A function that measures error in ulps (an extfl version of
    `flulp-error') and a way to distinguish +0.0 from -0.0

  * A solid set of deterministic test inputs (extfl versions of +0.0,
    -0.0, +inf.0, -inf.0, +min.0, +max.0, -min.0, -max.0, logs, square
    roots, and exponents of these, etc.)

  * A *good* way to generate random 80-bit floats (maybe using an extfl
    version of `ordinal->flonum')

  * `math/bigfloat' and conversion to and from extfls, to perfectly
     simulate 80-bit floating-point ops regardless of hardware

You're probably thinking of randomized boxing/unboxing/optimization 
tests, though. I think this is a very good idea, not just for extfls, 
but for flonums as well. It should be pretty easy to create a Redex 
model of finite programs that includes a few kernel forms, and use it to 
generate random programs.

Run each program as it is, with JIT optimizations. Run each without JIT 
optimizations. Transform each to use bigfloat-implemented operations, 
whose results are always correct and can't be unboxed. If the result of 
running all three is different, fail.

I'll bet we'd catch a few weird, overlooked cases, and maybe a few that 
are already affecting programs.

I'd be happy to help with the flonummy and bigfloaty stuff.

Neil ⊥

On 01/28/2013 06:45 PM, Robby Findler wrote:
> Would random testing help avoid some of the pain of writing a good
> initial set of tests?
>
> Robby
>
>
> On Mon, Jan 28, 2013 at 7:18 PM, Matthew Flatt <mflatt at cs.utah.edu
> <mailto:mflatt at cs.utah.edu>> wrote:
>
>     At Sat, 29 Dec 2012 14:05:08 +0300, Michael Filonenko wrote:
>      > I have prepared a new version of the patch (attached).
>
>     Thanks!
>
>     I've merged your patch into the git repo, with some changes:
>
>       * Abstracted more to both reduce code duplication and make the
>         "product line" variation easier to read and write.
>
>       * Renamed a few operations to consistently use "extfl", and added
>         `extfl->inexact' and `extfl-available?'.
>
>       * Changed the module organization, so that the extflonum bindings are
>         always available, and operations raise `exn:fail:unsupported' when
>         they are not supported. The operations `extflonum?', `extflvector?',
>         and `extflonum-available?' always work.
>
>       * Adjusted the reader to more completely isolate extflonums (e.g., no
>         complex numbers with an extflonum part).
>
>       * Changed "sconfig.h" and "scheme.h" to infer when extflonums can be
>         supported (see also the new note in "src/README"), and added
>         `--disable-extflonum' to `configure'.
>
>       * Reorganized and expanded the documentation.
>
>     I ran out of steam before trying a MinGW compile, so that's almost
>     certainly broken. Meanwhile, I have some thoughts on making an MSVC
>     build work with a MinGW-compiled support DLL (more later).
>
>     Unboxing of locally-bound extflonums is still not implemented, but I
>     think it's probably not too far away. If you want to give that a try, I
>     recommend continuing in the direction of threading an `extfl' flag
>     through the JIT, instead of duplicating functions.
>
>     Finally, I think the test suite probably needs a lot more tests to
>     cover the extflonum operations. Most of the flonum tests are in
>     "optimize.rktl", and I think it would make sense to add similar tests
>     there for extflonum operations --- guarded by `(when
>     (extflonum-available?) ...)'.
>
>     _________________________
>        Racket Developers list:
>     http://lists.racket-lang.org/dev
>
>
>
>
> _________________________
>    Racket Developers list:
>    http://lists.racket-lang.org/dev
>