How robust was floating point format output in pre-IEEE systems?

Question

Most pre-IEEE floating point formats that used biased exponent and a 2's-complement mantissa without a hidden bit, were asymmetric. That is, there was a representable negative value which had no positive equivalent, analogous to 0x80000000 in 32-bit integers.

Printing floating-point numbers typically involved checking if it is negative, negating it if it was, then proceeding with the conversion of the guaranteed non-negative number, taking care to prepend the minus sign if necessary when outputting the text representation.

Naturally, that technique would fail if the argument of the printing routine was the maximal-magnitude negative value. How did the pre-IEEE systems which employed such floating point formats handle the situation? Did any bother to include the code for that special case, or letting the program incur a floating point exception was the norm?

The question is focused on systems with hardware FPUs.

See, for example, a description of the PDP-10 floating point format, mentioning the two's complement format. It says,

Single precision floating point numbers are represented in one 36 bit word as follows:

 0 00000000 011111111112222222222333333
 0 12345678 901234567890123456789012345
 ______________________________________
| |       |                            |
|S| EXP   |     Fraction               |
|_|_______|____________________________|

If S is zero, the sign is positive. If S is one the sign is negative and the word is in twos complement format.

The fraction is interpreted as having a binary point between bits 8 and 9. The exponent is an exponent of 2 represented in excess 200 (octal) notation.

In a normalized floating point number bit 9 is different from bit 0, except in a negative number bits 0 and 9 may both be one if bits 10:35 are all zero. A floating point zero is represented by a word with 36 bits of zero.

Floating point numbers can represent numbers with magnitude within the range 0.5*2^-128 to (1-2^-27)*2^127, and zero. A number that in which bit 0 is one and bits 9-35 are zero can produce an incorrect result in any floating point operation.

from which it is not immediately clear if that restriction makes the useful set of numbers symmetric. Even if it did, how did the printing routines react to the aforementioned bit pattern?

Upd. For the PDP-10 predecessor PDP-6, the floating point format was described in a somewhat more permissive way, see page 27 of the PDF.

For an example of the issue on the CDC 6600 platform, see CERN Computer Newsletter, N 15, page 2, 6600 SYSTEM BUGS:

The input/output conversion routines go into a loop ... the phenomenon appears to be that a number with unnormalised mantissa, and exponent of −0 fails whereas if the mantissa is normalised with exponent −0, conversion is correct.

Answer 1

The primary advantage of two's-complement numeric representations over other forms is that the bottom bits from an addition or subtraction can be computed in a manner which is agnostic to the signs of the operands. Such an advantage does not apply with floating-point numbers, which require treating operations whose result will be larger than the larger operand differently from those whose result will be smaller. As a consequence, two's-complement floating-point representations have always been rare.

As for more general questions about robustness, many floating-point output routines were designed to output values with somewhat less precision than was available in the underlying types, and produce a value that was hopefully within +/-1 of the least significant digit that was output, but with "hope for the best" rounding semantics beyond that. If one has a floating-point number in the range 0 to 1, a simple way of outputting it would be to do something like:

void out_number(double x)
{
  char dig;
  putchar('.');
  for (int i=0; i<num_digits; i++)
  {
    x*=10.0;
    dig = x;
    x -= dig;
    putchar('0'+dig);
  }
}

Such an approach can easily output any desired number of digits, but will be limited in the number of correct digits it can output, especially when used with values near zero. If the number of digits the function tries to output is limited to what it can handle accurately, there may be no need to do anything fancier, and as a consequence many floating-point implementations didn't.