Re: Discussion on tetrits motion
> From: "Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>
> To: "Dan Zuras Intervals" <intervals08@xxxxxxxxxxxxxx>
> Cc: "P1788" <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Discussion on tetrits motion
> Date: Sat, 24 Apr 2010 14:11:00 -0500
>
> Dan Zuras Intervals wrote:
> >> . . .
> >
> > Very well. Even though this motion is NOT about any
> > specific decoration, I grant that a decoration like
> > 'domain' is a likely property that we will want to
> > track with the decorations described in this motion.
> >
> > There is a whole rather involved topological argument
> > I am working up to form a framework for deciding what
> > makes a good decoration or not. But I am trying to
> > save that argument for a future discussion followed
> > by a future motion.
> >
> > Still, you are correct: I will use that argument to
> > argue that we should have a 'domain' decoration.
> >
> > Given that, what is it about THIS motion you would like
> > to discuss?
> >
> > And, if possible, can you perhaps frame your discussion
> > so that it applies to any or at least many properties
> > for which this motion likely applies?
> >
> > It might help to keep the discussion within the context
> > of THIS motion.
> >
> > Thanks,
>
> I did frame a discussion of this motion as it applies to the "domain"
> attribute in my post yesterday. It is still relevant.
>
> I fear such an analysis demonstrates the proposed propagation mechanism
> would be a setback for P1788; it deviates too far from the semantics we
> agreed on in Motion 8. For example, Motion 8 specifically identifies the
> purpose of decorations is to help disambiguate between
> X \union {empty} = X and X \union NaI = NaI,
> where "NaI" is really some bare decoration. But the definitions being
> proposed in the current motion implicitly "undo" this disambiguation,
> leaving us, to some extent, back where we originally started about a year
> ago.
We have not yet discussed a definition of an NaI.
Nor even the need for one.
So I'm not sure how to sensibly respond to this.
>
> I believe a priority mapping, as outlined in my position paper, is required
> to overcome this difficulty and integrate the very nice idea of tetrits into
> a reliable exception handling mechanism consistent with Motion 8 semantics.
> Although I have made a position paper available, there has not been any
> discussion about it in the short time before the current motion.
>
> I'm a little skeptical that we really need to partition decorations into
> "most recent operation" vs. "history," but if there turns out to be a
This, I will grant you, may or may not be useful.
I believe it has diagnostic value but it may not have
value for the sort of branch & bound algorithms that
are favored in interval methods.
It is also something I realized could be cleanly done
only recently. When I realized that I could split
the evaluation of 'thingy'Sticky from the evaluation
of 'thingy'False, two things became possible.
(1) The separation of which you speak.
(2) The circuit paths needed to evaluate these bits
became independent of one another.
The value of the former may or may not ultimately be
of use to us as you suggest. But since it became
cheap to provide it I felt it was a good idea to do so.
The influence of the latter is a bit subtle. You see,
if we are to ultimately realize the value of interval
methods in fast hardware then that hardware will have
to incorporate interval circuits into the ordinary
instruction pipe much like floating-point circuits
are incorporated today. And, with floating-point
circuits, the exceptions that can happen during a
calculation (overflow, & the like) are all computed
late in the pipe. This becomes a problem when these
things are tested by later instructions (also in the
pipe). Things like branches & stores must be
accomodated or aborted by interlocks based on the
value of such an exception. These interlocks are
expensive both to design correctly & for the ultimate
performance of the machine in question. For, even if
they do not happen on any given interval operation,
the pipe must often be paused until that is known.
Performance suffers.
Well, decorations are pretty much our 'exceptions'
as far as this problem is concerned. They will
become things that can be tested & branched on. So
anything we can do to make them easier or faster to
calculate aids the hardeare designer in this task.
And the user with a faster computer.
That's what separating the calculation of 'thingy'False
& 'thingy'Sticky does for us.
In a sense it is a cheat. Because it means that the
thing we want to test for to find out if anything bad
has happened to us in the 'thingy' sense is ('thingy'False
\or 'thingy'Sticky) rather than 'thingy'Sticky alone.
But as that test comes later in the pipe it is one step
easier to compute the 'or' at that time than if it were
done in the interval operation itself.
Perhaps I should have explained all this before.
I guess I did not think it an important issue.
Still, that's what these discussions are for.
> compelling reason to do this, and if the collective wisdom of P1788 decides
> to go down this path, then I believe we need a total of 4-bits:
>
> -- 2-bits for "most recent operation," as defined in section 2.1 of my
> position paper
>
> -- 2-bits for "history," as defined by the priority mapping in section
> 2.2 of my position paper
>
> Otherwise, at a minimum, we need only the 2-bits of history as described
> above.
>
> Sincerely,
>
> Nate
>
This is another distinction that is made by assumption
in this motion.
As I mentioned in my cover letter, while this motion
does not formally place any constraints on the nature
of 'thingy', this motion DOES assume that 'thingy' is
the sort of property that is normally true in the sort
of functions we consider in interval methods. Say,
mostly continuous functions of mostly bounded evaluation
of intervals that are mostly within its domain.
The implication is that so long as these things are true,
there is nothing to worry about & nothing worthy of note
to keep track of.
Therefore, the thing we want to watch out for & the thing
we want to remember is situations in which the normal
state of affairs is NOT true. These are the things that
might need special treatment. These are the things that
might indicate a fault in our calculations. At the very
least, these are the things worthy of our consideration &
attention.
Thus, the things that are remembered are occurances of
'thingy'False. These are swept up into 'thingy'Sticky
& presented to the user as something of note.
The history of 'thingy'True is not considered note worthy
in this sense & is therefore not kept around.
But I think you will find that it can be mostly deduced
from the states of 'thingy'False, 'thingy'Sticky, & the
nature of the current interval.
However, I make no such claim at this time as to do so
would be a further digression from the intent of this
motion.
Anyway, that's the argument for only 3 bits only one of
which is sticky.
Does that all make sense?
Dan