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?



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