For Programmers: Free Programming Magazines  


Home > Archive > Fortran > September 2005 > Handling zero**-2.0 in CVF?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Handling zero**-2.0 in CVF?
Stig Kildegård Andersen

2005-09-02, 6:58 pm

I am having a problem with floating point exception handling in CVF6.6c. I
can handle divide by zero, overflows, and invalid operations such as
sqrt(-2.0). But if a program encounters the operation 0.0**(-2.0) it always
crashes with the run time error:
forrtl: severe (696): Real zero raised to negative power

Is there a way to avoid this behaviour, so that this exception can be
handled just as any other of the usual floating point exceptions divide by
zero, overflows, and invalid operations?

Best Regards and Thank You in Advance,
Stig Kildegård


Steve Lionel

2005-09-02, 6:58 pm

On Fri, 2 Sep 2005 15:39:04 +0200, "Stig Kildegård Andersen"
<SearchForMyFullName@google.com> wrote:

>I am having a problem with floating point exception handling in CVF6.6c. I
>can handle divide by zero, overflows, and invalid operations such as
>sqrt(-2.0). But if a program encounters the operation 0.0**(-2.0) it always
>crashes with the run time error:
>forrtl: severe (696): Real zero raised to negative power
>
>Is there a way to avoid this behaviour, so that this exception can be
>handled just as any other of the usual floating point exceptions divide by
>zero, overflows, and invalid operations?


I'm having difficulty constructing a test case that gives this specific error
- depending on various options I try, I get NaN, Infinity, or an M6201 domain
error.

Try various combinations of /check:nopower, /fpe:0 and /math_library:fast

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
Jim

2005-09-03, 6:57 pm


"Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
news:kd2hh1lmbphb01a4ard9tvl8f89vvnru77@
4ax.com...
> On Fri, 2 Sep 2005 15:39:04 +0200, "Stig Kildegård Andersen"
> <SearchForMyFullName@google.com> wrote:
>
>
> I'm having difficulty constructing a test case that gives this specific
> error
> - depending on various options I try, I get NaN, Infinity, or an M6201
> domain
> error.
>
> Try various combinations of /check:nopower, /fpe:0 and /math_library:fast
>
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://developer.intel.com/software/products/support/

I suspect that the problem comes about as the result of the formulation of
the equation. Don't compilers implement raising a floating point number to
a floating point power as:
a**b where a and b are real numbers can be evaluated as exp(b * ln(a)). The
natural logarithm of zero does not exist; hence whatever the operation
returns is bogus.
Jim


Tim Prince

2005-09-03, 9:56 pm

Jim wrote:
> "Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
> news:kd2hh1lmbphb01a4ard9tvl8f89vvnru77@
4ax.com...
>
>
> I suspect that the problem comes about as the result of the formulation of
> the equation. Don't compilers implement raising a floating point number to
> a floating point power as:
> a**b where a and b are real numbers can be evaluated as exp(b * ln(a)). The
> natural logarithm of zero does not exist; hence whatever the operation
> returns is bogus.
> Jim
>
>

If this happens to work in Fortran, it is likely to be by the use of a C
library pow() function. That function has to check for negative integer
exponents, and handle them separately.
Mr Hrundi V Bakshi

2005-09-04, 3:56 am


"Tim Prince" <tprince@nospamcomputer.org> wrote in message
news:XAsSe.1103$pt.789@newssvr27.news.prodigy.net...
> Jim wrote:
CVF6.6c. I[color=darkred]
divide by[color=darkred]
/math_library:fast[color=darkred]
of[color=darkred]
number to[color=darkred]
The[color=darkred]
> If this happens to work in Fortran, it is likely to be by the use of a C
> library pow() function. That function has to check for negative integer
> exponents, and handle them separately.


So, what does Fortran handle? fcuk all but you already know that or not.


Jim

2005-09-04, 6:56 pm



"Jim" <j.n@nospam.com> wrote in message
news:rXmSe.471$6e1.306@newssvr14.news.prodigy.com...
>
> "Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
> news:kd2hh1lmbphb01a4ard9tvl8f89vvnru77@
4ax.com...
> I suspect that the problem comes about as the result of the formulation of
> the equation. Don't compilers implement raising a floating point number
> to a floating point power as:
> a**b where a and b are real numbers can be evaluated as exp(b * ln(a)).
> The natural logarithm of zero does not exist; hence whatever the operation
> returns is bogus.
> Jim
>

After further review, I now see what is wrong.
Firstly the error message is correct, and the OP should have been able to
recognize this.
The return value from raizing zero to any integral power is zero. Raising
zero to any real power should return an error.
The translation of the OP's equation is:
1 / (0.0 ** 2) since most compilers understand that a ** (2.0) is equivalent
to a**2 (for example).
This always amounts to 1/0 which is an undefined operation.
Regards,
Jim


Richard Maine

2005-09-04, 6:56 pm

In article <F%DSe.188$eQ7.180@newssvr21.news.prodigy.com>,
"Jim" <j.n@nospam.com> wrote:

> Firstly the error message is correct, and the OP should have been able to
> recognize this....


The OP *DID* recognize it. You have misread the whole point of his post.
He knew that it was an error. His question was about whether there was
an associated error handler - like there is for other similar errors.
glen herrmannsfeldt

2005-09-06, 7:56 am


(mostly previously snipped question about 0.0**(-2.0)

> I suspect that the problem comes about as the result of the

formulation of
> the equation. Don't compilers implement raising a floating point

number to
> a floating point power as:
> a**b where a and b are real numbers can be evaluated as exp(b *

ln(a)). The
> natural logarithm of zero does not exist; hence whatever the operation
> returns is bogus.
> Jim


Well, just as bogus as dividing by zero or other math exceptions.

One thing, though. 0.0**(-2), with an integer power, is normally not
done with exp and log, at least not in Fortran, but by the reciprocal
of the integer power done through squaring and multiplying.

Also, even with a**b implemented with exp and log, it would seem
usual to test before calling the log routine, so the error would
come from the power routine and not from log.

-- glen

Stig Kildegård Andersen

2005-09-15, 7:57 am


"Steve Lionel" <Steve.Lionel@REMOVEintelME.com> wrote in message
news:kd2hh1lmbphb01a4ard9tvl8f89vvnru77@
4ax.com...
> On Fri, 2 Sep 2005 15:39:04 +0200, "Stig Kildegård Andersen"
> <SearchForMyFullName@google.com> wrote:
>
>
> I'm having difficulty constructing a test case that gives this specific
> error
> - depending on various options I try, I get NaN, Infinity, or an M6201
> domain
> error.
>
> Try various combinations of /check:nopower, /fpe:0 and /math_library:fast
>
> Steve Lionel
> Software Products Division
> Intel Corporation
> Nashua, NH
>
> User communities for Intel Software Development Products
> http://softwareforums.intel.com/
> Intel Fortran Support
> http://developer.intel.com/software/products/support/


Thank You all for answering. I was out of the country for some days - sorry
for the late follow up.

With regard to an example to reproduce the error You could, for example,
add the line "C = B**(-2.0)" to the sample file CLEARFP.F90 from the CVF6.6c
samples without changing anything else in the workspace.

With regards to the difficulties in reproducing the error I can only say
that I get the error message on both an Athlon64 desktop and a centrino
laptop with or without permutations of the suggested compiler options.

Thank You again,
Stig Kildegård Andersen


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2009 codecomments.com