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

Re: The history of the word 'format' in 754...



> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: The history of the word 'format' in 754...
> Date: Wed, 20 Oct 2010 11:46:50 -0500
> 
> Dan Zuras wrote:
> >> . . .
> >>
> >> > However making bare intervals a primary datatype at level
> >> > 2 creates a situation in which one intentionally computes
> >> > WITHOUT the information necessary to correctly interpret
> >> > the results.  The analogy would be computing in
> >> > floating-point WITHOUT computing the exceptions.  How
> >> > would one know if this infinity is the result of an
> >> > overflow or a divideByZero?
> >>
> >> Right.
> >>
> >> This is the desired situation in certain interval algorithms, hence
> >> a reason bare intervals should be first-class Level 2 types.
> >
> > Isn't concern for correct computing the
> > point of ALL interval algorithms?
> 
> It has been pointed out to me by John and Arnold that one sometimes wishes 
> to compute 1/[-1,1]=[-Inf,Inf] without generating an exception. So ask them.

	At level 2 this is indistinguishable from
	doing the operation on decorated intervals
	& not looking at the decoration.

	But this is not the example you want to cite
	to support your work.

	You want to use examples of bounded functions
	of known characteristics defined on bounded
	regions of 2-D arrays (or at least projections
	from 3-D onto 2-D) that are known to only
	undergo simple (say homogeneous)
	transformations that are known not to fail.

	In this case all the decorated intervals at
	level 2 could be safely replaced with bare
	intervals at lower levels WITHOUT THE RISK
	OF ERROR.

	This is the example that supports your case.

>
> . . .
>
> Now lets examine, closely, what happens if we smiply pass a bare interval to 
> the sqrt() operation, instead:
> 
> Motion 8.02 says a bare interval may be promoted to a decorated interval in 
> order to participate in arithmetic operations. Hence, the bare interval 
> [-1,4] is promoted to the decorated interval xx = ([-1,4],domain:(T,F)).

	Wait a minute: I don't want to argue with you
	about what motion 8.02 says but isn't promoting
	a bare interval to a decorated interval just
	the sort of thing we are trying to avoid?

	Also, & this is just a nit, I think it would
	be more clear in your examples if you decorated
	your intervals with the nature of the thing
	being recorded rather than the (T,F) value of
	the tetrit.  Something like outDomain or
	partiallyOutDomain or whatever rather than (T,F).

> 
> The decorated interval xx is then input to the sqrt() operation and the 
> exception is generated and recorded in the decoration of the decorated 
> interval output yy. So if I write a marcro or inline function:
>     bareOrDec(yy)
> that returns the interval portion of yy if the decoration of yy is "safe" 
> but otherwise returns the decoration portion of yy, then:
> 
>     bareOrDec(sqrt([-1,4]))
> 
> accomplishes the task.

	Hmm.  I'm not quite clear here.  A bare interval
	is one sort of thing & a bare decoration is
	another.  And you want a function that returns
	one thing under some circumstances & another
	under others?

	I don't get that.

>
> . . .
>
> >> Of course, with the bare decorations, there are decoration flags in the
> >> payload. So the branch-and-bound algorithm can also see exactly what
> >> exception occured, e.g., "possiblyDefined" vs. "notDefined" etc. It then
> >> uses this information to more optimally delete boxes from the solution.
> >
> > Decoration flags in WHAT payload?
> >
> > When have we ever discussed the 'payload' of a bare interval?
> >
> > What is it you have in mind here?
> 
> I'm sorry if I threw you off track:
> 
> There are decoration flags in a bare decoration.
> 
> I am NOT suggesting a bare interval carries any payload.

	OK, sorry.  My mistake.

> 
> . . .
> 

		Dan