Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Discussion paper: what are the level 2 datums?

Dan Zuas wrote:

From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
To: "John Pryce" <j.d.pryce@xxxxxxxxxxxx>,
 "stds-1788" <stds-1788@xxxxxxxxxxxxxxxxx>
Subject: Re: Discussion paper: what are the level 2 datums?
Date: Thu, 7 Oct 2010 07:37:01 -0500

John Pryce wrote:
> Nate, and anyone else who can elucidate
>
> My sister is staying for a few days so I send this as I wrote it before
> Nate's Oct 6 email on bare decorations, which I haven't time to absorb
> yet. Nate, forgive me if your explanation answers many of my concerns.
> Also, if my language is a bit OTT.
>
> On 5 Oct 2010, at 18:17, Nate Hayes wrote:
>> In my opinion, there is a large degree of compatibility and overlap
>> between the proposed NaI and a bare decoration. In other words, the >> NaI >> is mostly serving the same purpose as a bare decoration. This >> shouldn't >> come as too much suprise, because it was the intention of Motion 8 >> that a 
>> "bare decoration" is NaI.
>
> This brings into the open the fact that despite much study I do not
> understand what a bare decoration (BD) is, as Nate understands it.
>
> To me, Nate's BD seems inconsistent, in both its nature and its > purpose. 
>
> It is clear from Motion 8 §2.1 that bare decoration is a _type_ in the
> same way as bare interval is a type, but Nate seems to treat it as a
> _value_.
>
> For illustration, suppose we have agreed on these decoration prits as a
> level 2 model:
>  domain, a tetrit d with values 0 to 3.
>  continuous, a bit c with values 0, 1.
>  well-formed, a bit w with values 0,1.
>
> Assume types REAL, TETRIT, BIT have been defined. Suppose the interval
> part ivl is in inf-sup format with two REAL's. Then we can define
>  typedef struct{REAL inf; REAL sup;} INTERVAL; //bare interval
>  typedef struct{TETRIT d; BIT c; BIT w;} DECORATION; //bare decoration
>  typedef struct{INTERVAL ivl; DECORATION dcw} DINTERVAL; //decorated
> interval
>  ...
>  DINTERVAL XX ...;
>
> If REAL means binary64, and the decoration part dcw is held in 1 byte,
> then a whole decorated interval occupies 17 bytes.
>
> That is the only semantics a sane person can get from Motion 8 §2.1 and
> preceding, and anything that contradicts it must be WRONG.
>
> Further, the Motion 8 forgetful operation that "drops" the decoration > part 
> is quite unambiguous. It simply extracts the interval field, and
> conversely for dropping the interval part. Equivalent to:
>  INTERVAL xx = XX.ivl;
>  DECORATION dec = XX.dcw;
>
> In the above, the bare decoration dec is a 1-byte _variable_ from which > I > can extract whatever values are currently in d,c,w. And I can > re-assemble 
> XX from xx and dec if I want.
> (Probably the API must prevent the application programmer doing these
> things if w is false, because that flags an ill-formed object.)
>
> Nate, if you want your BD concept to mean something different from > that, > then don't call it "bare decoration". If it's a specific _value_, > packed 
> into a bare interval's 16 bytes, as you seem to indicate, then call it
> "bare interval NaI".


No.

The problem is you are conflating Level 2 names and objects with Level 3
representations (i.e., implementation code and structures). That is the
source of confusion.

A "bare decoration" is a Level 2 concept. Period.

So is a "bare interval".

Your example is entirely Level 3.

A pair of binary64 values at Level 3 is _not_ a bare interval. It is only
one possible Level 3 representation of a bare interval.

A pair of binary64 values (or, in light of recent e-mails with Dan and
Michel, a pair [NaN,x], etc.) is also a possible representation of a bare
decoration.
Don't try to apply Level 2 names and concepts to Level 3 objects, as you are doing in the above e-mail. This is wrong, plain and simple. You have always 
been an advocate of the Levels model. This is one example where not being
careful to distinguish between Level 2 objects and Level 3 representations 
is leading to confusion, I believe.

Nate


Nate,

First let me acknowledge that a level 2 concept of
bare intervals or bare decorations can answer to no
criticism at level 3.  And perhaps John missed that
detail with his sister over his shoulder. :-)


