(j3.2006) Interval arithmetic

[Malcolm Cohen]

Van Snyder wrote:
> Of course Malcolm knows I intended to conflate these things instead of
> engaging in the hair splitting necessary in the standard.
>   
No, of course I did not know you intended to deliberately obfuscate your 
statements and derail discussion.
>
>>  happen?  Most hardware does not require that.
>>     
>
> The only FP registers in Intel chips are the old x87 FP stack with
> 80-bit registers, and the XMM and MMX registers which contain one (MMX)
> or two (XXM) 64-bit floating-point values.
That is incorrect.  Those registers can also contain single precision 
values (both scalar and packed).  For a trivial example of use see the 
ADDSS instruction.  In fact IIRC a common complaint about SSE1 at the 
time was that it didn't support double precision!

All these claims that hardware/software does not and can not conform to 
IEEE 754 (that being what your claims amount to) are unconvincing and 
unhelpful (and so far as I can tell, unfounded).
> but the answer to interp F95/000104
is completely irrelevant to our ability to provide interval arithmetic 
capable facilities.  As you know, we ended up basically not doing that 
anyway, but that was for lack of enthusiasm not for lack of ability.

It's irrelevant not just because obviously if the hurdle is something we 
said in a past standard we could revise it for a new standard.  (In fact 
we did some of this for the IEEE module support, though admittedly some 
of it could be better explained or less ambiguous.)  And it's doubly 
irrelevant because it's talking about intermediate values of intrinsic 
type in a single expression; any user-written interval arithmetic 
package would perforce have been using individual statements to compute 
individual values - so the interp you hate the answer of just does not 
apply.

It's certainly clear that any interval arithmetic package using the IEEE 
modules to do rounding control will have all the information re rounding 
etc. right there in front of the data flow analyser so it *can* round 
each computation in the required way.  All this talk of register spills 
making it impossible are simply mistaken.

I'm not going to address most of your message as it seems 
irrelevant/incorrect - or too rhetorically argued.  Yes, we know you 
didn't like our answer to that interp.  Which wasn't about the effects 
of doing IEEE manipulations using the IEEE modules anyway.  Personally 
it's still my belief that leaving arithmetic specifications to the 
arithmetic standard and not the Fortran standard is a good thing; I 
understand that there are valid arguments for and against.
> I didn't see anything in the standard that says a default real function
> result value can't be returned in a double precision register.
Or indeed, that it cannot be returned via smoke signals from our ears.

Arguing from a Fortran 95 interp quoting document 97-007 tells you 
*NOTHING* about what happens when the IEEE modules are in play.  It's 
just the wrong document.  There are many subtle interactions in the 
F2003 document so even the same words might have the same meaning but 
not the same ramifications.

> It's a problem arising from the answer to interp f95/000104
You keep saying this.  I do not agree that the answer to this interp is 
wrong, causes a problem, or indeed is relevant to the question at hand.

> All 14.4
> and 14.11.21 say, however, is that results have to be rounded in a
> certain direction, not to what precision they have to be rounded,
That is not so, it says right there what the actual result is.  The 
actual IEEE 754 standard also has words to say on this matter for it is 
in their purview.

Finally: sometimes we cannot work out how to make the standard force 
someone to "do the right thing"; but this doesn't mean that the case is 
hopeless.  In the past that came under the umbrella of "Quality of 
Implementation".  It also, quite often, falls into the domain of other 
standards (like, for example, IEEE 754).  I seem to recall we even have 
some kind of binding that facilitates using 754 features from Fortran, 
which would seem to lead us back to the square one of "the facility is 
already (optionally) there".

Bob Corbett wrote:
> Given that members of the committee cannot agree which expressions are
> affected by the IEEE modules and which are not, what good are they?
>   
I sympathise, really I do, but I think there are many cases that are not 
ambiguous and that most/all reasonable people can agree on.  With 
careful coding that means one can do a good number of things portably 
with the IEEE modules, even without the paranoid coding one occasionally 
needed to do in the past to get things to work portably.

Anyway, I don't there would be much controversy that when the 
appropriate IEEE_FEATURES constant is accessible, the expression (using 
the IEEE datatypes) that the processor evaluates conforms to the IEEE 
standard in the stated ways.  That's not necessarily the literal 
expression the programmer wrote, but does have to be one mathematically 
equivalent to it.  There are hard cases, but they would all seem to be 
avoidable - and when doing interval arithmetic, the user will be 
avoiding those anyway.

Cheers,
-- 
.........................Malcolm Cohen, Nihon NAG, Tokyo.