Re: NaI's as decorated empty sets
Nate Hayes schrieb:
Arnold Neumaier wrote:
Nate Hayes schrieb:
Arnold Neumaier wrote:
This leads to an interesting possibility:
Perhaps we should treat NaI's as decorated empty sets!
This would make their processing fast, people who don't need them
can throw away all decorations and only need to propagate the
bare intervals, while those who can/need employ decorations
and/or NaI's can do so, too.
If I understand properly, this is a very neat idea.
It would basically mean users have one of three options:
-- use the whole decorated interval,
-- throw away the interval portion, or
-- throw away the decoration portion.
Is that about correct?
Yes.
It is a brilliant idea, Arnold.
I think it is good semantics to identify NaI with decorated empty set.
A good compiler can detect what is really needed/used and
choose the most efficient alternative, including early return
for partially evaluated expressions when the needed portion of
the result does not depend on the remainder of the evaluation.
It also eliminates the problem that even interval addition would
become significantly slower if an NaI would have to be encoded
in the interval portion itself.
Would it be ok to leave this one possibility on the table, though? i.e.,
that an implementation might somehow encode the NaI decoration into the
bits which would otherwise be the [double,double] of the interval? I
agree in software you are correct, and we want to keep addition as fast
as possible. But in hardware the encoding would essentially be free and
it might also be a practical and effective option. However, if we take
the time to examine the cost in software, there might be some clever
bit-hacks to make it viable, as well. Or there may be ways to word the
standard to allow a software implementation to do it one way and
hardware another. Bottom line, your idea opens up a whole new horizon of
rich possibilities regarding flexibility in the implementation, so I
would prefer to keep this door open for further investigation, if you
would be agreeable to that.
Yes. I think the standard does not need to specify how the functionality
is implemented, only that it is present. Thus there are
-- intervals,
-- decorations,
-- decorated intervals,
-- operations defined on intervals, decorations, and decorated
intervals, in a consistent and well-specified manner, and
-- forget operations that drop either the decoration or the interval
Implementors may represent a lonely decoration as they wish,
hence they can use a byte format or a 2-float format such
as [NaN,decoration] or something else, whatever they prefer.
The standard should be silent about how things are actually
represented, and only specify the effect of operations on
the representations (whatever they are).
Moreover, the various possibilities for savings in hardware
implementations can be left to the hardware builders since
the standard need only specify the functionality and not the
low level encoding itself.
So it seems now time to collect the necessary decorations.
Candidates are
CertainlyUndefined
PossiblyUndefined
DefinedButPossiblyDiscontinuous
InvalidConversion
Nonstandard
Nontight
Inaccurate
which fit comfortably into one decoration byte.
One more decoration fits the byte, so we can add
IsUnbounded
(sometimes one may want to skip the remainder of a computation
when intervals are no longer bounded; this allows to monitor that).