(j3.2006) Interval arithmetic
Tue Mar 17 05:51:41 EDT 2009
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
>> 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
> 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
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
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
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
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.
More information about the J3