Re: Draft Standard Text, V02.1
George & P1788
On 16 Mar 2010, at 20:52, Corliss, George wrote:
> (John Pryce had written:)
>> Yes. BUT I am in favour of an inverse of the "string2interval" constructor we probably have agreed on. An "interval2string" with optional formatting, such that the output of the second is valid input to the first. Vienna has something, referencing one of Arnold's software packages for details, but it seemed over-elaborate to me.
> 1. Should there be an string2interval? Clearly, a working environment needs one. Do we expect Intel to introduce an assembly language instruction? Probably not. Hence, string2interval lies somewhere between BASIC hardware and a useful environment.
> ...
> ... I'm OK saying there will be a string2interval(), but we'll worry about its specifications later.
>
> 2. string2interval(interval2string())? Grudging acceptance, so long as we delay specifications.
>
>>> I fear that taking on language bindings makes the task large enough that we will not complete it.
>> It seems to me 754-2008 has gone a long way on this, and we can adapt some of its material. We *can* include something on this in P1788, even if we know it's incomplete when time runs out.
> OK.
>
> I continue to hope that Intel is a more important consumer of (y)our work than Maple.
Yup.
But there's several people saying just now "P1788 is a hardware standard", whereas a year or so ago we were emphasising "No, we CAN'T enforce any part to be implemented in hardware". So there's confusion going on, which needs removing.
I thought we had a consensus that P1788 is
- delta H above the hardware level
- delta L below the language level.
Intuitively I feel delta H is considerably smaller than delta L.
But not zero, which means we EXPECT Intel to implement some of it in software. Probably for ever. But what's the problem? It seems similar to the case of the exact inner product. I know little of these things, but it seems to me the boundaries between hardware, microcode and software are pretty fluid these days.
John