(j3.2006) (SC22WG5.5355) [ukfortran] From a colleague

[Bill Long]

On Oct 28, 2014, at 12:38 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> On Tue, 2014-10-28 at 09:54 +0000, N.M. Maclaren wrote:
>> And the only good answer to what a logical IF should do if the operand
>> involves a NaN is to throw an exception.  The rule that comparisons on
>> NaNs always deliver False is every bit as horrible as (say) defining
>> an arithmetic IF to take the zero branch on a NaN.  Which would even
>> have precedent (Java real=>integer conversion)!
> 
> Better than taking the zero branch would be to execute the next
> statement, since the other three tests all fail.

It was not clear to me whether the original code was branching based on the value of a REAL or an INTEGER expression.  In the integer case, there is no question. 


> 
> Or, make its behavior processor dependent instead of undefined. At least
> then one could make minimal changes to the code, such as
> 
>  if ( .not. ieee_is_nan ( x ) ) if ( x ) 10, 20, 30
>  stop "Why is X a NaN??


Is that really an improvement?  It seems that someone willing to edit the source would better spend his time just eliminating the arithmetic IF in the first place.  Not do something like this (with the added need for USE statements).

I?m not convinced that trying to ?repair? arithmetic IF is a good plan.


Cheers,
Bill



> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101