Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: A question Re: Level 1 <---> level 2 mappings; arithmetic versus applications



> 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