(j3.2006) F03/0084, was Re: Interp letter ballot #25

[Malcolm Cohen]

Van Snyder wrote:
>---  -N-  F03/0084   IEEE_SET_ROUNDING_MODE in a subroutine
>            One of the reasons given for not needing to add interval
>            arithmetic to the work plan for 2003

It was actually in the work plan for 2003 for quite some time.  It lost support.

> was that the effect
>            could be provided using the IEEE facilities.

That was not the reason it lost support.  Even after it lost support, there was 
still a subgroup tasked with providing "enabling facilities" for it.  Grumbles 
that that subgroup did not do a very good job might well be reasonable, but have 
little to do with this interp.

Furthermore, many compilers support non-IEEE floating point.  The NAG compiler 
has done so on some systems since 1.x (probably with x==0) and continues to do 
so.  Playing with the IEEE rounding mode doesn't help in those cases either!

>  If one writes
>              CALL IEEE_SET_ROUNDING_MODE(IEEE_DOWN)
>              V%LOW_BOUND = X * Y
>              CALL IEEE_SET_ROUNDING_MODE(IEEE_UP)
>              V%HIGH_BOUND = X * Y
>            perhaps naively

The observation that properly implementing interval arithmetic methods cannot be 
done naively is correct.

> hoping that the processor will actually
>            round in the specified ways and produce different results
>            for the low and high bounds, it would be a nasty surprise
>            to find that in fact the values are always identical.

(1) Implementing interval arithmetic was not a significant part of the IEEE 
module facilities, which indeed began life as purely exception handling, and was 
not limited to IEEE arithmetic.

(2) Not inhibiting efficient execution on existing and possible future IEEE and 
IEEE-like hardware was an explicit goal of the IEEE module facilities.  Allowing 
compilers to continue to use existing optimisations was seen as highly 
desirable.  There is a wide class of computing devices for which Fortran 
performance would be severely negatively impacted if exact reproducible results 
across all machines were to be required by the Fortran standard - this precise 
effect has already been seen with the Java debacle (they have since relaxed 
their reproducibility requirements, at least in some circumstances).

(3) This interp contains no edits - the answer is based solely on the text of 
the standard.  Rescinding the permission for the processor to evaluate a 
mathematically equivalent expression has never been part of the IEEE TR, 
subsequent Fortran standards, or the expressed intention of the committee.

(4) Even though the standard does not say it completely explicitly, in practice 
making everything VOLATILE will almost certainly get you your desired outcome, 
though at a some performance cost.  If you are providing interval arithmetic 
through functions rather than writing naive code inline, only those functions 
would need to do that.  Actually since changing the rounding mode is often 
expensive anyway, the performance cost from VOLATILE might well not be 
noticeable.

(5) Finally, although to a fair extent I share your lack of satisfaction with 
the current situation, I don't think that it is appropriate to change it via 
interp.  Not to mention that it really is not that obvious how best to change it 
anyway!  If we want to have some standard-mandated way of requiring precise IEEE 
evaluation of the precise expression the user wrote, I would see this as a new 
feature.  And when we're talking about new features, I think that rather than 
disabling optimisation in some heavy-handed way we should instead simply finish 
the job of the "interval arithmetic enabling subgroup" and add module functions 
for directed roundings of arithmetic expressions; it might be a bit clunky to 
write IEEE_MULTIPLY(X,Y,IEEE_ROUND_DOWN) but it would be a lot nicer than all 
those subroutine calls.  Done right it could even be disconnected from the IEEE 
modules and made available for all floating-point types.  That would provide 
those who need the directed roundings with them, without potentially 
inconveniencing other users or slowing down their programs.

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