IEEE arithmetic in C

[David Neff]

Not being a Sun expert, I'm limiting my comments to the IEEE spec.

In article <1990Apr27.173218.19870 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>(1) Where's the support for extended-format variables?
>
>(2) Where's the support for extended format *at all* with the high-speed
>	floating-point add-ons?  Extended format is not optional in IEEE!

If I'm not mistaken, extended precision is not required for IEEE
conformance.  And in any case, double precision is a perfectly
conforming representation for single extended.

Here's the relevent text (remember that `shall' means a conforming
implementation *must* support the feature, `should' means that a
conforming implementation need not support the feature):

>From section 3.4:

    All implementations conforming to this standard shall support the
    single format.  Implementations should support the extended format
    corresponding to the widest basic format supported, and need not
    support any other extended format.

This tells me that an implementation can be fully conforming even if it
only supports single precision.  And that an implementation can also
conform if it supports only single and double precision.

>From section 3.3:

    An implementation of this standard is not required to provide (and
    the user should not assume) that single extended have greater range
    than double.

Given the language I quoted from Section 3.4, I read the `shall's
elsewhere in Section 3.3 as describing the requirements of the extended
formats *if you have them*, not as requiring that you have them.  This
is much like Section 8 that says that traps are only a `should' feature
but if you have them they `shall' appear as described.

Finally, Table 1 shows that the format parameters for single extended
are indeed met by double precision.

I agree that trouble occurs if a vendor claims to support IEEE extended
forms (beyond the degenerate single extended = double case I mentioned)
but doesn't provide ways to get at them.  But conformance can be
achieved simply by backing off from such a claim.  And, more subtly,
that also means *not* leaving intermediate expression values in
extended precision from one operation to the next.

Another issue that's been hinted at in this thread is support for NaNs.
As I read the standard, a conforming implementation need not preserve
one of the input NaNs.  It is only required to produce some quiet NaN.

>From section 6.1 (again, note `should's and `shall's):

    Every operation involving one or two input NaNs, none of them
    signaling, shall signal no exception but, if a floating-point
    result is to be delivered, shall deliver as its result a quiet NaN,
    which should be one of the input NaNs.
-- 
UUCP: {pyramid,sri-unix,ingr}!garth!dneff
USPS: Intergraph APD, 2400 Geng Road, Palo Alto, Ca, 94303
AT&T: (415) 852-2334