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

On Thu, 20 Apr 2023 11:01:41 +0200, 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.
> 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

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

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

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

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
```

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)

On Thu, 20 Apr 2023 16:37:35 -0700, gah4 wrote:

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

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

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.

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

On Fri, 21 Apr 2023 00:41:06 -0700, gah4 wrote:

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

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

On Fri, 21 Apr 2023 09:58:16 -0500, Ron Shepard wrote:

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

Isn't that the expected behavior?

--
steve

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

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

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?

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.

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

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?

On Sunday, April 23, 2023 at 8:42:59 AM UTC+12, gah4 wrote:
> 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?

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

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?

On Monday, April 24, 2023 at 6:23:05 PM UTC+12, gah4 wrote:
> 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?
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.

gah4 <gah4@u.washington.edu> schrieb:
> 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?

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