Fortran [FORTRAN] Division by zero allowed?

AI Thread Summary
The discussion revolves around a FORTRAN issue where dividing by a very small complex number (1e-20) results in a 'floating point exception' error, while another compiler handles the same code without issues. Users suggest that different compilers have varying default behaviors regarding floating-point operations and recommend checking the compiler's manual for options to manage such errors. There is a consensus that simply ignoring the error is risky and that it’s better to fix the underlying problem, possibly by using higher precision calculations or rearranging the formula. The original poster successfully resolved the issue by switching to a different compiler, g95, which managed the calculation without errors.
zstratto
Messages
6
Reaction score
0
Hi, I have an issue where I am squaring a very small complex number 1e-20 (FALFA2) which seems to make the value zero (both the real and imag part) and then dividing by it, the problem line is (all the numbers are complex):
GALFA = ( FBETA * FAA / FALFA2 ) - ( FAB / FALFA )

I get the error 'unknown floating point exception'. However, when another compiler compiled this code the executable works fine and I don't get an error for this (this is an old code that I am making some edits to now). Is there a way to just let GALFA=INF or something and continue, or do whatever the other compiler did (whatever that is)? Thank you!
 
Technology news on Phys.org
Do the calculation in double precision.
 
How exactly do I do that?
 
double precision or quadruple!

Different compilers do behave slightly different, by default, and there may be a way to control their behavior, too...you may want to read the user's manual for your compiler. I know that with g95, for example, one can set an environment variable to let the program continue or terminate on a "divide by zero" error.

I seem to recall seeing IEEE related function calls to control reporting this problems and behavior.

You can turn a blind eye and let the program continue, but what's the point? are you going to believe the results on a run like that?.

Or

...fix the program and guard against things like this...what is the order of magnitude of your numbers? when is a zero, zero?

Can you scale your problem and work with larger numbers?
 
tell which compiler you are using

post the commands you are using to compile the program
 
Hi Gsal,

I am using silverfrost (ftn95), and I am not really using any commands I just click 'compile'. And yes, I would just like to turn a blind eye. As I said, I have the executable that is the exact same code and it works fine, I just need to add a few write/print statements, but due to this issue I get the error I described.
 
Oh, boy...that is dangerous.

First you need a bit of help and you need to be willing to be a bit more diligent about this...nothing good can come out of turning a blind eye...maybe this task is in the wrong hands.

Second, I don't use Silverfrost, so, I cannot give details. Hopefully somebody will come along and give you step-by-step instructions on how to find out what the compilation command being used is and how to tweak it...OR, you could investigate yourself.

Good luck.
 
zstratto said:
How exactly do I do that?

Check your FORTRAN manual.
 
zstratto said:
I get the error 'unknown floating point exception'. However, when another compiler compiled this code the executable works fine ...
My guess is that the older compiler uses higher precision floating point math, ending up dividing by a small number instead of zero. A similar thing happened with microsoft c. The old 16 bit compilers supported "long double" using the 80 bit format, but the 32/64 bit compilers changed this so that "long double" is the same as "double" at 64 bit format (perhaps an issue related to a win32 console mode program, but assembly code can still use the 80 bit format).
 
Last edited:
  • #10
zstratto said:
Hi, I have an issue where I am squaring a very small complex number 1e-20 (FALFA2) which seems to make the value zero (both the real and imag part) and then dividing by it, the problem line is (all the numbers are complex):
GALFA = ( FBETA * FAA / FALFA2 ) - ( FAB / FALFA )

Just guessing here, but FALFA2 = FALFA*FALFA. Is that right? In that case you'd be much better off rearranging the calculation as :

GALFA = ( FBETA * FAA / FALFA - FAB ) / FALFA
 
  • #11
I was able to get around this by using a different compiler (g95), thank you everyone for the help!
 

Similar threads

Replies
16
Views
2K
Replies
2
Views
2K
Replies
8
Views
4K
Replies
7
Views
4K
Replies
3
Views
3K
Replies
3
Views
3K
Back
Top