View previous topic :: View next topic |
Author |
Message |
louis
Joined: 19 Oct 2005 Posts: 9
|
Posted: Thu Jun 05, 2008 10:15 am Post subject: action of acos/asin intrinsic functions |
|
|
I recently wrote some code which used the Fortran intrinsic function ACOS. The argument of course must lie between -1.0 and 1.0 for any meaningful result. My example code computed a value for the argument which was -1.0 except at the 15th decimal place, but FTN95 still raised a run time error due to an argument outwith the allowed range
My request is for the FTN95 versions of ACOS/ASIN to behave more like Linux/Unix versions, i.e. if the number is -1 or +1 within a certain (generous) tolerance, it be treated as exactly -1 or + 1
Over the years I have found many examples where this behaviour has necessitated writing extra code to ensure arguments don't fall outwith the allowed range. This code is not necessary when using most Linux/Unix Fortran compilers ! |
|
Back to top |
|
|
JohnHorspool
Joined: 26 Sep 2005 Posts: 270 Location: Gloucestershire UK
|
Posted: Thu Jun 05, 2008 10:56 am Post subject: |
|
|
Louis, isn't it best practice to write code that checks these arguments as a matter of course, and aren't the Linux/Unix compilers actually breaking the standard ? |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Thu Jun 05, 2008 12:00 pm Post subject: |
|
|
Hi,
John is absolutely right. You could try the real*10 precision in calculations leading up to your ACOS/ASIN, or if you are not interested in the checks then how about a lazy ACOS/ASIN, typically:
angle=acos(max(-1d0,min(1d0,cos_of_angle)))
Regards
Ian |
|
Back to top |
|
|
louis
Joined: 19 Oct 2005 Posts: 9
|
Posted: Thu Jun 05, 2008 12:22 pm Post subject: |
|
|
Hello
I agree in principle with the comments of John & Ian that the code should be in itself robust (rather than relying on compiler user-friendliness). In fact I use exactly the quick fix that Ian suggested.
Its just that the code I write is compiled both for Windows with FTN95 and for Linux, and I constantly find these little issues. A bigger issue is the Unix "nan" as an escape from e.g. zero divide and similar errors.
In the end though FTN95 is a truly excellent tool at winkling out coding errors...
Regards Louis |
|
Back to top |
|
|
|