Why doesn't frexp () give scientific notation?

Question

Scientific notation is a general way to express a number with an explicit order of magnitude. First, a non-zero digit, then a notation, then a fractional part and an exponent. In binary format, there is only one possible non-zero digit.

The floating point math includes an implicit first digit equal to one, then the mantissa bits "follow the notation".

So why does frexp() put a radius point to the left of the implicit bit and return a number in [0,5, 1] ​​instead of a notation similar to [1, 2]? Is there an overflow to beware of?

Effectively, it subtracts another offset value specified in IEEE 754 / ISO 60559. In hardware, this potentially trades the add-on for XOR. One, this seems like a pretty weak argument, given that in many cases a return to normal operation will require another floating point operation.

Answer 1

The argument says:

4.5.4.2 frexp function

The frexp, ldexp, and modf functions are the primitives used by the rest of the library. It was suggested that they be dropped for the same reasons that ecvt, fcvt and gcvt were dropped, but their followers saved them for general use. Their use is problematic: on non-binary architectures, ldexp may lose accuracy, and frexp may be inefficient.

It can be assumed that the “remainder of the library” was more convenient to write using the frexp or was traditionally written against this interface, although it did not bring any benefit.

I know that this does not completely answer the question, but it did not quite fit into the commentary.

I should also point out that some of the choices made in the C language design precede IEEE 754. Perhaps the format returned by frexp makes sense in the PDP-11 floating-point format (s), or any other architecture in which for the first time The frexp function was introduced. EDIT: see also page 155 of the manual for one PDP-11 model.