From: "Svetoslav Markov"<smarkov@xxxxxxxxxx>
To: Dan Zuras Intervals<intervals08@xxxxxxxxxxxxxx>,
P-1788<stds-1788@xxxxxxxxxxxxxxxxx>
Date: Wed, 07 Jul 2010 10:29:28 +0300
Subject: Re: A question Re: Level 1<---> level 2 mappings; arithmetic versus applications
CC: Nate Hayes<nh@xxxxxxxxxxxxxxxxx>,
Marco Nehmeier<nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Dear Dan,
But this proposal met with little support& none
from the mid-rad folks. So we are trying something else.
As a "mid-rad guy", I am very happy with
your proposal to shift the inf-sup and mid-rad
concepts to lower levels. I congratulate this idea
and all your efforts in this direction.
Now I see that you are retreating from
your initial position, which is a pity. You say:
there is one
abstraction for inf-sup representations& another, quite
different, abstraction for mid-rad forms.
This is not so. The abstractions are exactly the same.
Those who claim that there is a difference probably start
the abstract model with defining first the set of intervals.
This is not the correct approach to an abstract model.
The correct one is the axiomatic approach, where only
the operations and relations are specified and the rules
for them. The specification of the supporting sets comes
later with the specification of the presentations (inf-sup
or mid-rad). To be more specific, in the case of addition
and multiplication by scalars we should state on level 1
that the interval system is a quasilinear space and that is all.
Luckily, interval spaces are much more adopted to computations
than number spaces, so now we should not follow exactly the
standard for fp-numbers.
Well, being an FP guy myself, I have always been more
comfortable with a bit more specificity than you
suggest here.
I feel you should not only specify the (finite) set of
objects (numbers or intervals) within your system but
the rules for arithmetic. Where arithmetic usually
boils down to doing the arithmetic among the Reals&
specifying some projection onto your finite set of
objects.
For floating-point numbers, the set was a collection
of signed integers of p digits in some base b (2 or 10)
scaled by a power e of the base (b^e) limited in
absolute value. The abstract elements +oo& -oo are
also added. All arithmetic takes place among the Reals
& the infinitely precise result is projected to the
nearest representable number by some criteron (nearest,
not less than, not greater than, etc.).
I feel the natural thing for intervals is to also
choose some set abstraction first. Arithmetic is still
done in the Real intervals with a tightest containing
abstract element being the natural projection.
But this is not easy to do with intervals. Or, at least,
not as easy as one might hope.
On level 2 the abstraction for machine number arithmetic should
come within the lines of prof Kulisch theory on computer arithmetic.
Your initial idea, I think, was close to his theory. Only then
on level 3, if still necessary, presentations like inf-sup and
mid-rad should be mentioned. This will make the standard
simple and clear.
Oh, I would dearly like to do something along these lines.
Something specific enough to allow the user to predict the
results. And something general enough to allow the
implementers more than one way to compute it.
But I don't know how. Not yet.
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.
I am very puzzled to see what these two abstractions would
look like. I beleive that Juergen and Marco will make an useful
proposal in the correct direction.
Svetoslav
Very well. I believe the distinction between our two
approaches to level 2 abstractions is that I (we) would
like the level 3 representation to be able to represent
the entire level 2 abstraction, no more, no less.
Let me give an example.
If we are agreed that the intervals at level 1 are all
contiguous subsets of the Reals (including those that
are unbounded), then the natural abstraction at level 2
is some finite subset of those.
One choice is the set of all contiguous subsets of the
Reals with bounds chosen from the set of elements of
some (already supported) floating-point set F. One
might call this THE INTERVALS ASSOCIATED WITH F.
For this level 2 abstraction, there is an easy& natural
level 3 representation in the inf-sup form or any of its
variants.
But the level 3 representations of the mid-rad form do
not to represent this set exactly. In some areas (the
very narrow intervals) they have many more elements&
in other areas (the very wide intervals) they have many
fewer (or none, in the case of the semi-infinite
intervals).
So, if we would like to keep this standard at the level
of data abstractions& above (a laudable goal), we are
presented with three possible solutions as I see it.
One way is to have two DIFFERENT level 2 abstractions
for our intervals. One suitable only for level 3
representations of the inf-sup form& another suitable
only for level 3 abstractions of the mid-rad form. Not
really a solution so much as a compromise, in my opinion.
Or, we could have some implementations (the inf-sups)
represent this abstraction exactly& still permit others
(the mid-rads) to only represent it approximately.
Or, we could try to CHANGE one of the representations to
MAKE it identical to the other.
This is where my suggestion to project an interval at
level 1 with Real midpoint midR& radius radR onto level
2 with
mid<-- roundToNearest(midR)
rad<-- roundAway(mid + radR) - mid
came from. This restricts mid-rad elements to those for
which mid-rad& mid+rad are exactly extractable as
elements of F.
But it is only a partial solution. It solves the problem
for narrow intervals but leaves the wide interval problem
still, ah, wide open. :-)
We were looking into a solution for that involving the
use of decorations for wide or semi-infinite intervals in
some offline discussions. However, when this directed
rounding projection met with no interest, we went another
way.
We are now looking into something more along the lines of
the middle approach. On the basis of a suggestion of
Nate's, we are currently trying to figure out if we can
live with one representation that EXPLICITLY represents a
level 2 abstraction& another that only IMPLICITLY
represents it. I hesitate to describe it further because
it is still in the works.
But if you are saying this is an approach that still has
merit to the mid-rad community, I would be interested in
further discussion on the matter.
I still feel the standard would be a better one if we
were able to couch it in terms of level 2 abstractions
that anyone can understand&, more importantly, reproduce
from implementation to implementation.
How do you feel about this?
Can you outline the approach that Juergen and Marco will
be proposing?
Perhaps there is some common ground we can all build on.
Dan