Fortran 2023 trig functions

The fortran 2023 standard includes new trig related functions, namely cosd, sind, tand, acosd, asind, atand, atan2d, acospi, asinpi, atanpi, atan2pi, cospi, sinpi, and tanpi.

**D functions which use degrees rather than radians were implemented in gFortran and Ifort as extensions long before the 2023 standard, so they do appear fairly regularly in code I see written by others.

**PI functions operate on multiples of half revolutions. For example:: COSPI(x) = COS(PI*X), so COSPI(1.0) = -1.0 These functions have obvious applications in signal processing etc.

Perhaps these new intrinsics should be added to the FTN95 wish list, and added to the library when time permits? This would keep the core mathematical intrinsics in FTN95 in synch with the latest fortran standard.

The functions should be easy to implement - no gotchas like asin(Z) 😄

Further details can be found here:

https://wg5-fortran.org/N2201-N2250/N2212.pdf

Many thanks for the feedback. I have added this to the wish list.

These functions have now been implemented for the next release of FTN95 and the associated DLLs.

Paul, this will be a nice addition. I have some complex equations that will be simplified (to the eye, at least) using these new features.

Thanks for all you do!

Bill

If 'complex' means passing and returning complex numbers then this addition will not help.

As I understand it, the Standard does not include complex numbers in this context. Please let me know if I am wrong.

Oh, sorry! I 'misspoke'. I meant that there are a number of calculations that would be better done using *D or *PI functions, making the reading of them simpler, versus complex. Mostly involving spherical trig and datum conversions...

I can certainly see using that term would cause some concern!

Good work Paul, I appreciate this addition to the library.

Just to clarify, the aforementioned functions are indeed intended to operate on real and not complex variables.

Paul, there's something not correct with the *d functions. The following code should return two columns of data with equal entries in each row.

program test
use iso_fortran_env
implicit none
real :: rad2deg
real x
real*8 xd
write(*,*) compiler_version()
x = 45.0
write(*,'(2(F8.5,1X))') sind(x),  sind(45.0)
write(*,'(2(F8.5,1X))') cosd(x),  cosd(45.0)
write(*,'(2(F8.5,1X))') tand(x),  tand(45.0)

x = 0.0
write(*,'(2(F8.5,1X))') asind(x), asind(0.0)
write(*,'(2(F8.5,1X))') acosd(x), acosd(0.0)
write(*,'(2(F8.5,1X))') atand(x), atand(0.0)

xd = 1.d0
write(*,'(2(F8.5,1X))') asind(xd), asind(1.d0)
write(*,'(2(F8.5,1X))') acosd(xd), acosd(1.d0)
write(*,'(2(F8.5,1X))') atand(xd), atand(1.d0)

end program test


 FTN95 v9.13
 0.70711  0.85090
 0.70711  0.52532
 1.00000  1.61978
 0.00000  0.00000
90.00000  1.57080
 0.00000  0.00000
90.00000  1.57080
 0.00000  0.00000
45.00000  0.78540


 GCC version 12.3.0
 0.70711  0.70711
 0.70711  0.70711
 1.00000  1.00000
 0.00000  0.00000
90.00000 90.00000
 0.00000  0.00000
90.00000 90.00000
 0.00000  0.00000
45.00000 45.00000

Thanks Ken. I will take a look at this.

This has now been fixed for the next release of FTN95.

Thanks Paul,

Did you also look at the *pi functions? I see today that they have a similar issue.

x = 1.0
print*, asinpi(x), asinpi(1.0)
print*, atanpi(x), atanpi(1.0)
x = 0.0
print*, acospi(x), acospi(0.0)
print*, atanpi(x), atanpi(0.0)
end


     0.500000         1.57080
     0.250000        0.785398
     0.500000         1.57080
      0.00000         0.00000

C:\Arcadis 2025\0008 

Yes and also a failure when used in an initialisation (PARAMETER) statement.

I am fascinated by the introduction of new functions like this. What did people do before? What did they name their self-developed functions? Is there any conflict - and do the system functions perform better (faster? more accurate?)?

As I understand it, in general there is no reason to expect faster or more accurate results. Any differences will normally be in the round-off error.

But there are some interesting possibilities. For example cosd(60.0) could be exactly 0.5 with no round-off error, whilst tand(90.0) could print as INFINITY.