Re: A question Re: Level 1 <---> level 2 mappings; arithmetic versus applications
Dan, Marco, Svetoslav, P1788
A.
On 6 Jul 2010, at 23:43, Dan Zuras Intervals wrote:
> But it will likely force us to have one level 2 abstraction
> for intervals that are represented at level 3 by inf-sup
> forms. And another level 2 abstraction for intervals
> represented at level 3 by mid-rad forms.
That is not the way I look at it. Quite independently of Marco's email, the gang of six (Corliss, Hayes, Kearfott, Keil, Pryce, Zuras) had agreed that reviving the word "datatype" was a good idea. Here is the wording in the current draft of our position paper:
> An {\em interval datatype} ITbar is an arbitrary finite set of mathematical (level 1) intervals (plus possibly other symbols such as NaI), whose members are called (level 2) interval datums.
...
> Entire = [-oo,+oo] must be in ITbar. This ensures the interval hull always exists.
...and there must be a well-defined "hull" operation.
("ITbar" at present is TeXed as \overline{\mathbb{IT}}. Maybe, because of use of T for "text interval" in the IO motion, it would be better to use a D, for "datatype", instead of T, for "type".)
So, at level 2 we DO have a unified family of abstract datatypes:
inf-sup with binary64 bounds
mid-rad with binary64 mid and binary32 rad
other more exotic kinds
...
are all examples of "interval datatype".
B.
I personally would like the standard text to emphasise that at level 2 an interval xx is just a *symbol*, an atom, with no internal structure.
- It maps to a level 1 interval, which has internal structure,
being a set of real numbers.
The map is just the identity map, but conceptually there's
a huge difference between the levels.
- It maps to a level 3 object, which has internal structure,
being, say, an ordered pair of FP numbers.
Would this be a useful thing for the standard to say?
C.
On the other hand, as practical programmers we can *recognise* ITbar1, say, as "an inf-sup type" because it's easy to extract its lower & upper bounds exactly as FP numbers. And ITbar2, say, as "a mid-rad type" because it's easy to extract its midpoint & radius exactly as FP numbers.
D.
On top of this there is the sub-class of interval datatypes that are 754-conforming, for which one gets the extra tightness and efficiency of "formatOf" operations, etc.
Does that sound sensible?
John Pryce