And I probably would have said the same thing a month ago, but I don’t think it’s that big a deal, particularly for someone who’s into bit-smashing the internals of floating point numbers. (And this coming from someone with novice-level C skills.)
Not my place to say, but if everything that could be done in 20 lines of C were to become a builtin, it would be an even bigger barrier to entry. Prototyping this as a foreign language predicate would be a useful first step in demonstrating its value as a potential builtin. I can’t argue that there aren’t longer term issues with packaging and distribution, but I don’t think we’re there yet.
After all, I’ve added float_parts/4 with these docs.
float_parts(+Float, -Mantissa, -Base, -Exponent) [det]
True when Mantissa is the normalized fraction of Float, Base is the radix and Exponent is
the exponent. This uses the C function frexp(). If Float is NaN or ±Inf Mantissa has the
same value and Exponent is 0 (zero). In the current implementation Base is always 2. The
following relation is always true
Float =:= Mantissa × Base^Exponent
I consider this a special case. It is a simple wrapper around C frexp(). I have deliberately omitted to make this multi-moded. It is not necessary and I want to keep this simple. I also deliberately did not include the direct memory layout. This should remain hidden to accommodate other float formats. The core relation above is (I hope) the basis of floating points and thus true for any float infrastructure we may use in the future. If you really want the memory, you need to use foreign code.