Home > Archive > Fortran > January 2006 > implementation of DACOSD
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
implementation of DACOSD
|
|
| Damien MATTEI 2005-05-27, 8:57 am |
| i have this error when porting a Fortran program from tru 64 to Linux:
[dma@alhena SIMECAFLD]$ make
f77 long_onde.F -o long_onde.o -c -Wall
long_onde.F: In subroutine `long_onde':
long_onde.F:423: warning:
radrad=dacosd(z/rayray) +i
^
Reference to unimplemented intrinsic `DACOSD' at (^) (assumed EXTERNAL)
long_onde.F:423:
radrad=dacosd(z/rayray) +i
^
Invalid declaration of or reference to symbol `dacosd' at (^) [initially
seen at (^)]
make: *** [long_onde.o] Error 1
i assume this due to dacosd not yet implemented under gcc
(see http://gcc.gnu.org/onlinedocs/gcc-3...-Intrinsic.html)
does anyone have an implementation of the function DACOSD ?
in a way as simple as dsind and dcosd can be implemented:
* ****************************************
*************************
real*8 FUNCTION DSIND( angle )
* ****************************************
*************************
implicit none
real*8 angle
real*8 pi
if( angle .eq. 180.0 ) then
dsind = 0.
else
pi=acos(0.)*2
dsind = dsin( angle * pi / 180.0 )
endif
return
end
* ****************************************
*************************
real*8 FUNCTION DCOSD( angle )
* ****************************************
*************************
implicit none
real*8 angle
real*8 pi
if( angle .eq. 90.0 ) then
dcosd = 0.
else if( angle .eq. 270.0 ) then
dcosd = 0.
else
pi=acos(0.)*2
dcosd = dcos( angle * pi / 180.0 )
endif
return
end
any help greatly appreciated
Damien
--
Damien MATTEI
email: Damien (dot) Mattei (AT) obs*azur (dot) fr
and replace * with -
| |
| Michel OLAGNON 2005-05-27, 4:01 pm |
|
Damien MATTEI wrote:
> i have this error when porting a Fortran program from tru 64 to Linux:
>
> [dma@alhena SIMECAFLD]$ make
> f77 long_onde.F -o long_onde.o -c -Wall
> long_onde.F: In subroutine `long_onde':
> long_onde.F:423: warning:
> radrad=dacosd(z/rayray) +i
> ^
> Reference to unimplemented intrinsic `DACOSD' at (^) (assumed EXTERNAL)
> long_onde.F:423:
> radrad=dacosd(z/rayray) +i
> ^
> Invalid declaration of or reference to symbol `dacosd' at (^) [initially
> seen at (^)]
> make: *** [long_onde.o] Error 1
>
> i assume this due to dacosd not yet implemented under gcc
> (see http://gcc.gnu.org/onlinedocs/gcc-3...-Intrinsic.html)
>
> does anyone have an implementation of the function DACOSD ?
>
Do you really not know how to turn the result of ACOS into degrees ?
I can give you a one-liner, but how then can you check that it is
right and that you implement it correctly ?
| |
| Michel OLAGNON 2005-05-27, 4:01 pm |
|
Damien MATTEI wrote:
> in a way as simple as dsind and dcosd can be implemented:
>
> * ****************************************
*************************
> real*8 FUNCTION DSIND( angle )
> * ****************************************
*************************
> implicit none
> real*8 angle
> real*8 pi
>
> if( angle .eq. 180.0 ) then
> dsind = 0.
> else
> pi=acos(0.)*2
> dsind = dsin( angle * pi / 180.0 )
> endif
> return
> end
>
> * ****************************************
*************************
> real*8 FUNCTION DCOSD( angle )
> * ****************************************
*************************
> implicit none
> real*8 angle
> real*8 pi
>
> if( angle .eq. 90.0 ) then
> dcosd = 0.
> else if( angle .eq. 270.0 ) then
> dcosd = 0.
> else
> pi=acos(0.)*2
> dcosd = dcos( angle * pi / 180.0 )
> endif
> return
> end
>
By the way, those functions are very bad implementations.
Hint: real*8 pi
real*8 zero
zero = 0.0
pi = 2 * acos(zero)
| |
| Rich Townsend 2005-05-27, 4:01 pm |
| Michel OLAGNON wrote:
>
> Damien MATTEI wrote:
>
>
>
>
>
>
> By the way, those functions are very bad implementations.
>
> Hint: real*8 pi
> real*8 zero
> zero = 0.0
> pi = 2 * acos(zero)
>
I would even prefer
pi = ACOS(-1.D0)
cheers,
Rich
| |
| Damien MATTEI 2005-05-27, 4:01 pm |
| Michel OLAGNON wrote:
>
>
> Damien MATTEI wrote:
>
>
> Do you really not know how to turn the result of ACOS into degrees ?
> I can give you a one-liner, but how then can you check that it is
> right and that you implement it correctly ?
YES i know , i know too that the only useless answer beetween all on
this forum is _yours_ !
--
Damien MATTEI
email: Damien (dot) Mattei (AT) obs*azur (dot) fr
and replace * with -
| |
| Michel OLAGNON 2005-05-27, 4:01 pm |
|
Damien MATTEI wrote:
>
> YES i know ,
Then it is useless that you ask.
> i know too that the only useless answer beetween all on
> this forum is _yours_ !
>
Useless question, useless answer ...
| |
| James Van Buskirk 2005-05-27, 4:01 pm |
| "Michel OLAGNON" <molagnon@ifremer-a-oter.fr> wrote in message
news:429712AC.4070005@ifremer-a-oter.fr...
> By the way, those functions are very bad implementations.
> Hint: real*8 pi
> real*8 zero
> zero = 0.0
> pi = 2 * acos(zero)
Not to mention that it also makes sense to reduce the
argument while a circle is still an integral number of
degrees, rather than a transcendental number of radians:
dcosd = cos(mod(angle,real(360,kind(angle)))*pi/180)
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| glen herrmannsfeldt 2005-05-27, 4:01 pm |
| Damien MATTEI wrote:
> i have this error when porting a Fortran program from tru 64 to Linux:
(snip)
> Reference to unimplemented intrinsic `DACOSD' at (^) (assumed EXTERNAL)
> long_onde.F:423:
> radrad=dacosd(z/rayray) +i
It seems that Fortran doesn't have a DACOSD function.
For comparison purposes only, note that PL/I does have SIND, COSD, TAND,
and ATAND, sine, cosine, tangent, and arctangent in degrees, but still
no ASIND or ACOSD. (No SINHD or TANHD, either.)
-- glen
| |
| Damien MATTEI 2005-06-01, 9:03 am |
| Michel OLAGNON wrote:
>
>
> Damien MATTEI wrote:
>
>
>
> Then it is useless that you ask.
>
>
> Useless question, useless answer ...
>
I have to made a point clear in your mind!
my question was an open question,opened to all ideas, IF they bring
something really usefull which is not case or _yours_ answers
but open questions requires open minds to answer...
--
Damien MATTEI
email: Damien (dot) Mattei (AT) obs*azur (dot) fr
and replace * with -
| |
| Michel OLAGNON 2005-06-01, 9:03 am |
|
Damien MATTEI wrote:
> I have to made a point clear in your mind!
>
> my question was an open question,opened to all ideas, IF they bring
> something really usefull which is not case or _yours_ answers
My answer was "turn the result of ACOS into degrees". It is so simple
that I expressed my wonder on why you asked, and my doubts on how you
would implement it since you gave such a poor example of a DCOSD / DSIND
implementation.
My other answer was to point out those deficiencies, and I hope that
it may avoid that others fall into the same precision trap.
If you don't want your errors being pointed at, don't post on usenet.
>
> but open questions requires open minds to answer...
>
LOL
| |
| Ken Fairfield 2005-06-01, 8:58 pm |
| glen herrmannsfeldt wrote:
> Damien MATTEI wrote:
>
>
>
> (snip)
>
>
>
> It seems that Fortran doesn't have a DACOSD function.
The first place I saw these (SIND, COSD, TAND, ASIND, ACOSD,
ATAND, ATAN2D, COTAND) was in some mid-80's release of VAX Fortran
(yes _VAX_), possibly V3.x. These were the generic names (in analogy
to SIN, COS, etc.) and DACOSD is the name of the double precision
specific version of the generic ACOSD. There should be no need to
reference the this specific name...unless you need to write your own...
IMHO, these were "sugar": nice to have for some problems, but
nothing that a pi/180 (or vice versa) wouldn't fix. :-)
-Ken
--
I don't speak for Intel, Intel doesn't speak for me...
Ken Fairfield
D1C Automation VMS System Support
who: kenneth dot h dot fairfield
where: intel dot com
| |
| glen herrmannsfeldt 2005-06-02, 3:59 am |
| Ken Fairfield wrote:
(snip)
(I wrote)
[color=darkred]
> The first place I saw these (SIND, COSD, TAND, ASIND, ACOSD,
> ATAND, ATAN2D, COTAND) was in some mid-80's release of VAX Fortran
> (yes _VAX_), possibly V3.x. These were the generic names (in analogy
> to SIN, COS, etc.) and DACOSD is the name of the double precision
> specific version of the generic ACOSD. There should be no need to
> reference the this specific name...unless you need to write your own...
VMS is interesting in that they attempted, more than most others,
to have a library independent of the language. If they were trying
to support PL/I such functions would need to exist, though they might
have different names. (PL/I has generic builtin functions, and so as
not to conflict with user functions with similar names the actual
library routines usually have different names. If I remember VMS
they have names like MTH$SIN and others starting with MTH$.)
> IMHO, these were "sugar": nice to have for some problems, but
> nothing that a pi/180 (or vice versa) wouldn't fix. :-)
This subject comes up reasonably often in comp.arch.arithmetic, and I
don't always agree. There seem to be people who believe that argument
reduction should be done as accurately as possible even for very large
arguments. Consider, for example SIN(1E100). It takes something over
100 digits of pi to do the argument reduction, and no single precision
value between 3 and 4 is likely to return 0.E0 when passed to SIN().
With SIND one can do reasonable argument reduction without having to
worry about rounding of irrational numbers. Consider that I might do
SIN(3.1415926535) but the constant might round differently than the
value used to do argument reduction, so the SIN() might not be zero,
even if there is an argument that returns zero. This is also true for
conversion from degrees to radians.
Now, personally I believe that anyone calling SIN with very large
arguments should know that they might get bad answers, but others seem
to disagree.
When I was in high school I knew someone with a brand new HP-55
calculator, and who was sure it always gave perfect answers. For
sin(9.999999999e99) in degrees it did not give zero, but the number is
obviously a multiple of 180.
-- glen
| |
| Jan Vorbrüggen 2005-06-02, 9:02 am |
| > VMS is interesting in that they attempted, more than most others,
> to have a library independent of the language.
Yes, that is MTHRTL.
> If I remember VMS
> they have names like MTH$SIN and others starting with MTH$.)
Quite. Another thing they are good at is name-space management.
Jan
| |
| woodpecker of mistrust 2006-01-11, 11:00 am |
| quote: Originally posted by Michel OLAGNON
Do you really not know how to turn the result of ACOS into degrees ?
I can give you a one-liner, but how then can you check that it is
right and that you implement it correctly ? [/B]
I know how to do this, and I am sure the OP knows how to do this. I had the same problem, but its nice to know the computer solution, not the mathematical solution, in case this problem comes up again, and, if the OP is anything like me, he is stubborn and simply wants to figure out the compiler error rather than do a manual conversion.
Anyway, I have solved this problem halfway. The problem is that g77 does not have implementation for these trig functions, even though they are still considered intrinsic, in the event that they do get implemented.
Go to google, and do a search for g77fix.f, and you should find a link to a text page that has implementation for these functions. I still have not been able to figure out how to override the intrinsic functions, so I have the functions now, I just do not know how to implement them. |
|
|
|
|