Re: NaI's as decorated empty sets
Arnold Neumaier wrote:
> 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).
I wholeheartedly agree with this entire view.
Nate Hayes