Re: Empty interval representations (general)
> Date: Wed, 05 May 2010 10:12:56 -0500
> From: "R. Baker Kearfott" <rbk@xxxxxxxxxxxxx>
> To: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> CC: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Empty interval representations (general)
>
> That's an interesting stance since, I think (correct me if
> I am wrong), that, except for "big-endian" and "small-endian",
> 754 does specify formats. Of course, an argument for
> not specifying is: "it does not matter what's inside
> if what is actually seen is as specified."
>
> Baker
Actually, John turns out to be correct. And,
you too, in a way. But John has the intent
correct.
While 754 DOES specify formats, it is only the
interchange formats. How a system chooses to
represent its numbers for itself is not of any
concern to 754. Well, 754-2008, anyway.
What IS specified down to the last element is
the set of numbers that are represented in each
floating-point datatype, whether interchange or
not.
So if you say you are doing arithmetic in, say,
Binary64, everyone knows exactly what numbers
you are talking about. And Binary64 also has
an interchange format so there are bit patterns
available to allow you to give your numbers to
another system.
But you could just as easily say you are doing
arithmetic in a Binary65 & we would STILL know
what your numbers are. (Well, it needs to be
specified a bit more than that but its all in
the document.) Its just that in this case there
is no interchange format defined.
As for big-endian versus little-endian, even back
in 1985 that was solved by another data interchange
standard. (Was it 1596.5? I forget.) So 754
basically punts that problem by appealing to the
other standard by reference.
I think John is correct in that 1788 can pretty
much do the same thing.
More to the point, I think we should.
Dan
P.S. - This is different from but related to the
problem of mid-rad versus inf-sup. If they both
specified exactly the same set of intervals we
could ignore the implementer's choice & move on.
But they do not have the same set & we must deal
with that. The 6.1 text takes the first step in
coercing mid-rad into inf-sup but it does not
solve the problem. I'm not sure what the solution
is or even if we SHOULD coerce them to be the same.
I guess I'm hoping something will come up in our
discussions.
>
> On 5/5/2010 4:34 AM, John Pryce wrote:
> > Nate, Dan, everyone
> >
> > On 4 May 2010, at 14:56, Nate Hayes wrote:
> >> I still partly think P1788 only needs to specify bit-encodings for
> >> interchange formats and not internal representations of various conforming
> >> implementations.
> >
> > This remains my default position and I don't feel Dan or anyone else has made a convincing case for doing otherwise.
> >
> > John
> >
>