Re: Tagged intervals (Was Branch & bound for not everywhere defined constraints)
Corliss, George wrote:
> "Arnold Neumaier" <Arnold.Neumaier@xxxxxxxxxxxx> wrote:
>
>> Corliss, George schrieb:
>>
>>> Isn't the P1788 standard for the interval that DecoratedInterval
>>> would decorate? That is, our class Interval is the SIMPLE
>>> interval. Sure, we want it to be as rich and expressive as we can
>>> design, but we should expect that in many applications, the
>>> expressive power will come from application-specific decorations,
>>> so the core class Interval can remain SIMPLE and FAST. Then
>>> applications that do not need decorations will enjoy good
>>> performance.
This seems to be admission decorated intervals are mostly to be avoided
whenever possible, since they are not as fast or efficient as SIMPLE
intervals. What is a decorated interval, anyhow? Basically it is just a
thread-safe variant of a simple interval encapsulated with its global/local
flags state.
With a few standardized NaIs, applications that would otherwise need
decorations can continue to be SIMPLE and FAST; it reduces the number of
applications that may actually need decoration.
>>
>> We need to specify what support 1722 should rerquire that enables
>> programmers later to do with the decorated intervals whatever they
>> want to do.
> ABSOLUTELY, and I should have made that point. We DO want to include
> hooks essential to building class DecoratedInterval. I do not really
> favor simplest possible; I just oppose overly complicated.
>
Or even better yet: what is minimum complication 1788 should require that
enables programmers to avoid decorated intervals altogther!
>
>> If no flags or equivalents for PossiblyUndefined etc. are provide
>> then a user who wants to program decorated intervals that propagate
>> a PossiblyUndefined decoration will have to do that the same way as
>> it is done now, which means inefficiently and with lots of effort:
>> every operation must be reprogrammed!
> Violently agree.
I don't think anyone has suggested flags can't be specified, even if NaIs
exist. We can have both, if necessary.
>
> I think one consequence of viewing P1788 as a basis for many classes
> DecoratedInterval is to prefer the relative simplicity of a flag
> PossiblyUndefined (or equivalent) to the relative complexity of
> multiple NaIs, but I'm still listening to the arguments there.
The 128-bit SSE registers on existing Intel and AMD processors are
partitioned into four 32-bit single-precision IEEE floating-point values.
But the MXCSR only has one set of IEEE flags (underflow, overflow, invalid
operation, etc.). The flag state of the MXCSR is the logical-OR of the
exceptional state of all four floating-point values in a register. For
example, if the invalid operation flag is set in the MXCSR, this means "the
processor reports that at least one of the four floating-point values in the
SSE register was an invalid operation." The hardware does not provide any
further information, e.g., which of the four floating-point values actually
caused the invalid operation.
How would a user initialize a decorated interval in this case?
The AMD Programmer's Reference Manual recommends using NaN payloads to
help
determine which of the four floating-point values actually caused the
trouble. However, this is a punt, since IEEE 754 does not standardize any
NaN payloads.
1788 has the opportunity to rectify this problem by standardizing a small
but important set of NaIs.
Nate Hayes