mid-rad, inf-sup, a caution...
> Date: Sun, 9 May 2010 19:31:54 +0300
> Subject: Re: mid-rad, inf-sup, etc.
> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> Dear 1788,
>
> 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
>
Hossam's analogy is an excellent one. The issue of mid-rad
versus inf-sup is, for us, very VERY much like the the issue
of binary versus decimal was for 754. Like binary & decimal,
mid-rad & inf-sup each have their adherents & appripriate
application areas. Not only are the underlying mental models
different in the two forms, the very concept of precision &
range is defined differently with mid-rad being able to
represent some intervals more precisely & others badly or not
at all. Similarly, one cannot say that Decimal64 is more or
less precise than Binary64 in that some numbers are more
precise in one & some more precise in the other.
His analogy is so good that I am persuaded that we should
consider giving mid-rad full first class status.
His analogy is also so good that a caution applies.
You see, when we started our revision work in late 2000,
we were only going to make some minor changes to update the
25 page 1985 document (a couple of bug fixes, defining FMA,
that sort of thing). But when we convinced ourselves that
we should include decimal into the standard it meant that
the standard needed to be entirely rewritten in a mostly
radix free form.
What most people on the 754 committee are unaware of is that
Prof Kahan, David Hough, Mike Cowlishaw, Jeff Kidder, myself,
& others met twice a week for over a year to work out the
details. It was a LOT of work. But we got it done.
Still, when the results of our work got back to the full
committee, there were many changes & additions. Most of
clause 9 (transcendental functions) was added. We were
forced by circumstance to admit two completely different
encodings for 'standard' decimal interchange formats.
(Something I opposed as much as the position of chairman
allowed me to do. But they are in the document all the
same.)
And the 2008 standard is now 70 pages. It took us 7 years
to get everyone to agree to it all. And many of the
agreements were reluctant at best.
The analogy should be obvious. A standard that admits both
mid-rad & inf-sup is a much harder standard to write. Such
a standard would have to be written with largely 'form free'
language. We will need to investigate technical issues that
have likely gone unconsidered in the literature up til now.
We will have to write the constraints of the standard in
language that admits both interval forms but admits of only
one answer in each form.
So my caution is twofold.
I like Hossam's approach. But it carries with it a lot of
work that we will have to all learn & agree to however long
that takes.
And, if we go that route, I think we should start now. It
is still early. Very little is cast in stone at the moment.
So if we decide to do this there is a chance we can avoid
some of the delays that plagued 754.
But we must all be willing to compromise.
A lot.
Dan