# [racket-dev] flonum vs. inexact-real

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?