Neil Carlson said:
>I'm irritated by an apparent inconsistency in constraints
>between user-written pure functions and intrinsic functions
>which are pure. A pure function is not allowed to do any i/o
>nor execute a stop statement, but many of the intrinsic
>functions do exactly this (or effectively so); for example,
>asin(2.0) produces an arithmetic exception, output to stdout,
>and halts execution of the program (NAG compiler). How is one
I agree that it is unfortunate that "PURE" functions are not allowed to
contain STOP statements. In the rush to eliminate side-effects (which
are only bad in a parallel context if they create indeterminancy) these
were ruled out (by the HPF Forum, whose work WG5 and J3 adopted) - even
though they are clearly useful (and would be safe).
BTW, If IEEE non-stop arithmetic is enabled (e.g. using the -ieee=full
option with the NAG compiler), ASIN(2.0) will not produce an
arithmetic exception that halts execution but a NaN value.
>supposed to write a pure function having a limited domain?
>Has this issue been addressed in F2K? My only thought is to
>execute something like "asin(2.0)" when the input is out-of-range
>to trigger the desired abort, but it's kludgy and one needs to
>watch out for compilers that are too smart (the NAG compiler
>recognized sin(0.0) as 0.0, so 1.0/sin(0.0) didn't work).
NB: +1/+0 is +INF (overflow) not NaN (invalid). 0/0 is NaN.
>Anybody have any a more elegant solution?
For functions returning floating-point values, raising an IEEE INVALID
exception *IS* a more elegant solution than executing a STOP statement
- if the user of your routine wants IEEE continuation with a NaN (or
INF) value that is what they'll get, and if they want to stop on
arithmetic exceptions they'll get an appropriate message there too.
There are two ways of raising an IEEE exception:
(1) use the IEEE modules (from TR 15580, also in F2002 draft)
(2) compute something that is infinite or invalid - whichever is most
appropriate to your case.
Again, option (2) is certainly the easiest in the real world (and is quite
often what the intrinsics do themselves!) - just make sure you are computing
with variables not constants.
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
