(j3.2006) Interval arithmetic

[Van Snyder]

Malcolm Cohen wrote:
> 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.
>   

Whether a type is intrinsic or merely understood by the compiler is 
obviously a distinction without a difference, for purposes of this 
discussion.

>> The only FP registers in Intel chips are the old x87 FP stack 
>> with80-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)....
>   
>> but the answer to interp F95/000104
>>     

allows a single-precision result to be carried around as a 
double-precision value in those kinds of register.  Malcolm says this
> is completely irrelevant to our ability to provide interval arithmetic 
> capable facilities
>   

but it's not.

> 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.

Which is true at the point of the computation, but f95/000104 allows the 
result to be created and carried indefinitely in a precision different 
from the one implied by the kind demanded by f95:7.1.4.

> 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.

The effect of an interpretation is not limited to the question 
originally asked.

> 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.
>   

The IEEE standard specifies how to round the results of computations, 
and how to round when converting from higher precision to lower 
precision, but specifies nothing about the relationship between those 
two events, which is the topic of the current discussion.

>> 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.

To  get back to f95, let's use 14.3 and 14.10.20.  Neither one of these 
says "the result of an expression shall be rounded to the precision 
implied by the kind demanded by 7.1.4" or anything that can be 
interpreted to imply that.  In fact, f95/000104 says exactly the 
opposite.  This means that IEEE_SET_ROUNDING_MODE controls the rounding 
of computations to the precision chosen by the processor, and controls 
the rounding during conversions between that precision and the precision 
implied by the kind demanded by 7.1.4, but says nothing about the 
relationship between the rounding modes at those two events.

> The actual IEEE 754 standard also has words to say on this matter for it is in their purview.
>   

The IEEE standard doesn't say anything about the relationship between 
rounding when an expression is evaluated in one precision and when its 
result is later rounded to a different precision, which f95/000104 
allows to happen, and to happen at different instants.

> 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 is true and absolutely irrelevant to the problem. The problem is 
that evaluation is explicitly allowed to result in value with a kind 
having precision more than that of the kind demanded by 7.1.4, and 
converting the result to the precision implied by the kind demanded by 
7.1.4 is allowed to occur at a different instant from evaluation.  Since 
these are different instants, it is possible for the rounding mode to be 
changed between them, and that is the problem.

> 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.

and that's irrelevant to the problem, too.

> I'm not going to address most of your message as it seems 
> irrelevant/incorrect - or too rhetorically argued.  

So here's a more concrete and less rhetorical exposition.

Suppose a program does the following:

   use, intrinsic :: IEEE_ARITHMETIC
   real :: A, B, X
   real, external :: F
   volatile :: X
   call IEEE_SET_ROUNDING_MODE ( IEEE_NEAREST )
   X = F(a,b)
   print *, X

in which F sets the rounding mode to other than nearest before it
evaluates its result.

F95:14.10.20 says IEEE_SET_ROUNDING_MODE sets the current rounding
mode.

F95:14.3 Says the current rounding mode is set back to nearest
when F returns.

Interp f95/000104 says the representation and precision of the
value of the expression that computes the result of F need not be
as demanded by f95:7.1.4, and does not specify when the result of
an expression is required to be represented as demanded by 7.1.4.
In particular, it does not require the result of F to be
represented with the precision implied by the kind demanded by
7.1.4.

Therefore, the "current" rounding modes might be different within F
and when the result of F is stored into X.

Is the processor required to use the same rounding mode at these
two instants, or is it allowed to use the rounding modes that are
current at the different instants?

If the answer is "they can be different," there really is no point in
setting the rounding mode.

If the answer is "they have to be the same," there are at least the
following possibilities:

1.  Dataflow analysis can always carry the rounding mode from
evaluation to storing.  I do not think this is possible if an
external function returns a single-precision result in a
double-precision register, or by smoke signals that have higher
precision than demanded by 7.1.4, both of which the answer to
interp f95/000104 allows.
2.  The processor has to round all high-precision representations
that are different from the precision implied by the kind demanded
by 7.1.4 to the precision implied by that kind whenever the rounding
mode changes.  This means it has to do so upon return from a
procedure in which the rounding mode is changed.  The desire NOT
to do this was one argument that led to the outcome of interp
f95/000104, which diminishes my confidence in the "quality of
implementation" answer.
3.  Programs should store results for which the rounding mode is
important into volatile variables.  That is, F should include
  volatile :: TEMP
  temp = expr
  F = temp
This is a very heavy hammer.


Possibilities 1 is probably impossible in general, possibility 2 is 
opposed by the desires for performance that led to the answer to interp 
f95/000104, and possibility 3 is undesirable.  Ultimately, to give 
programs explicit control over rounding at all instants when it might 
occur, the standard could provide an attribute that specifies the 
rounding mode to be applied when a value is stored into a variable.