The history of the word 'format' in 754...
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>
> Cc: "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Bare decorations (was ...level 2 datums)
> Date: Sun, 17 Oct 2010 11:48:20 -0500
>
> John Pryce wrote:
> > Nate, P1788
> >
> > . . .
> >
>
> >
> > Some of our basic assumptions differ so we come to different conclusions.
> > I'll try to avoid the word "confusion".
> >
> > Consider 754 floating point. Let Real denote a particular level 2 format.
>
> My understanding is that a "format" is a Level 3 concept (see below), hence
> from my perspective you're already off-topic.
This nomenclature problem is my fault.
At least, in part. Twice.
754 does indeed use the word 'format' for the
floating-point data sets defined at level 2.
This was done over my great objection & I
suggested the use of the more natural word
'datatype' for 1788.
The history of the problem is that in 1985
we used the word format but did not make any
distinction between the data sets & the way
numbers appeared in memory. Indeed, there
was no reason to because the representations
for binary were fairly natural one-to-one &
onto mappings from the data elements to the
biased exponents & signed magnitude
significands.
15 years later in the 21st century we had
more modern nomenclature to think about &
decimal to include into the standard. And
the representation for decimal is NOT so
natural.
So we needed a different name for each.
Many names were proposed. My suggestion of
'datatype' for the data abstraction seemed
right in line with current complier thought
on the matter but the compiler guys in the
room didn't like it. In the end 'format'
was chosen.
Having used 'format' for the abstraction we
needed another word for the level 3 memory
layout. 'Encoding' was chosen. It is a
good word.
But I still feel it leaves 'format' ambiguious
in the common usage.
Therefore, I suggested to John that he use the
word 'datatype' for you guys.
Perhaps I should not have.
A literal use of 754 wants to have the words
'format' & 'encoding'. But I have found that
exactly the confusion that has come up here
follows the word 'format' in this use of it.
Let me suggest that we use the words 'datatype'
& 'encoding' & avoid the use of the word
'format' altogether.
I have no problem with this group being guided
by 754. But let's not be hamstrung by it.
There is much to criticise about it. And its
often obtuse nomenclature is right up there.
BTW, on some of the other details mentioned
recently, 754 defines no set called "Real".
There are languages that do that with one
meaning or another according to the language.
And, NaNs (or one NaN) do (does) live at
level 2 in 754.
For us, I think the question comes down to
whether or not we will have NaIs. If we do
not, fine. But if we do, putting them at
level 2 seems a natural place for them. It
makes them elements of the data abstraction
defined there just like every other interval
is an element of that abstraction.
In that way I believe it will be possible for
our definition of intervals & all operations
on them to be written at level 2.
A laudable goal, IMHO.
>
> >
> > I think Michel Hack and others told us that modern compilers can handle
> > 17-byte datatypes efficiently by storing the 16 bytes and the 1 byte
> > separately -- especially in the case of large DInterval arrays -- even
> > though they are conceptually one object.
>
> I would not use a 17-byte datatype in my software or products.
>
>
> Nate Hayes
>
This is interesting to me.
Nate, do you plan to never or perhaps seldom
use decorated intervals in your work?
It would explain much about your arguments
in the recent past.
Dan