ATAND built in function

[Ken11]

Why does the input into ATAND need to be a value greater than or  equal to zero and is there a work around for this? 

[mecej4]

program xatd
print *,atand(-1.0),atand(+1.0),atand(0.0)
end

  -45.00000       45.00000      0.0000000E+00

No, the argument can range from -infinity to +infinity, and the result will range from -90.0 to +90.0.

[Ken11]

I agree however, the documentation states that the input value must be greater then or equal to zero. I will sometimes receive a NAN result from the atand function if the argument is a negative number. Results from the intel atand function are indeterminate.    

[mecej4]

Ah, I see, it seems that the documentation is in error. The ATAND function is non-standard, and vendors could implement their own definitions, but it appears that the function in the library works as I described. If you have examples where it did not, please show them.

program xatand
implicit none
integer, parameter :: NN = 10000
integer :: i,j,k,m
double precision :: x(NN),y(NN)
!
call random_number(x)    ! NN numbers between 0 and 1
x = atand(1d2*(x-0.5))   ! arg = NN numbers between -50 and +50
i = count(x >= 0.0)      ! x = NN numbers between -90 and +90
k = count(x < 0.0)
j = count(isnan(x))
m = count(abs(x) > 90d0)
print *,i,j,k,m
end

T:\LANG>xatd
        4982           0        5018           0

[Steve_Lionel · Accepted solution]

ATAND will be standard in F202X. I will inform Intel of the doc error (05347129). Amazing what things won't be found for so many years. It was also wrong in CVF!

[mecej4]

Years ago, when compiler documentation was mostly in the form of text or PDF files, it made sense to inform the vendor of typos and errors that users found in it.

Now, there are so many pages and versions of HTML documentation, often with no obvious version number or date, that it seems pointless to attempt to get them corrected. A documentation page that a search engine links to may not be a current version, and may not be hosted by the vendor, or it may not be clear whom to tell about the error.

[LuckyMartin]

I have seen the faulty ATAND behavior that Ken11 described, i.e., ATAND will return a result of NaN for certain (negative?) floating-point arguments.

So, Steve, are you saying that the ATAND bug was a known feature associated with pre-F202x releases and, as a result, the documentation was intentionally written with the seemingly absurd "argument must be greater than or equal to zero" qualification?  But now ATAND works correctly in F202x, and someone just forgot to update the documentation to reflect the fix?

If so, I'll need to graduate from my pre-F202x implementation.

[Steve_Lionel]

I said nothing about a bug. If you found a bug in the intrinsic itself, that's a different matter - do you have an example? The documentation was simply wrong, and I have no idea how it got that way. It is NOT the practice to revise the documentation to cover up a bug!

[mecej4]

Let us denote by F the fraction of users who report a bug related to a specific feature of a Fortran compiler. It seems likely from what we read in this thread that the number of people who use ATAND, N, is so small that int(N F) = 0.

[Ken11]

I was able to track down the offending input value using the IsNan() function. The input value is a real*4  (-4.6891688E-05) the program I'm running is a mixed language program in Visual Studio. I wrote a stand alone Fortran program in Visual Studio and did not get the NAN. 

[Steve_Lionel]

You might have a data corrupter elsewhere in the program. Your standalone test suggests that ATAND doesn't have a bug. (When testing specific REAL values, I always get the hex representation and use that to initialize the argument - that way I know exactly which value is being used.

Intel informs me that the documentation error will be corrected in a future update.

[andrew_4619]

It is amazing to me that degree angle functions were not in the F77 standard and have stayed out all the way to F202X!  Yes I know they are extensions in most (all??) compilers but extensions are not allowed in my world it has to be 100% standard.

[mecej4]

What's next? A set of trigonometric functions sing, cosg, tang, asing, acosg, atang, etc for angles measured in gradians? (1 gradian = 0.01 x right angle)

[andrew_4619]

OK it is trivial to convert units  but particularly when dealing with user input degrees is much more accessible in terms of interpreting numbers.  Rarely do you actually use and angle directly it pretty much always gets fed into a trig function, the forward backward conversion is tedious and it is less error prone to work in one unit. I have never used a gradian in my life to date BTW.  What next "Trig functions with arguments implicitly scaled by PI. J3/19-204r1" I believe! 

[JohnNichols]

From wikipedia:

The Babylonian system of mathematics was a sexagesimal (base 60) numeral system. From this we derive the modern-day usage of 60 seconds in a minute, 60 minutes in an hour, and 360 degrees in a circle.^[10] The Babylonians were able to make great advances in mathematics for two reasons. Firstly, the number 60 is a superior highly composite number, having factors of 1, 2, 3, 4, 5, 6, 10, 12, 15, 20, 30, 60 (including those that are themselves composite), facilitating calculations with fractions. Additionally, unlike the Egyptians and Romans, the Babylonians had a true place-value system, where digits written in the left column represented larger values (much as, in our base ten system, 734 = 7×100 + 3×10 + 4×1).^[11]

^{The question why change from something that is 3500 years old and works well.   We cannot even get metric in the USA.}  

[Steve_Lionel]

The standards committee likes to standardize extensions in wide use already - such proposals have a much lower barrier to acceptance and implementation. For mathematical intrinsics, it helps if C math libraries already have the function. 

[jimdempseyatthecove]

FWIW Back in 1968/69 I received an NSF grant to adapt FOCAL (an interpreter) to use sexagesimal number format. This was done on a 4KW PDP8/L.

Jim Dempsey