How many floating-point numbers are in the interval [0,1]?

  #include 

  int main(int argc, char **argv)
  {
        unsigned long long int mant, exp ;

        mant = 0;
        exp = 1;

        typedef struct _bitfield80 {
                unsigned int sign:1;
                signed int exp:15;
                unsigned long long int mant:64;
        } bitfield80;

        union {
                long double a;
                bitfield80 b;
        } union80;

        union80.b.sign = 0;
        union80.b.mant = mant;
        union80.b.exp = exp;

        printf ("%0.17000Lf\n", union80.a);
        return 0;
  }

Even worse, it kicks in earlier than one might naively think. People are often surprised to hear a value as simple as 0.1 has no matching floating point representation.

(For those interested, http://www.exploringbinary.com/why-0-point-1-does-not-exist-... has a nicely illustrated explanation.)

The smallest positive “denormal” 80-bit float is (I think) 2^(2 − 2^(14)). I just represented it using 5 decimal digits and two minus signs. :-)

William Kahan claims the following issues with unums:

1. Unum computation does not always deliver correct results.

2. The description of unums sidesteps using unum for solving calculus problems.

3. Unums can be expensive in terms of time and power consumption.

4. Each computation in unum space is likely to change the bit length of the structure. This requires either unpacking them into a fixed-size space, or data allocation, deallocation, and garbage collection during unum operations, similar to the issues for dealing with variable-length records in mass storage.

5. Unums provide only two kinds of numerical exception, quiet and signaling NaN (Not-a-Number).

6. Unum computation may deliver overly loose bounds from the selection of an algebraically correct but numerically unstable algorithm.

7. The costs and benefits of unum over short precision floating point for problems requiring low precision are not obvious.

8. Solving differential equations and evaluating integrals with unums guarantee correct answers but may not be as fast as methods that usually work.

Point #4 makes implementation tricky and slow. Point #6 (from what I understand) means unum operations tend to guarantee correctness by being overly vague - by denoting results that FP can produce using ranges that are just too big to be useful.