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 <mfl...@cs.utah.edu
<mailto:mfl...@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
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
