Dear All,

Since the discussion started gravitating towards assessment of 
the quality of weather prediction, I'd like to note that 
the original subject was: is it a good idea to allow REAL 
expressions in SELECT CASE constructs.

Some of the replies in this thread were interesting but departed 
so far from the topic, that they do not have anything to do with 
the stated subject any more.

To recall the begginings: the syntax proposed by Van Snyder is:
> In 97-114, I proposed SELECT CASE (<expr>) ... CASE (r1 <= * < r2) ...
> where * is a place-holder that refers to the value of <expr>.

It is entirely new syntax - never allowed before. The novelties 
are: allowing REAL variables and using non-overlapping ranges. 
Whatever is it's intepretation it can't change the behaviuor 
of existing codes.             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^

It is a valid observation that the new codes using this syntax may
bahave differently on different machines. 
I 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. 
<snip>
> And, of course, the programmer has to include such numerical 
> tolerances in those places in the code where it matters. 
<snip>
> Scientific programming requires numerical literacy and handling 
> roundoff is just that.
(and I still support that view)

This gave rise to comments from both software writers and users 
that *any* change of behaviour of their existing codes is so costly 
that they'd rather not change *anything* in the language. The quotes 
follow:
John Bray wrote from the users perspective:
> For models as complicated as our forecasting model, sometimes the only
> way to ensure a hardware/compiler upgrade has worked is to get bit
> comparibility. For climate work, exact repeatability across many
> years is essential. One of the biggest issues of our C90 - T3E
> upgrade and MPP conversion was the precision changes due to the
> change in number format from Cray to ieee, and the calculation order
> changes required for MPP.

It's good to know why weather forecasts may miss the mark so badly. 
No connection to the topic of REALs in SELECT CASE, though. If you 
know your code is *so* unstable you just *can't* use REALs in 
SELECT CASE whether or not it is available in the language. So 
all you can say is: we, people who use F90 in weather forecasting, 
don't need it.

And Bill Long wrote from the software and hardware maker perspective:
> I could recount many stories about compiler upgrades resulted
> in slightly different answers for codes, usually due to improved
> optimization of addition sequences that resulted in different orders 
> of operation.
<snip>
> The certification procedures for their codes are so onerous that 
> making any change (even if it is an improvement) is essentially 
> impossible. The test for a new compiler is that the binary answers 
> are exactly the same as the certification run outputs.

And the same answer: codes that are to be certified that way should 
not contain REAL selectors in SELECT CASE. In fact, they'd better 
not use any floating point at all 8->

As for other resistance to REALs in SELECT CASE it was already 
dealt with, mostly by Van Snyder in his report and recent postings 
here.

I'm even more convinced now that REALs in SELECT CASE are a good 
idea. Now perhaps some more detailed discussion on how to do it 
rather than 'shoud we do it at all' might be interesting.

I'll start with some restrictions to consider:
a) allow *only* ranges when REAL selector is used, or at least 
   require/endorse a compile time warning if that was not true,

b) consider allowing empty ranges, i.e., range (2.0 < * <= 1.0)
   would be an empty range not overlapping with other ranges,

c) consider requiring such definition of ranges that they may 
   not possibly overlap regardless of the underlying floating 
   point (even though thay may be slightly different on different 
   machines). Alternatively consider emitting compile time 
   warning message when the compiler cannot determine if 
   the overlap is possible.

With b) and c) in place the code below (no statements, as we 
don't need them here):
  REAL a
  SELECT CASE (a)
  CASE( * <= MIN( b, c ) )
  CASE( b < * <= c )
  CASE( MAX( b, c ) < * )
  END CASE
would be correct regardless of whether b < c or b >= c. Without b) 
the below would still be correct (although it would not mean 
the same):
  SELECT CASE (a)
  CASE( * <= MIN( b, c ) )
  CASE( MIN( b, c ) < * <= MAX( b, c ) )
  CASE( MAX( b, c ) < * )
  END CASE

Obviously, the above requires more thinking. Let's think then!

Regards,
----------------------------------------------------------------------
Artur Swietanowski                mailto:[log in to unmask]
Institut fuer Statistik,  Operations Research und Computerverfahren,
Universitaet Wien,  Universitaetsstr. 5,  A-1010 Wien,  Austria
tel. +43 (1) 407 63 55 - 120      fax  +43 (1) 406 41 59
----------------------------------------------------------------------


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