- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page