Quiet or Signaling NaN

[GianLuigi Piacentini]

Dear all,

I would like to set the result of a simple subroutine to NaN, as a way
to signal the outside world that something went wrong inside that
procedure.
Better Quiet or Signaling NaN ?

The idea is that result is invalid, and subsequent operations should
stop, perhaps triggering premature end of program.

I could perhaps use huge or tiny, although, at least theoretically, huge
and tiny could be valid results.
I would also avoid an "info" argument.

Any different suggestion ?

Thanks in advance
Gigi

[Steven G. Kargl]

Use the IEEE 754 facilities that modern compilers support.

subroutine foo

use ieee_arithmetic

logical, save :: once = .true.

if (.not. ieee_support_nan()) then
write(*,'(A)') 'program does not support IEEE NaN'
once = .false.
end if

<do calculation to get x>

! set results
if (ieee_support_nan()) then
if (IEEE_IS_NAN(x)) then
! You can do other things that might make sense here
error stop 'NaN occurred'
end if
end if

result = x

end subroutine

[Steve Lionel]

On 4/20/2023 5:01 AM, GianLuigi Piacentini wrote:
> Better Quiet or Signaling NaN ?

Quiet NaN is better as many processors will convert a signaling NaN to
quiet when moved.
--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[baf]

I often just use an integer valued intent out argument to the subroutine
that provides the exit condition. Different values of the argument have
some meaning about the success or failure of the subroutine. In your
case, it could be a logical argument that signals failure.

[jfh]

On Friday, April 21, 2023 at 4:34:50 AM UTC+12, baf wrote:
> On 4/20/2023 2:01 AM, GianLuigi Piacentini wrote:
> > Dear all,
> >
> > I would like to set the result of a simple subroutine to NaN, as a way
> > to signal the outside world that something went wrong inside that
> > procedure.

With a compiler that can read ```'NaN'```` into a real variable one can do this without using IEEE:
```
real function nan()
character:: cnan*3 = 'NaN'
read(cnan,*) nan
end function nan
```

[gah4]

On Thursday, April 20, 2023 at 2:01:46 AM UTC-7, GianLuigi Piacentini wrote:

> I would like to set the result of a simple subroutine to NaN, as a way
> to signal the outside world that something went wrong inside that
> procedure.

use, intrinsic:: ieee_arithmetic
real :: snan, qnan
snan = ieee_value(snan, ieee_signaling_nan)
qnan = ieee_value(qnan, ieee_quiet_nan)
print *, snan, qnan
end

It seems that you can't:

real :: snan = ieee_value(snan, ieee_signaling_nan)

[Steven G. Kargl]

One can't do what?

% gfcx -o z a.f90 && ./z
NaN NaN
% gfcx -o z a.f90 && ./z
7FA00000 7FC00000

That last result changes the print statement in an obvious
way.

--
steve

[gah4]

On Thursday, April 20, 2023 at 4:54:33 PM UTC-7, Steven G. Kargl wrote:

(snip)

> One can't do what?

use, intrinsic:: ieee_arithmetic

real :: snan = ieee_value(snan, ieee_signaling_nan)

real :: qnan = ieee_value(qnan, ieee_quiet_nan)

print *, snan, qnan
end

claims that ieee_value isn't an intrinsic function.

[Ron Shepard]

On 4/20/23 6:54 PM, Steven G. Kargl wrote:

> One can't do what?

If you change the assignments to initialization expressions, then you
get errors like:

$gfortran nan.f90 && a.out
nan.f90:2:17:

2 | real :: snan = ieee_value(snan, ieee_signaling_nan), qnan =
ieee_value(qnan, ieee_quiet_nan)
| 1
Error: Function ‘ieee_value’ in initialization expression at (1) must be
an intrinsic function

$.02 -Ron Shepard

[Steven G. Kargl]

It isn't an intrinsic function.

F2023, Sec. 17, p. 460

NOTE 1
The types and procedures defined in these modules are not themselves intrinsic.

--
steve

[Steven G. Kargl]

Isn't that the expected behavior?

--
steve

[Steve Lionel]

On 4/21/2023 3:41 AM, gah4 wrote:
> claims that ieee_value isn't an intrinsic function.

There are only selected intrinsic module functions (which are not
intrinsic functions) allowed in constant expressions:

- a reference to a transformational function from the intrinsic module
IEEE_ARITHMETIC or IEEE_EXCEPTIONS, where each argument is a constant
expression

- an inquiry function from the intrinsic modules IEEE_ARITHMETIC and
IEEE_EXCEPTIONS (17.10) [this is from "specification inquiry functions",
which are allowed in constant expressions.]

IEEE_VALUE is neither of these. I could see a case being made for
IEEE_VALUE being allowed here, but at present it is not (including in
F2023.)

[gah4]

On Friday, April 21, 2023 at 12:01:12 PM UTC-7, Steve Lionel wrote:
> On 4/21/2023 3:41 AM, gah4 wrote:
> > claims that ieee_value isn't an intrinsic function.

> There are only selected intrinsic module functions (which are not
> intrinsic functions) allowed in constant expressions:

> - a reference to a transformational function from the intrinsic module
> IEEE_ARITHMETIC or IEEE_EXCEPTIONS, where each argument is a constant
> expression

> - an inquiry function from the intrinsic modules IEEE_ARITHMETIC and
> IEEE_EXCEPTIONS (17.10) [this is from "specification inquiry functions",
> which are allowed in constant expressions.]

> IEEE_VALUE is neither of these. I could see a case being made for
> IEEE_VALUE being allowed here, but at present it is not (including in
> F2023.)

Well, first I expected I was looking for a named constant, but didn't find it.
Then I found IEEE_VALUE, and wrote the second program, using it in an
initialization expression, first.

In any case, I vote for allowing it. Are we up for F2028 now?

[Steve Lionel]

On 4/21/2023 6:45 PM, gah4 wrote:
>> IEEE_VALUE is neither of these. I could see a case being made for
>> IEEE_VALUE being allowed here, but at present it is not (including in
>> F2023.)
>
> Well, first I expected I was looking for a named constant, but didn't find it.
> Then I found IEEE_VALUE, and wrote the second program, using it in an
> initialization expression, first.
>
> In any case, I vote for allowing it. Are we up for F2028 now?
>
>

F202Y is what we are calling the next revision. It may end up as 2028,
too soon to tell. We do have a good head start on it already.

[gah4]

On Saturday, April 22, 2023 at 10:12:25 AM UTC-7, Steve Lionel wrote:
> On 4/21/2023 6:45 PM, gah4 wrote:

(snip)

> > In any case, I vote for allowing it. Are we up for F2028 now?

> F202Y is what we are calling the next revision. It may end up as 2028,
> too soon to tell. We do have a good head start on it already.

I still have, somewhere, "Fortran 8x Explained" which I might have bought
in 1989. So, now they are only up to Y?

[jfh]

I think F2023 was called F202X before anyone knew when it would be settled. In Fortran terms, that X was a variable not a constant :-)

[gah4]

On Sunday, April 23, 2023 at 10:15:51 PM UTC-7, jfh wrote:

(snip)

> I think F2023 was called F202X before anyone knew when it would be settled. In Fortran terms, that X was a variable not a constant :-)

So the X variable has been overused, and they moved on to Y?

[jfh]

My memory is that some enhancements to F2018 were called F202X because they could go into the next version of the standard and others were called F202Y because they would have to wait for the one after, because a lot more work was needed on them.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

There was planning for 202Y before 202X was settled - it will
(presumably) be the second release in this decade.