portable way to test for NaN
g durham
Thanks,
Garland
Michel OLAGNON
> Can anyone tell me if there is a portable way to test x==NaN ?
>
whatsoever that Fortran will ever impose to abide to the Floating-point standard,
so you need to check your method on every new system that you want to use.
Methods were discussed several times in this group, see dejanews.
--
Michel OLAGNON email : Michel....@ifremer.fr
http://www.ifremer.fr/metocean/group/michel/michel_olagnon.htm
http://www.fortran-2000.com/
Keith Bierman
Michel OLAGNON wrote:
> In article <3ACD81D8...@email.unc.edu>, g durham <gdu...@email.unc.edu> writes:
> > Can anyone tell me if there is a portable way to test x==NaN ?
> >
> NaN belongs to a different standard than the Fortran one, there is no chance
> whatsoever that Fortran will ever impose to abide to the Floating-point standard--
Unless things have changed since I left the committe, there is a "Technical Report" which
binds Fortran to the IEEE floating point standard. In addition, the working draft of the
Standard being worked on "20xx" as part of the standard itself. Using very, very rough
pseduo code, one would be able to do something like:
IF (IEEE_SUPPORT_NAN) then
if (IEEE_ISNAN(x)) then
do whaever remedial action you want
endif
ELSE
some sort of generic behavior in the absence of IEEE nan support.
END
Note that a processor might comply to other parts of the IEEE standard, but not have NAN
support (most likely this would be in some particular mode of operation, not that the
processor would lack NAN support in all modes).
It will probably be a few years before using the facilities in the TR will be widely
enough implemented that relying on them as such will be a clever idea.
Keith H. Bierman keith....@Sun.COM
Sun Microsystems Laboratories
901 San Antonio Road UMPK 31-101
Palo Alto, California 94303
650 943-3903 voice|650 321-9175fax
<speaking for myself, not Sun*> Copyright 2001
Gary Scott
That will be nice...but can we PLEASE chuck those underscores in the
names before it gets standardized...PLEASE? That's one of those bad
habits that needs to be stamped out.
--
Gary Scott
mailto:sco...@flash.net
mailto:webm...@fortranlib.com
http://www.fortranlib.com
Support the GNU Fortran G95 Project: http://g95.sourceforge.net
Michel OLAGNON
>
>
>Michel OLAGNON wrote:
>
>> In article <3ACD81D8...@email.unc.edu>, g durham <gdu...@email.unc.edu> writes:
>> > Can anyone tell me if there is a portable way to test x==NaN ?
>> >
>> NaN belongs to a different standard than the Fortran one, there is no chance
>> whatsoever that Fortran will ever impose to abide to the Floating-point standard--
>
>Unless things have changed since I left the committe, there is a "Technical Report" which
>binds Fortran to the IEEE floating point standard. In addition, the working draft of the
>Standard being worked on "20xx" as part of the standard itself. Using very, very rough
>
> IF (IEEE_SUPPORT_NAN) then
> if (IEEE_ISNAN(x)) then
> do whaever remedial action you want
> endif
> ELSE
> some sort of generic behavior in the absence of IEEE nan support.
> END
>
>Note that a processor might comply to other parts of the IEEE standard, but not have NAN
>support (most likely this would be in some particular mode of operation, not that the
>processor would lack NAN support in all modes).
>
As a programmer, I am biased, and I call "portable" your "some sort of generic
behavior in the absence of IEEE nan support", since presence of IEEE nan support
cannot be garanteed by the standard. I am usually unhappy with the option
WRITE (*,*) 'Find a system where IEEE_SUPPORT_NAN .EQV. .TRUE. to run this program'.
If I have a better option, why should I make a distinction to use sometimes
IEEE_ISNAN(x) and sometimes, say, (x > 0.0) .EQV. (x <= 0.0) ? Code becomes
harder to read, debug and maintain, one branch or the other may be taken on
a mere compiler option with the same system, but of course you have this
magic 4-letter word: IEEE that you can show your boss is ubiquitous in the program.
;-)
>It will probably be a few years before using the facilities in the TR will be widely
>enough implemented that relying on them as such will be a clever idea.
:-(
Michel
Jan Vorbrueggen
> That will be nice...but can we PLEASE chuck those underscores in the
> names before it gets standardized...PLEASE? That's one of those bad
> habits that needs to be stamped out.
Why do you mind? Some form of punctuation is required, IMNSHO, to make
things readable. I'm pretty sure that the alternative to the underscore,
the dash, is not allowed in variable names. What else do you suggest?
Jan
Paul van Delst
>
> Gary Scott <sco...@flash.net> writes:
>
> > That will be nice...but can we PLEASE chuck those underscores in the
> > names before it gets standardized...PLEASE? That's one of those bad
> > habits that needs to be stamped out.
>
> Why do you mind? Some form of punctuation is required, IMNSHO, to make
> things readable.
I agree. But I'm an adherent of using "_" for naming things like so:
my_function
this_variable
that_variable
rather than:
MyFunction
ThisVariable
ThatVariable
How else besides the underscore would one punctuate IEEE_SUPPORT_NAN? IEEESupportNan,
maybe? Blech. Besides, we already have DOT_PRODUCT, DATE_AND_TIME, SYSTEM_CLOCK, BIT_SIZE,
SELECTED_REAL_KIND, etc. so the "_" style has precedent. To introduce different naming
styles of intrinsics in the standard (which is the ultimate goal of all this IEEE stuff,
right? In F21XX? :o) would be quite untidy. Sniff.
cheers,
paulv
--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301)763-8000 x7274 There shallow draughts intoxicate the brain,
Fax:(301)763-8545 And drinking largely sobers us again.
paul.v...@noaa.gov Alexander Pope.
James Giles
Michel OLAGNON wrote in message <9aubte$i40$1...@iletudy.ifremer.fr>...
...
>As a programmer, I am biased, and I call "portable" your "some sort of
generic
>behavior in the absence of IEEE nan support", since presence of IEEE nan
support
>cannot be garanteed by the standard. I am usually unhappy with the option
>WRITE (*,*) 'Find a system where IEEE_SUPPORT_NAN .EQV. .TRUE. to run this
program'.
I think that the intent of the standard is that all implementations
whose hardware supports NANs must support the new software
feature as well. By you definition, what constitutes "portable"
if you move to non-IEEE hardware?
>If I have a better option, why should I make a distinction to use sometimes
>IEEE_ISNAN(x) and sometimes, say, (x > 0.0) .EQV. (x <= 0.0) ? [...]
Wouldn't the test (X/=X) be faster than the compare you use? It's
specifically mentioned in the original IEEE standard as the behavior
for unordered values (NANs). OK, they use .ne. because they didn't
know Fortran was going to introduce a /= operator. (See: ANSI/IEEE
Std. 754-1985, page 13.) Or, is it the case that some implementations
don't return .true. for (X/=X) if X is a NAN? I'd still prefer to use
IS_NAN because it's easier to read. (By the way, I'd rename the
standard IEEE_IS_NAN to just IS_NAN by enclosing it in a
internal procedure that I'd include in all my programs - IS_NAN
could then use the built-in IEEE_IS_NAN if it exists or be written
as (X/=X) where it doesn't.)
--
J. Giles
Gary Scott
Just appearance preferences...I'd prefer capitalization to creating
variable names that look like derived type components:
IEEE.SUPPORT.NAN
IEEE_SUPPORT_NAN
IEEE%SUPPORT%NAN
Not much difference there in appearance, it looks like 3 separate
composite variable name parts to me.
ieeeSupportNAN
Would probably work.
No biggie, I just don't happen to like _ in names.
Gary Scott
of _ in names in favor of capitalization. I'm quite grateful to them
for that.
Michel OLAGNON
>
>Michel OLAGNON wrote in message <9aubte$i40$1...@iletudy.ifremer.fr>...
>>As a programmer, I am biased, and I call "portable" your "some sort of
>generic
>>behavior in the absence of IEEE nan support", since presence of IEEE nan
>support
>>cannot be garanteed by the standard. I am usually unhappy with the option
>>WRITE (*,*) 'Find a system where IEEE_SUPPORT_NAN .EQV. .TRUE. to run this
>program'.
>
>I think that the intent of the standard is that all implementations
>whose hardware supports NANs must support the new software
>if you move to non-IEEE hardware?
I fear some vendors may use some adequate wording, just like "our
hardware _allows_ NANs and we provide software support as an
extension". A well-known vendor used a twirk like that to
provide a REAL KIND that has no matching COMPLEX KIND, despite
what the standard states.
"portable" means portable. I just doubt that in the above case,
a truly portable solution will ever exist. Yet I met systems
with limited NAN support; in such cases, whether IEEE_SUPPORT_NAN
should have returned .TRUE. might be a good case for a lawyer.
>
>>If I have a better option, why should I make a distinction to use sometimes
>>IEEE_ISNAN(x) and sometimes, say, (x > 0.0) .EQV. (x <= 0.0) ? [...]
>
>Wouldn't the test (X/=X) be faster than the compare you use? It's
>specifically mentioned in the original IEEE standard as the behavior
>for unordered values (NANs). OK, they use .ne. because they didn't
>know Fortran was going to introduce a /= operator. (See: ANSI/IEEE
>Std. 754-1985, page 13.) Or, is it the case that some implementations
>don't return .true. for (X/=X) if X is a NAN?
It's just that I already met optimizers that with some aggressive options
removed the (X/=X) test (there were caveats in the doc, so I guess that they
were fully entitled to), and that I did not meet one smart enough yet to
remove (x > 0.0) .EQV. (x <= 0.0) -- Probably a matter of weeks now
before one comes out :-)
> I'd still prefer to use
>IS_NAN because it's easier to read. (By the way, I'd rename the
>standard IEEE_IS_NAN to just IS_NAN by enclosing it in a
>internal procedure that I'd include in all my programs - IS_NAN
>could then use the built-in IEEE_IS_NAN if it exists or be written
>as (X/=X) where it doesn't.)
>
(MY_SUPPORT_TO_GILES_NAN_NAMES .AND. MY_SUPPORT_TO_GILES_PROCEDURE) .EQV. .TRUE.
Jan Vorbrueggen
> Just appearance preferences...I'd prefer capitalization to creating
> variable names that look like derived type components:
>
> IEEE.SUPPORT.NAN
> IEEE_SUPPORT_NAN
> IEEE%SUPPORT%NAN
>
> Not much difference there in appearance, it looks like 3 separate
> composite variable name parts to me.
>
> ieeeSupportNAN
>
> Would probably work.
I use the all-capital names for all intrinsics etc., and capitalized (mixed-
case) names for all declared variables. However, your suggestion doesn't fly
for a simple reason: to the compiler, they are all capitalized! (Try a listing
of your source code, for instance.) Thus, the standard cannot mandate
differentiation based on case, because a standard-conforming compiler could
refuse to recognize program text not in all capitals - or is that not so?
(That buyers would vote such a compiler down on quality of implementation is
neither here nor there to the standard.)
Jan
Jan Vorbrueggen
> Wouldn't the test (X/=X) be faster than the compare you use?
Unless the compiler has a bug or is optimized to run in a mode where exact
IEEE semantics are obeyed unless specifically asked for...remember, say what
you want (IS_NAN(X)) instead of how you wnat it (X/=X).
> Or, is it the case that some implementations don't return .true. for
> (X/=X) if X is a NAN?
No, there are implementations for which X/=X even if IS_NAN(X) .EQV. .FALSE..
A case in point is/was the 68040, which would sometimes compare mantissa bits
that should have been ignored. Duh.
Jan
Herman D. Knoble
! Compiled using Compaq Visual Fortran 6.5a with default
! fpe settings. This program yields the one-line result:
! x=Infinity
!
double precision x
x=1.D+170
x=x*x
if( (x > 0.0) .EQV. (x <= 0.0)) write(*,*) '1) X is a NaN'
if (x/=x) write(*,*) '2) X is a NaN'
if (ISNAN(x)) write(*,*) '3) X is a NaN'
write(*,*) 'X=',x
stop
end
Since the output (X=Infinity) verifies that x is a Nan, why
do not the three IF's test .TRUE.?
Skip
On 11 Apr 2001 07:06:05 GMT, mola...@ifremer.fr (Michel OLAGNON) wrote:
-|In article <S%HA6.17148$IJ1.1...@bgtnsc05-news.ops.worldnet.att.net>, "James Giles"
<james...@worldnet.att.net> writes:
-|>
-|>Michel OLAGNON wrote in message <9aubte$i40$1...@iletudy.ifremer.fr>...
-|>....
-|>>As a programmer, I am biased, and I call "portable" your "some sort of
-|>generic
-|>>behavior in the absence of IEEE nan support", since presence of IEEE nan
-|>support
-|>>cannot be garanteed by the standard. I am usually unhappy with the option
-|>>WRITE (*,*) 'Find a system where IEEE_SUPPORT_NAN .EQV. .TRUE. to run this
-|>program'.
-|>
-|>I think that the intent of the standard is that all implementations
-|>whose hardware supports NANs must support the new software
-|>feature as well. By your definition, what constitutes "portable"
-|>if you move to non-IEEE hardware?
-|
-|I fear some vendors may use some adequate wording, just like "our
-|hardware _allows_ NANs and we provide software support as an
-|extension". A well-known vendor used a twirk like that to
-|provide a REAL KIND that has no matching COMPLEX KIND, despite
-|what the standard states.
-|
-|"portable" means portable. I just doubt that in the above case,
-|a truly portable solution will ever exist. Yet I met systems
-|with limited NAN support; in such cases, whether IEEE_SUPPORT_NAN
-|should have returned .TRUE. might be a good case for a lawyer.
-|
-|>
-|>>If I have a better option, why should I make a distinction to use sometimes
-|>>IEEE_ISNAN(x) and sometimes, say, (x > 0.0) .EQV. (x <= 0.0) ? [...]
-|>
-|>Wouldn't the test (X/=X) be faster than the compare you use? It's
-|>specifically mentioned in the original IEEE standard as the behavior
-|>for unordered values (NANs). OK, they use .ne. because they didn't
-|>know Fortran was going to introduce a /= operator. (See: ANSI/IEEE
-|>Std. 754-1985, page 13.) Or, is it the case that some implementations
-|>don't return .true. for (X/=X) if X is a NAN?
-|
-|
-|It's just that I already met optimizers that with some aggressive options
-|removed the (X/=X) test (there were caveats in the doc, so I guess that they
-|were fully entitled to), and that I did not meet one smart enough yet to
-|remove (x > 0.0) .EQV. (x <= 0.0) -- Probably a matter of weeks now
-|before one comes out :-)
-|
-|> I'd still prefer to use
-|>IS_NAN because it's easier to read. (By the way, I'd rename the
-|>standard IEEE_IS_NAN to just IS_NAN by enclosing it in a
-|>internal procedure that I'd include in all my programs - IS_NAN
-|>could then use the built-in IEEE_IS_NAN if it exists or be written
-|>as (X/=X) where it doesn't.)
-|>
-|
-|(MY_SUPPORT_TO_GILES_NAN_NAMES .AND. MY_SUPPORT_TO_GILES_PROCEDURE) .EQV. .TRUE.
-|
-|Michel
Herman D. (Skip) Knoble, Research Associate
Mailto:h...@psu.edu
Web: http://www.personal.psu.edu/hdk
Center for Academic Computing
Penn State University
214C Computer Building
University Park, PA 16802-2101
Phone:+1 814 865-0818 Fax:+1 814 863-7049
Gary Scott
I would never ask for a variable or procedure name to be differentiated
based upon case.
I don't expect IEEESUPPORTNAN to be a different from ieeeSupportNAN, it
is merely for the human reader. As for a compiler not supporting lower
case, I wouldn't buy it, regardless of what the standard says. If the
standard does not require support of mixed case, then the standard needs
to do so. As for the compiler not retaining the case of the source in
any listings, that is also a "quality of implementation" issue. I would
prefer that it did so, but it wouldn't bother me much if it didn't (a
lot less than the underscores do).
Ron Sverdlove x2517
capital letters in the middle. They are hard to type and hard to
read. I think underscores are fine, because they look most like
spaces, which makes it easy to read names that consist of more than
one word. To me names with underscores don't look at all like
structure components. I must agree about case, however. I would
not want to use a compiler that didn't support mixed case.
--
Ronald Sverdlove Visual Information Systems Research
r...@sarnoff.com Sarnoff Corporation
Tel. 609-734-2517 CN 5300
FAX 609-734-2662 Princeton, NJ 08543-5300
James Giles
Herman D. Knoble wrote in message
<4kn8dt4tff663u55n...@4ax.com>...
>Given the code:
>! Compiled using Compaq Visual Fortran 6.5a with default
>! fpe settings. This program yields the one-line result:
>! x=Infinity
>!
> double precision x
> x=1.D+170
> x=x*x
> if( (x > 0.0) .EQV. (x <= 0.0)) write(*,*) '1) X is a NaN'
> if (x/=x) write(*,*) '2) X is a NaN'
> if (ISNAN(x)) write(*,*) '3) X is a NaN'
> write(*,*) 'X=',x
> stop
> end
>
>Since the output (X=Infinity) verifies that x is a Nan, why
>do not the three IF's test .TRUE.?
Infinity isn't a NAN. Infinity is ordered relative to all
non-NAN numbers. Infinity is, for example, greater than
zero. It is not less than or equal to zero. Infinity does
equal itself. It does not not-equal itself. Infinity is
infinity.
--
J. Giles
Paul van Delst
>
> Infinity isn't a NAN. Infinity is ordered relative to all
> non-NAN numbers. Infinity is, for example, greater than
> zero. It is not less than or equal to zero.
Unless, of course, it's -infinity. :o) On further thought, I guess they are different
numbers though.
<natty quotable snipped>
If I were a mathematician, I would change my .sig to:
--
Paul van Delst Infinity does equal itself.
CIMSS @ NOAA/NCEP It does not not-equal itself.
Ph: (301)763-8000 x7274 Infinity is infinity.
Fax:(301)763-8545 James Giles
paul.v...@noaa.gov
:o)
Herman D. Knoble
Given the following (revised) code:
! Compiled using Compaq Visual Fortran 6.5a with default
! fpe settings. This program displays the results:
! 1) X is a NaN
! 3) X is a NaN
! X= NaN
!
real x
! See for example: http://www.psc.edu/general/software/packages/ieee/ieee.html
data x/B'01111111100000100000000000000000'/
if( (x > 0.0) .EQV. (x <= 0.0)) write(*,*) '1) X is a NaN'
if (x/=x) write(*,*) '2) X is a NaN'
if (ISNAN(x)) write(*,*) '3) X is a NaN'
write(*,*) 'X=',x
stop
end
Results Displayed:
1) X is a NaN
3) X is a NaN
X= NaN
Note: Method 2 didn't "catch" the NaN in this case. Nor does Method 2
seem to work for other NaNs, e.g.: 1 11111111 00100010001001010101010 .
In this case OPTIMIZE:0 (no optimizatoin) was used with CVF to
compile the above code.
Skip
On Wed, 11 Apr 2001 16:24:27 GMT, "James Giles" <james...@worldnet.att.net> wrote:
-|
-|Herman D. Knoble wrote in message
-|<4kn8dt4tff663u55n...@4ax.com>...
-|>Given the code:
-|>! Compiled using Compaq Visual Fortran 6.5a with default
-|>! fpe settings. This program yields the one-line result:
-|>! x=Infinity
-|>!
-|> double precision x
-|> x=1.D+170
-|> x=x*x
-|> if( (x > 0.0) .EQV. (x <= 0.0)) write(*,*) '1) X is a NaN'
-|> if (x/=x) write(*,*) '2) X is a NaN'
-|> if (ISNAN(x)) write(*,*) '3) X is a NaN'
-|> write(*,*) 'X=',x
-|> stop
-|> end
-|>
-|>Since the output (X=Infinity) verifies that x is a Nan, why
-|>do not the three IF's test .TRUE.?
-|
-|Infinity isn't a NAN. Infinity is ordered relative to all
-|non-NAN numbers. Infinity is, for example, greater than
-|zero. It is not less than or equal to zero. Infinity does
-|equal itself. It does not not-equal itself. Infinity is
-|infinity.
James Giles
Herman D. Knoble wrote in message ...
This is really too bad. It means that either CVF always optimized
that particular test out, or it uses an XOR internally for comparisons
of equality/inequality. That violates the IEEE standard. It doesn't
(yet) violate the Fortran standard, but it's not a good thing.
--
J. Giles
Keith Bierman
James Giles wrote:
> Std. 754-1985, page 13.) Or, is it the case that some implementations
> don't return .true. for (X/=X) if X is a NAN?
An optimizer could well optimize away the comparision. That's why the committee
went with an intrinsic rather than binding to the inequality test (it could have
been done that way, but at the price of constraining optimization of fp in
general).
> ould then use the built-in IEEE_IS_NAN if it exists or be written
> as (X/=X) where it doesn't.)
And, being a careful sort, I have no doubt you'd compile the file with the local
definition sans optimization just to ensure good behavior ;>
--
tho...@antispam.ham
> I hate the C++ style of names that have capital letters in the
> middle. They are hard to type and hard to read. I think
> underscores are fine, because they look most like spaces, which
> makes it easy to read names that consist of more than one word.
And in the six of one, half a dozen of the other department, I
prefer capital letters in the middle to underscores. Fewer
characters to type, for one thing. Less likely to accidentally
get a hyphen (which the compiler would treat as a minus sign)
instead of an underscore for another. And I find underscores
harder to type than capital letters. To each his own. Fortunately,
the new standard can accommodate both styles.
Guillaume Dargaud
> if (IEEE_ISNAN(x)) then
> do whaever remedial action you want
> endif
> ELSE
> some sort of generic behavior in the absence of IEEE nan support.
> END
OK, I just jumped ship here as I'm trying to test for NaN in a Fortran f77
prog on an SGI machine (IRIX 6.5.11).
The man pages tell me that there are 2 equivalent functions: IEEE_IS_NAN and
ISNAN.
But the linker thrashes around with:
ld32: ERROR 33 : Unresolved text symbol "ieee_is_nan_" -- 1st referenced
by eddgton.F-pp-W-13-mie.o.
ld32: ERROR 33 : Unresolved text symbol "isnan_" -- 1st referenced by
eddgton.F-pp-W-13-mie.o.
Since those are intrinsic _extensions_, do I need to link with some special
lib ?
--
Guillaume Dargaud
Colorado State University - Dept of Atmospheric Science
http://rome.atmos.colostate.edu/
"Programmers are tools for converting caffeine into code."
Walter Roberson
Guillaume Dargaud <dar...@sung3.ifsi.rm.cnr.it> wrote:
:> IF (IEEE_SUPPORT_NAN) then
:> if (IEEE_ISNAN(x)) then
:OK, I just jumped ship here as I'm trying to test for NaN in a Fortran f77
:prog on an SGI machine (IRIX 6.5.11).
:The man pages tell me that there are 2 equivalent functions: IEEE_IS_NAN and
:ISNAN.
$ man ieee_is_nan
IEEE_IS_NAN is accepted by the CF90 and MIPSpro 7 Fortran 90. ISNAN
is accepted by the CF90, MIPSpro 7 Fortran 90, and MIPSpro Fortran 77
compilers.
:But the linker thrashes around with:
:ld32: ERROR 33 : Unresolved text symbol "ieee_is_nan_" -- 1st referenced
:by eddgton.F-pp-W-13-mie.o.
Not supported for F77
:ld32: ERROR 33 : Unresolved text symbol "isnan_" -- 1st referenced by
:eddgton.F-pp-W-13-mie.o.
Should be supported for F77 though!
Steve Crockett
> In article <3ad5...@news.ColoState.EDU>,
> Guillaume Dargaud <dar...@sung3.ifsi.rm.cnr.it> wrote:
> :> IF (IEEE_SUPPORT_NAN) then
> :> if (IEEE_ISNAN(x)) then
>
> :OK, I just jumped ship here as I'm trying to test for NaN in a Fortran f77
> :prog on an SGI machine (IRIX 6.5.11).
> :The man pages tell me that there are 2 equivalent functions: IEEE_IS_NAN and
> :ISNAN.
>
> $ man ieee_is_nan
> IEEE_IS_NAN is accepted by the CF90 and MIPSpro 7 Fortran 90. ISNAN
> is accepted by the CF90, MIPSpro 7 Fortran 90, and MIPSpro Fortran 77
> compilers.
Okay, so apparently we lied. :-(
It's close, and there's even a bug filed (798127, for those of you
who have the level of support needed to view it).
For some reason, the ISNAN doesn't get processed properly
as an F77 intrinsic, so it gets treated as a normal function.
Not what should be happening.
I tested this with a trivial code bit, which reads two numbers
and computes a value which is NaN if the second number is zero,
in both single and double precision.
For Fortran 90, ISNAN works as advertised:
% f90 -n32 -O3 -o zzz test1.f
% ./zzz
3 5
val is 3.
dval is 3.
% ./zzz
8 0
val: I'm a single precision NaN!
dval: I'm a double precision NaN!
%
>
>
> :ld32: ERROR 33 : Unresolved text symbol "isnan_" -- 1st referenced by
> :eddgton.F-pp-W-13-mie.o.
>
> Should be supported for F77 though!
You can workaround it with this change: if the argument is
a double precision or real*8 expression, change the call
from
ISNAN(darg)
to
ISNAND$(%VAL(darg))
If the argument is a single precision or real*4 expression,
change the call from
ISNAN(arg)
to
ISNANF$(%VAL(arg))
% f77 -n32 -O3 -o zzzzzz test2.f
% ./zzzzzz
3 5
val is 3.000000
dval is 3.000000000000000
% ./zzzzzz
8 0
val: I'm a single precision NaN!
dval: I'm a double precision NaN!
%
Sorry for the foulup. It's not listed as a high-priority
bug, given that it's an extension and that Fortran 90
will build it properly.
regards,
--
Steve Crockett Supercomputing Apps-Energy
SGI Server & Supercomputing Bus. Unit
11490 Westheimer Rd, Ste. 100 e-mail: s...@sgi.com
Houston, TX 77077 phone: (281) 493-8349