Fortran - Re: Checking for IEEE Infinity

Author

Re: Checking for IEEE Infinity

Jugoslav Dujic

2005-08-15, 4:01 am

Max wrote:
| I've spent a day trying to catch this, and Google didn't throw up a
| solution, so I thought I would post this.
|
| I was trying to catch at what point I calculated an Infinity; using Digital
| Visual Fortran there is supposed to be a compiler switch, -fpe:0, that will
| do this automatically. At least in a DLL, it doesn't. My infinity was
| calculated from dividing by a denormalised number, so many of the available
| error traps in DVF didn't apply. (I did try them!) I could check for NaN,
| but that located where the problem manifested itself, not where the problem
| occurred - which was in a different subroutine.
|
| My eventual solution was to check for
|
| IF (IsNan(cos(Value))) THEN ' Only TRUE if Value is NaN or
| Infinity
| ! break statement here in debugger to investigate what caused 'Value' to
| cause the problem
| END IF
|
| I made this an entry-level condition of each routine to ensure that it was
| from a previous routine that the problem was being propagated.

The entire mechanism for catching floating-point errors in CVF is quirky.
I had a similar problem with a Dll (albeit reverse -- I wanted silent
behaviour with /fpe:3 but the floating-point run-time errors kept on
emerging with a Dll called from a Delphi host application).

In the end, I overcame it by explicitly calling SETCONTROLFPQQ() from
a Dll's base routine:

call getcontrolfpqq(iFpu)
iFp=iFpu.or.FPCW$OVERFLOW.or.FPCW$INVALID.or. &
FPCW$ZERODIVIDE.or.FPCW$UNDERFLOW.or.FPCW$INEXACT
call setcontrolfpqq(iFp)

you'll want to clear these bits, obviously (or entire exception mask
called FPCW$MCW_EM).

Hope this helps,

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Abdul Qat

2005-08-16, 4:01 am

"Jugoslav Dujic" <jdujic@yahoo.com> wrote in message
news:3markkF163nd0U1@individual.net...
> Max wrote:
> | I've spent a day trying to catch this, and Google didn't throw up a
> | solution, so I thought I would post this.
> |
> | I was trying to catch at what point I calculated an Infinity; using
Digital
> | Visual Fortran there is supposed to be a compiler switch, -fpe:0, that
will
> | do this automatically. At least in a DLL, it doesn't. My infinity was
> | calculated from dividing by a denormalised number, so many of the
available
> | error traps in DVF didn't apply. (I did try them!) I could check for
NaN,
> | but that located where the problem manifested itself, not where the
problem
> | occurred - which was in a different subroutine.
> |
> | My eventual solution was to check for
> |
> | IF (IsNan(cos(Value))) THEN ' Only TRUE if Value is NaN
or
> | Infinity
> | ! break statement here in debugger to investigate what caused
'Value' to
> | cause the problem
> | END IF
> |
> | I made this an entry-level condition of each routine to ensure that it
was
> | from a previous routine that the problem was being propagated.
>
> The entire mechanism for catching floating-point errors in CVF is quirky.
> I had a similar problem with a Dll (albeit reverse -- I wanted silent
> behaviour with /fpe:3 but the floating-point run-time errors kept on
> emerging with a Dll called from a Delphi host application).
>
> In the end, I overcame it by explicitly calling SETCONTROLFPQQ() from
> a Dll's base routine:
>
> call getcontrolfpqq(iFpu)
> iFp=iFpu.or.FPCW$OVERFLOW.or.FPCW$INVALID.or. &
> FPCW$ZERODIVIDE.or.FPCW$UNDERFLOW.or.FPCW$INEXACT
> call setcontrolfpqq(iFp)
>
> you'll want to clear these bits, obviously (or entire exception mask
> called FPCW$MCW_EM).
>

Yes, this is how to do it for .DLLs. The /fpe:x was a Digital invention
that works for .EXEs but not for .DLLs. It was never part of FPS, :-). The
automoton from Digital/Compaq/Intel/NEXT never did realize this, he being
dumb enough to believe the Manual.

--
Salaam,
Abdul Q.
______
"I'm going to be as well known as Murphy one of these days." Gordon Moore,
founder of Intel.

Sponsored Links