0.**0.=1. ?

[dnoack]

Hello,
I am somewhat surprised about the mathematics of the compiler. In the analytical mathematics 0.**0. is indeterminated. In contrast to that, the compiler gives 0.**0.=1. . IMHO this is not a good idea, because this is a jump, since 0.**x=0. for all x>0.

The compiler action results in the following gag:
If I have none apple and I do nothing with is, I get an apple.

Furthermore the compiler solves 0.**x=0./0.="infinity" for x<0. This is also indeterminate and therefore not correct.

Please can anyone explain to me this curious results.

Thanks,
Dieter

[TimP]

0.**0. is a point of non-portability, as Fortran compilers aren't required to follow the expert consensus, as ifort (and even Google) do. This of course is based on the fact that x**0. == 1. for all positive finite x, and x**0 == 1. for all finite non-xero x.



I think you have a typo later in your post. 0.**x for x .lt. 0 is 1./0.**abs(x)



In a somewhat similar matter, even expert consensus may change. The original IEEE754 standard defined the result of atan2(0.,0.) to be NaN, but that didn't achieve general acceptance, and now that NaN is burnt into a lot of chips, the traditional *nix result, from before NaN was invented, is accepted.



I didn't find the key to Googling up full references on this matter. I did find some hits which led to dead ends. Here is a correction for a URL served up on some of the searches: http://www.netlib.org/paranoia/

That diagnostic program tests behavior of some of these exponentiation cases, among others. The author took a position, but does not assess adverse marks against compilers which violate his position.

Message Edited by tim18 on 04-07-200609:32 AM

Message Edited by tim18 on 04-10-200605:03 AM

[dnoack]

Hallo tim18,
thank you for your reply.

Fortran is a language, which will be used predominant for solving scientific problems and I also work in this field. Therefore the results of a program should be correct according to the mathematics. I think, it make no sense to tune the results only for the fact, that the program runs nice and the users are pleased.

If there is an error in the mathematical formulation, the program should rather abort, than provide paranoia results. Basically the execution cannot continue, if an invalid value appears.

I have a large program system and cannot test every possibility for such paranoia. Is there a compiler option available, to abort the execution if such a
paranoia appears?

Thanks,
Dieter