Artur Swietanowski wrote:
> > | I agree that this form of CASE would be appropriate in many cases.

and I wrote:
> > In 97-114, I proposed SELECT CASE (<expr>) ... CASE (r1 <= * < r2) ...
> > where * is a place-holder that refers to the value of <expr>.
> > 
> > <large snip>
> >
> > One recently raised objection is that a program might have different
> > meaning on different platforms, or might compile on some, but not on
> > others, because different precisions and rounding methods might cause
> > REAL ranges to have different boundaries, or to overlap.  This is _no_
> > different from the situation with IF, except that with IF you don't get
> > any help from the compiler in the case when ranges overlap.  If the
> > compilers work correctly, one should be able to prevent overlap and
> > non-portable behavior by writing
> >     CASE (A <= * < B) ; ... ; CASE (B <= * < C) ; ...
> > or  CASE (A <= * <= B) ; ... ; CASE (B+NEAREST(B,1.0) <= * <= C); ...
> > (I prefer the first), except in the case when the ranges degenerate to
> > emptyness (and then the compiler should produce a message).
> > 
> > (This is, by the way, related to the reason to prohibit REAL loop
> > inductors: the number of "trips" might vary from platform to platform.)

and Artur wrote:

> Yes, quite obviously the program might execute differently. So what? 
> When I write a numerical algorithm I don't care to much whether 
> my program will give identical results on two different machines. 
> I *only* care whether it gives a mathematically correct answer in 
> both cases. In numerical analysis it means that the result will 
> fulfill certain accuracy criteria to a predefined relative accuracy 
> which is (has to be) orders of magnitude larger than the machine 
> precision.
> 
> That's the story with optimization, linear algebra, statistics, 
> approximation etc.
> 
> And, of course, the programmer has to include such numerical 
> tolerances in those places in the code where it matters. And 
> avoid them when it doesn't. One way or another it's the programmer 
> who decides. If he does it well, the differences between FPU's 
> will not matter for the result (but possibly change the exact path 
> the program travels). If he does not, it can only work by luck and 
> is likely to fail when he tries another example, even without 
> changing the computer, numerical library or compiler.
> 
> Scientific programming requires numerical literacy and handling 
> roundoff is just that.
> 
> Same arguments for REAL iterators in DO loops.

Artur is exactly correct.  These arguments carried absolutely no
weight when I proposed that J3 should extend CASE to real ranges,
including when I was present to advocate it.

In all of my numerical algorithms, I pay very close attention to their
behavior as they reach a boundary between two methods.  If the behavior
is discontinuous, I've done something wrong.  Otherwise, it doesn't
really matter which branch the software that implements the algorithm
uses when the argument is near the boundary.

(I try to design my approximations to be good for 30 digits, so if
there's a discontinuity of magnitude about 10**(-32) when computing
with, say, 40 digits, I have more work to do.)

If I specify boundaries so carelessly that regions overlap, I deserve
a headache.  It's actually _better_ if the compiler tells me about it
(as it would with CASE) than that it just happens silently at run-time
(as it does with IF).

Keep up the pressure, Artur!

Best regards,
Van


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%