Re: A question Re: Level 1 <---> level 2 mappings; arithmetic versus applications
John,
I complletely disagree
see my comments
Juergen
John Pryce schrieb:
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.
...
That is not necessary. we have reasonable arithmetic for bounded intervals
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".
no No NO
We are NOT defining a set of different specialised arithmetics.
But we design an abstract specification of interval arithmetic
That is my view of level 2, an abstract data type. that will hopefully
have a set of representations and implementations (level 3)
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?
we have already stated that in motion 2 (Ithink)
but wait for the proposal to redefine level2 as an interface
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.
The practical programmer will use the best concrete implementation for
her application.
The system programmer may implement his own implementation of the interface
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.
IEEE 754 provides a list of useful types.
tightness belongs to the specification in level 2
Does that sound sensible?
John Pryce
No, not at all
But I don't think that we are far away
You may look at an interface as a family of implementing types, but I
prefer to use it as its own concept:
An interface is an ADT with
methods to access inf, sup, mid, rad
specification of operations with tightness bounds
Juergen
--
-
o Prof. Dr. J. Wolff v. Gudenberg, Informatik II
/ \ Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o Tel.: +49 931 / 31 86602
/ \ Uni E-Mail: wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
o o Wuerzburg