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

Re: Constructors & decorations

John Pryce wrote:

Dan & P1788

On 23 Feb 2010, at 12:17, Dan Zuras Intervals wrote:

John Pryce had written:

I believe not. I think the intention of Motion 8 is that once
an interval is set notValid, _all_ its other attributes become
meaningless. It has fallen into a black hole. So a V- interval
is essentially the same as NaI. It follows that all query-functions
on it should give results of maximum meaninglessness:
- Its other decorations should be D0 C0 B0.
- Its lower & upper bounds, midpoint, radius etc., should all
return NaN.


So it seems that you are reserving the interpretation
of 'Valid' things to those things which are imported
into intervals from other arithmetics.  Constructors,
converters, & the like.


Yes.


Does that not seem like a particularly narrow use for
a decoration?  Would not 'Defined' do as well?


The Motion 8.02 document says on p3:

-- inv is the decoration of an interval created by an invalid
conversion
...
we may have ...
(X,ok) \union (Empty,inv) = (X,inv)
as an unambiguous version of X \union NaI = NaI.


This seems to me to agree with my interpretation.

'Defined' has a quite different and specific purpose, to do with the
applicability of fixed-point theorems.


... I say this because decoration bits might end up being
expensive things some day.  If we are successful &
intervals find their way into hardware, decoration bits
will become state bits.  They will have interlocks &
busses devoted to them.  They will be saved on context
switch.  They will become involved in issues of
parallelism & cache coherency.  We should make sure
they are useful.


I am not a hardware guy so maybe I have the wrong end of the stick.
But didn't Nate argue for decorations, in contrast to global flags,
precisely on the grounds that
- they are fast because they are attached to the individual data
item, hence
- they don't need to be in state bits
- they don't need interlocks or busses
- they are NOT part of a context switch
- they don't affect parallelism & cache coherency more than any other
kind of data


John,

There is no contradiction in what Dan says.

For example, decorations can be considered by implementer as NaNs with
payload. The payload of the NaNs are then truly "state bits." Circuits that
process these state bits will need busses of some sort that lead to logic
gates.

Anything we include in a future interval standard will ultimately need to be
reduced to these concepts. If we cannot do this, the standard will be quite
useless.

Even if the decoration concept is abandoned and we return to global flags,
all the same thorny issues about constructors, boundedness, etc. continue to
exist. However, then we are left with a standard that dictates how
implementers must design their hardware... even if much more optimal or
efficient solutions are available (and they are).

IMO, there is no complexity in the actual decorations. That mechanism is
simple. The challenge before P1788, I believe, is to understand and
articulate the exceptional conditions in the interval arithmetic. Motion 8
simply forces the issue.

I think one of the biggest gaps between our current set of accepted motions
and practical implementations is the notion of unbounded intervals. It is
easy to deal with unbounded intervals on paper, but difficult in a finite
floating-point representation within a computer. I think a great deal of
complexity could be potentially eliminated from the standard by considering
only compact (closed and bounded) intervals.

Nate