2010/5/7 Michel Hack
<hack@xxxxxxxxxxxxxx>
Baker Kearfott wrote:
> this up, but, speaking of many different allowable formats, we could
> conceivably allow separate formats for mid-rad and inf-sup.
then compared this to the two permitted interchange encodings
for DFP in IEEE 754-2008 (Intel's BID and IBM's DPD).
That comparison is invalid, because, sad as it may be that
we could not agree on ONE interchange format for DFP, the two
encodings represent *exactly* the same set of floating-point
numbers, including NaNs.
I agree with Michel's reasons that the comparison is not valid. What I see as a more appropriate comparison is the existence of binary and decimal floating point numbers in 754-2008.
Binary and Decimal do not represent the same exact set. Many numbers are accurately representable in both sets however many other numbers are not members of both sets. This is not an issue of precision alone, even with a huge (but finite) number of bits binary FP numbers cannot accurately represent some of the decimal FP numbers. (However, with enough precision decimal FP can represent any binary FP number.)
In general, binary FP is faster and is geared to scientific SW while decimal is geared to financial and human centered SW.
This is similar to what we have in inf-sup versus mid-rad where they represent different sets and each is geared for a specific application as Michel clarified:
This seems a good place to remind everybody of a point I have made
in the past: there are two conceptually different interpretations of
intervals: as ranges of possible values (where infsup is definitely
superior), and as imprecise single values (where midrad seems preferred).
We need to come to grips with that distinction, because it affects our
expectations for how various operations are to be defined.
However, I differ with Michel on the issue of having mid-rad as a "secondary" type where it receives a "second class treatment" and does not get its own interchange format. I would go for a "different" type with clearly defined conversion rules between the two types just as 754-2008 does between binary and decimal. We will have to live with some inexact conversions if a program decides to use both types.
What do other people think?
--
Hossam A. H. Fahmy
Assistant Professor
Electronics and Communications Department
Cairo University
Egypt