Currently, every inexact real in Racket is represented by a 64-bit IEEE floating-point number.
There's an `--enable-float' configuration option that enables support in Racket for 32-bit floating-point numbers. The use I see for 32-bit arithmetic is to mimic some other program that uses 32-bit floating-point arithmetic. (That was the original motivation, where I was trying to perform Racket computations that mimicked C computations in the drawing toolbox. I later settled on the solution of changing the drawing toolbox to use `double' instead of `float' everywhere.) With the current memory manager, I don't think there's any potential space gain from using 32-bit floats instead of 64-bit floats. Is there any other reason to use 32-bit floating point? The `--enable-float' option doesn't build at the moment, but the immediate problems could be fixed easily. The bigger problem is the interaction of 32-bit numbers and flonum-specific operations. As a concept related to performance, we don't want "flonum" to include multiple representations. It would make sense, though, to say that "flonum" indicates a 64-bit floating-point number and is therefore more specific than "inexact real". We would have to add `flonum?' and change all guards on unsafe flonum-specific operations to use `flonum?' instead of `inexact-real?'. Also, the distinction between inexact reals and flonums would complicate Typed Racket's already-complex number tower. Is it worth the effort to clean up this corner of the number system and leave room for 32-bit floating-point (and maybe other representations some day, as unlikely as that seems)? Or should we just declare "inexact real" and "flonum" to be always 64-bit floating point once and for all? _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
