Re: The history of the word 'format' in 754...
Dan Zuras wrote:
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.
...
Let me suggest that we use the words 'datatype'
& 'encoding' & avoid the use of the word
'format' altogether.
I'm ok with your suggestion that "datatype" should be Level 2 and "encoding"
should be Level 3. I have less concern what are the names than that we do
choose some names and then apply those names consistently at the various
levels. Otherwise, chaos will reign.
However, both of your name suggestions do make sense to me.
The suggestion that Level 2 should be a "datatype" mostly agrees with my
understanding of the modern definition in computer science of an "abstract
data type" or ADT for short. Bertrand Meyer, author of the Eiffel
programming language, defines an ADT in purely mathematical terms. In
particular, each ADT is defined by its types, functions, axioms, and
preconditions (if any).
For example, Motion 8.02 defines an ADT of "interval data" by:
-- its types: bare interval, bare decoration, and decorated interval
-- its functions: addtion, subraction, multiplication, sqrt, various
constructors, forgetful operators, etc.
-- its axioms: "a decorated interval may be constructed from i) a bare
interval or ii) a bare interval and a bare decoration but iii) never from a
bare decoration", "any arithmetic operation on a bare decoration results in
a bare decoration", etc.
To follow your suggestion further, then, Level 3 is the appropriate place to
speak of "encodings" of the "interval data" into various concrete
representations that actually require bits and bytes. For example, one can
have a 16-byte Level 3 encoding that represents either a bare interval or a
bare decoration, depending if certain encoding conditions are met, e.g., if
the encoding is a pair of doubles [NaN,NaN] then the encoding may represent
a bare decoration, etc. (assuming of course the decoration bits are then
also somehow encoded into the payload of the NaNs).
I have no problem with this group being guided
by 754. But let's not be hamstrung by it.
I agree.
There is much to criticise about it. And its
often obtuse nomenclature is right up there.
I think 754 has done a rather remarkable job separating the various levels,
but as you point out some aspects could perhaps use further clarification.
In P1788, we also have the concept of "decorated intervals" which has no
direct analogue in IEEE 754, either. So this also requires some fresh
thinking.
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.
This is all my understanding, as well.
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 fully agree, and have had my sights set on this goal, as well, since
Motion 8.02. Progress is being made, though I agree some work is yet to be
done. However our analysis here at Sunfish is the underlying Level 2 model
in Motion 8.02 is rock-solid. We have spent lots of time and effort studying
this the past year or so and find more and more it works for all our
examples and desired use-cases.
We like it so much, even if P1788 decides to abandon it we probably will
continue to use it anyways.
>
> 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.
Decorated intervals are very useful as a theoretical device. They also play
a crucial role in terms of interval constructors, i.e., they provide a
precise mathematical model to help us understand how to initialize interval
data.
Other than that, however, I see that decorated intervals have very little
practical use or significance in real-world interval computing applications.
There are not any real-world interval algorithms I know of that can't be
computed purely in terms of bare intervals, bare decorations, or some
selective combination of the two.
I don't claim this means there are _no_ practical uses for decorated
intervals. People may find some.
All I'm saying is that the real emphasis should be on bare intervals and
bare decorations. That's where the real performance and utility is.
Nate Hayes