(j3.2006) Interval arithmetic

[Malcolm Cohen]

Van Snyder wrote:
> On Wed, 2009-03-18 at 18:47 -0700, Malcolm Cohen wrote:
>   
>> You have yet to come up with a single concrete example of code.
>>     
>
>   pure real function add_up ( x, y )
>     use, intrinsic :: ieee_arithmetic
>     real, intent(in) :: x, y
>     call ieee_set_rounding_mode ( ieee_up )
>     add_up = x + y                             ! Instant one
>   end function add_up
>   
Well somehow I was expecting an interval arithmetic example, since you 
claimed that was what was impossible.

> The answer to question two in interp f95/000104
Broken record.  That interp made NO CHANGES to the standard.

It drew conclusions about what F95 (not F2003) said about certain 
abstract questions.
>  (which hasn't been
> refuted in f08) allows the processor to compute x+y in double precision
> at instant one,
Not according to c14 it doesn't, at least not with USE IEEE_FEATURES 
(which you didn't use) and use of IEEE_SELECTED_REAL_KIND on the 
declarations (which you also didn't).

c14 was not present in F95 in any way, shape, or form; so if one is 
arguing about that, *ANY* F95 interp which didn't even mention IEEE as 
it happens is an elephant.
> The standard doesn't
> prohibit inter-statement optimization,
Actually it nearly always does effectively prohibit it.  But most people 
want faster programs; after all, their programs are mostly buggy 
already, who cares about a few non-standard-conforming bits here and there?
>   
>> Some packages existed and worked before VOLATILE existed, so no, when
>> I actually looked they didn't.
>>     
>
> Well look again for yourself if you don't believe Christian Keil or any
> of the other members of P1788.  The packages existed, but were found
> _not_ to work.
Except of course when they did.  At least they were claimed to at the 
time, and I have no doubt whatsoever that they did work - at least the 
ones using NEAREST rather than the nonexistent rounding mode fiddles.  
P1788 can say that these didn't work because of rounding until they're 
blue in the face, but that doesn't make it true because in fact those 
ones DID work.

I have no doubt that using rounding mode fiddles with a compiler than 
doesn't expect them is doomed to failure!  Even after the IEEE modules 
came about, I have no doubt that some/many compilers had bugs in their 
implementation and maybe still do, but that's hardly the fault of the 
standard.

AND IN ANY CASE, you claimed impossibility.  That would seem to have 
been a gross exaggeration - we're down to "have to occasionally use the 
VOLATILE attribute" at most, and probably "have to occasionally use the 
VOLATILE attribute on x87" in reality.
>   The cause of the problem was found to be exactly as I
> explained.  That's why implementors started shoving results through
> volatile variables.
>
>   
>> There certainly is a place for volatile when intermediate calculations
>> *inside the interval package itself* have to be correctly rounded, at
>> least on x87.
>>     
>
> This shouldn't be necessary,
Yes, something *SHOULD* be necessary on x87, otherwise you are dooming 
all x87 programs to worse performance for the benefit of slow-anyway 
intervals.  Intervals will always be slow on anything, that being the 
nature of the beast.

In fact the majority of user programs benefit from intermediate 
calculations being carried out in extended double rather than single.

If the interval arithmetic package writers are using floating-point 
functions like your one above instead of subroutines that shows that 
even interval arithmetic experts can fall into the well-known (and 
easily avoided) traps in ordinary Fortran.
>  and it took a long time to discover that
> omitting it was a source of error.
This isn't a new problem, people wrote about this in the 1970s at the 
very least (the need to "sanitise" results).  Probably in the 1960s as 
well for that matter, but my memory doesn't go back that far.
>   We really shouldn't expect everybody
> to understand the subtle interaction between f95/000104, rounding mode,
> and volatile.  The standard should require it to work correctly as the
> text + 7.1.9
There is no 7.1.9 in F2003.

And no, the standard should not require programs to be executed slowly.  
If people want that they can write in Java.  That has not been held to 
be an outstanding success on the numerical performance front.
>  appear to require.  I think interp f95/000104 means it
> doesn't.
You can think and say whatever you please regardless.  Since F95/000104 
didn't actually say anything more than what the standard already did 
say, it's hard to draw many conclusions from it.  In fact, since F95 did 
not actually have the features we are discussing, anything you drew from 
it would be a confusion not a conclusion.
>   If it does, please tell me where.  Just shouting "P754 +
> Clause 14" doesn't convince me.
>   
I did earlier and you just ignored me.

It is the text you earlier claimed "only specified the direction" and 
which I pointed out did not.  14.3, 14.8 and 754 do the trick easily.  
In particular,
   - the normalised numbers match ieee_single or ieee_double exactly
   - rounding conforms to 754 [and that specifies the result]
   - "rounds the exact result to the nearest representable value".
Since the representable (normalised) values are fully specified, that 
does the trick.  Yes, I think you do need to do "USE 
IEEE_FEATURES,ONLY:IEEE_DATATYPE,IEEE_ROUNDING", otherwise the processor 
is free not to have conformant representations and/or rounding.

There are, in fact, lots more requirements in F2003 than there were in 
F95.  Most of them only come into play when the user specifically asks 
for them, fortunately; and this is one of those.  (There are a number of 
other "exact" result specifications in F2003, unfortunately some of them 
operate all the time, boo hoo.)
> Is it too much to ask for at least a note in 14.4 that advises a
> processor not to carry a result of higher precision than implied by the
> kind demanded by 7.1.9 across a change of rounding mode?
They talk about generals always fighting the last war, and here you are 
asking for help to fight the x87.  Forget it.  Intel and AMD have done a 
much better job than you have already, but it will still take time to 
mop up the casualties.

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