[FORTRAN] Division by zero allowed?

[zstratto]

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!

 

[Chestermiller]

Do the calculation in double precision.

 

[zstratto]

How exactly do I do that?

 

[gsal]

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?

 

[gsal]

tell which compiler you are using

post the commands you are using to compile the program

 

[zstratto]

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.

 

[gsal]

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.

 

[Chestermiller]

How exactly do I do that?

Check your FORTRAN manual.

 

[rcgldr]

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).

 

[uart]

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

 

[zstratto]

I was able to get around this by using a different compiler (g95), thank you everyone for the help!