This is true. :-)
In all sincerity (and without malice to John or his sister), it is also the way it is supposed to be in a level model.
This holds for all our other IEEE 1788 Level 2 concepts as well, such as implicit vs. explicit i-datatypes, etc. 





Still, I think John's criticisms go to the motive
for having bare intervals & bare decorations.  And
by claiming they live only at level 2 you are only
ducking that question.


No I'm not! :-)
I'm giving it a solid answer: that the mathematical meaning, functionality and usefulness of these objects is understood entirely at Level 2. Trying to explain it in terms of Level 3 objects only leads to unnecessary confusion.
The mappings into Level 3 are purely issues of implementation and design. For example, this is how one goes about creating a functioning implementation that has predictable properties and is not based on ad-hoc design choices or preferences, etc. 




At level 2, bare intervals & bare decorations also
have no notion of storage.  They are defined by the
set of things they represent not the number of bits
it takes to represent them.


Right.
In fairness, I think Motion 8 was not so explicit about this. I hope that this can be cleared up by now. What you say above is exactly correct. Thanks. 




Let us assume for the moment that we deal with them
entirely at level 2.  At that level a bare interval
is not so much an interval without decorations as an
interval for which the decorations have no meaning.


No!
At Level 2, a bare interval is an element of overline-IR. Period. This includes closed real intervals and the empty set. 



Similarly, a bare decoration is something for which
the interval part has no meaning.
No. A bare decoration is just an abstract object representing the state of various decoration attributes, e.g., the "domain" tetrit or a "defined and continuous" bit, etc. 

A bare decoration has no interval part.




But I think we can assume that is not your motive.


Right. See above (and below).





For if it were it would simply be something that
introduces the possibility that the thing that has
no meaning or the thing being ignored might admit
errors down the line.  Or, at the very least, cause
problems for a correctness proof.


Exactly.

This is why in Motion 8
   bare intervals
   bare decorations
   decorated intervals
are specifically singled-out and defined as different Level 2 objects, each with its own meaning; and that precise rules about how these objects may be used in arithmetic and non-arithmetic functions or operations are also provided so that the result is a reliable Level 2 system of computing.
One really important example is that it should never be possible to construct a decorated interval from just a bare decoration. Another important example is that it should never be possible to convert a bare decoration into a bare interval (e.g. the empty set) or vice-versa.
If Motion 8 did not make distinctions between these three Level 2 objects, then as you point out there would be no consistent mathematical model to ensure that some implementor won't design a system that allows a "moral equivalent" of a bare decoration to be converted into an empty set, hence causing some unintentional catastrophic failure of a branch-and-bound algorithm, for example. 




Therefore, we must assume that there is some other
motive.


Right. See above (and below, again).

It sounds to me you are getting the gist of it.

I hope my comments are helping even further.





If that motive is to save space or the time needed
to compute something that will go unused, then that
motive lives at level 3.

Is that the motive?


The Level 2 model is the primary motive, for reasons described above.
However, the Level 2 model _does_ also anticipate that at Level 3 there will eventually be issues of storage space and efficiency that will come into play.
This is why, for example, there are both bare intervals and bare decorations as opposed to just decorated intervals. The assumption is that for certain implementations, always computing with decorated intervals will be overkill (in fact I think this is actually true for just about all practical interval implemenations I can think of).
Therefore, the Level 2 model anticipates that some interval implementations and/or algorithms will choose to use only bare intervals at some times and only bare decorations at others. But the Level 2 model does not in any way dictate or require how users and/or implementors make those decisions. It defers those decisions to implementors, users, compiler designers, hardware engineers, language committes, library vendors, etc., assuming that those people are the experts in thier respective fields and can make the best decisions in that regard as to when and/or how to use bare intervals vs. bare decorations etc.
But the Level 2 model does dictate the terms, rules, and conditions that those implementation experts must follow to ensure their final product conforms to the standard and is also a reliable system of computing. For example, it decrees that no implementer shall allow a bare decoration (or its moral equivalent) be converted to an empty set, etc.
That way, despite the platform-specific implementation choices various implementors may end up using, missiles will still hit thier intended targets and planes won't fall from the sky. :-) 

Sincerely,

Nate