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



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. 

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.

> 	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
 


On 6 Jul 2010 at 15:43, Dan Zuras Intervals wrote:

To:             	Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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:      	Tue, 06 Jul 2010 15:43:15 -0700

> > Date: Tue, 06 Jul 2010 17:29:03 +0200
> > From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>, stds-1788@xxxxxxxx
> > Subject: Re: A question Re: Level 1 <---> level 2 mappings; arithmetic versus
> > 
> > Am 30.06.2010 23:11, schrieb Dan Zuras Intervals:
> > >> From: "Nate Hayes"<nh@xxxxxxxxxxxxxxxxx>
> > >> To: "Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx>,
> > >> 	"Ralph Baker Kearfott"<rbk@xxxxxxxxxxxx>
> > >> Cc: "P-1788"<stds-1788@xxxxxxxxxxxxxxxxx>,
> > >> 	"Dan Zuras Intervals"<intervals08@xxxxxxxxxxxxxx>
> > >> Subject: Re: A question Re: Level 1<--->  level 2 mappings; arithmetic versus applications
> > >> Date: Wed, 30 Jun 2010 15:05:39 -0500
> > >>
> > >> Dan Zuras wrote:
> > >>
> > >> . . .
> > >>
> > >> John has previously made the observation that there is an exact mapping from
> > >> Level 2 mid-rad interval to Level 1 interval. Of course, once at Level 1
> > >> there is then also an exact mapping from mid-rad to inf-sup (or vice-versa).
> > >> So the only conversion that requires care is mapping back from Level 1 to
> > >> Level 2. However, it seems there is some Level 1 mid-rad interval
> > >> corresponding to some Level 2 mid-rad interval that is provably the tightest
> > >> possible Level 2 enclosure, so long as that Level 2 enclosure is represented
> > >> by a midpoint and a radius.
> > >>
> > >> . . .
> > >>
> > >> Nate
> > >>
> > >
> > > 	Nate,
> > >
> > > 	I am going to pass on most of the content of your note
> > > 	to focus on this one statement because the fact that
> > > 	you state things in this way means I have not been
> > > 	clear.
> > >
> > > 	Level 1 is the set of all possible contiguous subsets
> > > 	of the extended Reals.
> > >
> > > 	Therefore there ARE NO mid-rad or inf-sups at level 1.
> > > 	Representations have no meaning there.
> > >
> > > 	Level 2 is some finite subset of the intervals that exist
> > > 	at level 1.
> > >
> > > 	What I am proposing is that the DEFINING characteristic
> > > 	of that subset be that the bounds be exactly (some say,
> > > 	losslessly) extractable as elements of some floating-point
> > > 	type F.
> > >
> > > 	Therefore, there are no mid-rad or inf-sups at level 2
> > > 	either.  Representations have no more meaning here then
> > > 	they do at level 1.
> > >
> > > 	All the formats live at lower levels.
> > >
> > > 	And I am proposing an approach that never speaks of them
> > > 	directly while still knowing that they exist&  taking
> > > 	care that some agreeable behavior is possible for them.
> > >
> > > 	That's all.
> > >
> > >
> > > 				Dan
> > 
> > 
> > Dan,
> > 
> > After having been quiet in the long discussion we want to congratulate 
> > you for clarifying the level structure.
> > 
> > Your new definition of level 2 is completely analogue to the 
> > specification of an interface (abstract data type) in object orientated 
> > programming. Where the methods are specified by pre- and 
> > post-conditions. The internal representation is not yet determined.
> > 
> > For example addition of two intervals A and B
> > 	pre: A, B in IR
> > 	post: (A + B).inf() == rnd_down(A.inf() + B.inf())
> > 	      (A + B).sup() == rnd_up(A.sup() + B.sup())	
> > 
> > Now implementation (level 3) with inf-sup-intervals is obvious. The 
> > mid-rad-guys have to proof if they can meet the specification.
> > 
> > 
> > We will put in a motion that the standard will be written in this manner.
> > 
> > Note that motion 5 already close to this definition.
> >   	
> > Best regards
> > 
> > J"urgen & Marco
> 
> 	Gentlemen,
> 
> 	While I thank you for your praise, I fear much of it is
> 	undeserved.
> 
> 	You see, my primary purpose in posting that note was to
> 	criticise Nate for confusing representations with the
> 	(otherwise unrepresented) Real intervals that live at
> 	level 1.
> 
> 	That may have been overly critical of me.  I have spoken
> 	to Nate in a more private forum since then & it turns out
> 	that he was merely discussing the Real analogues of
> 	intervals that could be DESCRIBED in inf-sup or mid-rad
> 	terms.
> 
> 	I have apologised to Nate in private & I apologise to him
> 	in public now.
> 
> 	Still, I agree with your point that objects at level 2
> 	should still remain an abstraction divorced from any
> 	representation which may live at level 3.  The clarity
> 	of this position is muddied, however, when there is one
> 	abstraction for inf-sup representations & another, quite
> 	different, abstraction for mid-rad forms.
> 
> 	I made a half baked proposal that level 3 representations
> 	be RESTRICTED to representing only those level 2 intervals
> 	with endpoints in a set F of numbers that can be found in
> 	some associated floating-point type.  And I showed how
> 	this might be done (primarily by slightly modifying mid-rad
> 	results).  But this proposal met with little support & none
> 	from the mid-rad folks.  So we are trying something else.
> 
> 	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.
> 
> 	Thus, the distinction between levels 2 & 3 will be less
> 	useful than might otherwise be the case.
> 
> 	I am not happy with it but it may be a necessary compromise.
> 
> 	Yours,
> 
> 				Dan



 Prof. Svetoslav Markov, DSci, PhD
 Dept.  "Biomathematics",                      phone: +359-2-979-3704
 Inst. of Mathematics and Informatics,       fax: +359-2-971-3649
 Bulgarian Academy of Sciences,              e-mail: smarkov@xxxxxxxxxx
 "Acad. G. Bonchev" st., block 8,       
 BG-1113 Sofia,  BULGARIA                      mobile (gsm): 0885871584
  URL: http://www.math.bas.bg/~bio/