Re: Interval hardware and existing practice
On Tue, Sep 8, 2009 at 10:29 AM, Nate Hayes<nh@xxxxxxxxxxxxxxxxx> wrote:
> Ralph Baker Kearfott wrote:
>> Nate et al,
>>
>> See my inserted comment.
>>
>> Baker
>>
>> Nate Hayes wrote:
>>> Dan Zuras Intervals wrote:
>>>>> Date: Mon, 7 Sep 2009 14:50:05 -0400
>>>>> From: Nate Hayes <nh@xxxxxxxxxxxxxxxxx>
>>>>> Subject: Re: Branch & bound for not everywhere defiend constraints
>>>>> To: STDS-1788@xxxxxxxxxxxxxxxxx
>>>>>
>>>>> Dan Zuras Intervals wrote:
>> .
>> .
>> .
>>>
>>> I just want to see blazing fast interval hardware. Soon. If we make
>>> it easy for hardware vendors to retrofit intervals into existing
>>> floating-point hardware, like the SSE registers or the Larrabee VPU,
>>> I think it increases chances the hardware vendors will actually
>>> provide interval support.
>>
>> I agree strongly that there are big advantages to designing
>> the interval standard to fit into existing practice, where
>> such design does not seriously compromise other attributes
>> of the interval computation. I see this as particularly so
>> with regard 754-2008-conforming machines. I am also glad you
>> are considering trends in hardware.
>
> In my view, the problem with decorated intervals is they don't appear to
> provide any benefit or function that can't be achieved more simply and
> efficiently with a few standardized NaIs, which would retrofit very nicely
> into existing hardware.
>
> I think those in favour of decorated intervals need to show why they are
> absolutely necessary; even if this can be done, it should also be explained
> why we CAN'T also have NaIs for the branch-and-bound algorithms.
And we do need convincing reasons to include NaI at all. We have to bear
in mind that the specification will ultimately be implemented in some
programming environments, (C++, Fortran, computer algebra systems, etc.),
and make sure we do not impede on native programming supports. It would
be wishful thinking that somehow magically if we have a standard specification
it will material in hardware, and that programming languages will wholeheartly
adopt. I would like to remind folks that not just because a datatype is said
builtin into a programming language (e.g. 'long double') means it is actually
supported in hardware (e.g. PowerPC.)
There are higher chances of getting good compiler support if the abstractions
can be efficiently mapped to library artifacts -- all you'll need is
that compiler
front-ends recognize the abstractions and optimize accordingly. In my exprience
that has had more scalable success than alternatives that have been floated.
-- Gaby