Re: A question Re: Level 1 <---> level 2 mappings; arithmetic versus applications
Dear Dan,
your detailed posting convinced me in
your intention to find a proper place for
the mid-rad format in the standard.
Up to now I was anxious about a possible preclusion
of the mid-rad form in the standard which IMO
will be certainly a big mistake.
I congratulate your idea to look for a compromise.
It seems to me that the idea about two "abstract data
types" (explicite and implicite) might be the correct
approach to such a compromise. I shall follow with
interest the developments in this direction and shall
try to be helpful as much as I can.
Best regards,
Svetoslav
On 7 Jul 2010 at 2:49, Dan Zuras Intervals wrote:
To: "Svetoslav Markov" <smarkov@xxxxxxxxxx>
Copies to: stds-1788@xxxxxxxxxxxxxxxxx,
Dan Zuras Intervals
<intervals08@xxxxxxxxxxxxxx>
From: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
Send reply to: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
Subject: Re: A question Re: Level 1 <---> level 2 mappings; arithmetic
versus applications
Date sent: Wed, 07 Jul 2010 02:49:06 -0700
> > 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