[Bug fortran/27452] New: gfortran support for non-standard sind,cosd and friends intrinsics

[Bug fortran/27452] New: gfortran support for non-standard sind,cosd and friends intrinsics

[deji_aking at yahoo dot ca]

I will like to request gfortran's support for intrinsic functions that returns
trigonometric functions in degrees, i.e sind,cosd etc. I understand these are
not part of standard fortran intrinsic, but a couple other fortran compilers
provides them.

Thanks.


-- 
           Summary: gfortran support for non-standard sind,cosd and friends
                    intrinsics
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: deji_aking at yahoo dot ca


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2006-05-06 06:14 -------
Why?

Is it that difficult to write a module
to provide sind and friends?


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[pinskia at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]



------- Comment #2 from pinskia at gcc dot gnu dot org  2006-05-06 06:22 -------
In fact it is easy to divide by 90° and multiply by pi.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[deji_aking at yahoo dot ca]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]



------- Comment #3 from deji_aking at yahoo dot ca  2006-05-06 06:32 -------
(In reply to comment #2)
> In fact it is easy to divide by 90° and multiply by pi.
> 
You just proved my point, one would want to divide by 180 and multiply by pi
;).
Having sind and co safeguard against such silly mistake.
fair enough, i'll continue using my self-made functions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[sgk at troutmask dot apl dot washington dot edu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]



------- Comment #4 from sgk at troutmask dot apl dot washington dot edu  2006-05-06 13:38 -------
Subject: Re:  gfortran support for non-standard sind,cosd and friends
intrinsics

On Sat, May 06, 2006 at 06:32:01AM -0000, deji_aking at yahoo dot ca wrote:
> 
> 
> ------- Comment #3 from deji_aking at yahoo dot ca  2006-05-06 06:32 -------
> (In reply to comment #2)
> > In fact it is easy to divide by 90° and multiply by pi.
> > 
> You just proved my point, one would want to divide by 180 and multiply by pi
> ;).
> Having sind and co safeguard against such silly mistake.
> fair enough, i'll continue using my self-made functions.
> 

Which is faster?  Multiplying and dividing by a literal constant
directly in your code or a function call to do the trivial work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[deji_aking at yahoo dot ca]

------- Comment #5 from deji_aking at yahoo dot ca  2006-05-06 16:24 -------
(In reply to comment #4)
> 
> Which is faster?  Multiplying and dividing by a literal constant
> directly in your code or a function call to do the trivial work.
> 
Really, I don't know enough about compiler technology to ba able to tell.
Having had to deal with an empirical formulas made of a bunch of trig.
functions (in degrees), i found it much convenient to just use sin_d(angle)
instead of multiplying and diving by literal constants in each and all terms.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-05-06 16:29 -------
I should note that sind sounds to me sin taking a double precision agrument at
least when I read the summary and not the first comment.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-05-29 22:25 -------
Also note when I see d, I think double and not degrees when it comes to
intrinsics.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[ruben at tapir dot caltech dot edu]

------- Comment #8 from ruben at tapir dot caltech dot edu  2009-04-30 07:33 -------
In my considered opinion, the need to support these functions has little to do
with efficiency or with convenience.  It has more to do with accuracy and
symmetries; relations such as sind(30)=0.5, cosd(90)=0.0, and such must be
fulfilled exactly, and that without damaging finite-differencing properties. 
Relations such as sind(x)=cosd(90-x) may also be fulfilled to sufficient
accuracy - and maybe even exactly.  These things are difficult or impossible to
achieve using radian units, giving niche use to the degree-based functions for
applications where high floating point accuracy of symmetries must be
preserved.  Angular grids in curvilinear CFD occassionally need that.  There
must be other examples.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[ruben at tapir dot caltech dot edu]

------- Comment #9 from ruben at tapir dot caltech dot edu  2009-04-30 07:38 -------
Someone suggested multiplying or dividing the argument by a factor.
That does not do - the floating point precision achieved would be insufficient.

Someone complains about the names of these functions.  I don't care one way or
the other about that - I need the functions, I don't care about the spelling -
they are not in the standard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[steven at gcc dot gnu dot org]

------- Comment #10 from steven at gcc dot gnu dot org  2009-04-30 07:51 -------
These functions will *not* be implemented, period.

And even if they would be implemented, they'd internally just return
sin(arg*180/pi) & co. The compiler and the runtime library don't actually
calculate sin/cos themselves. They rely on libc and often on machine
instructions, and they all work in radians too.

End of discussion -- move along...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[sgk at troutmask dot apl dot washington dot edu]

------- Comment #11 from sgk at troutmask dot apl dot washington dot edu  2009-04-30 16:09 -------
Subject: Re:  gfortran support for non-standard sind,cosd and friends
intrinsics

On Thu, Apr 30, 2009 at 07:38:31AM -0000, ruben at tapir dot caltech dot edu
wrote:
> 
> 
> ------- Comment #9 from ruben at tapir dot caltech dot edu  2009-04-30 07:38 -------
> Someone suggested multiplying or dividing the argument by a factor.
> That does not do - the floating point precision achieved would be insufficient.
> 

Yep.  I even wrote the necessary code.  You're more than welcomed 
to improve it.

http://gcc.gnu.org/ml/fortran/2006-12/msg00329.html

You need to
  (1) Treat special cases.
  (2) Add argument reduction in degrees.
  (3) Treat special cases of the reduced argument.
  (4) Convert to radians and use the hardware FPU,
      or implement a Remes polynomial approximation
      to evaluation the function in degrees.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452

[Bug fortran/27452] gfortran support for non-standard sind,cosd and friends intrinsics

[ruben at tapir dot caltech dot edu]

------- Comment #12 from ruben at tapir dot caltech dot edu  2009-05-05 09:36 -------
(In reply to comment #10)
> These functions will *not* be implemented, period.
> 
> And even if they would be implemented, they'd internally just return
> sin(arg*180/pi) & co. The compiler and the runtime library don't actually
> calculate sin/cos themselves. They rely on libc and often on machine
> instructions, and they all work in radians too.
> 
> End of discussion -- move along...

I am happy enough with this decision.
It is much better to have them consciously not implemented that having them
implemented with dubious floating point accuracy.

So, I'm moving along.  I'm working on an implementation for myself right now,
which needs only to satisfy my present accuracy requirements - it does not need
to be a quality-grade implementation.  I've seen that doing the argument
reduction in degrees first does most of the trick for me.  Surely much better
can be done, especially for the inverse trig functions (which I do not need
right now) - if you can afford the runtime cost.  I'll look into Kargl's list
of suggestions.

There is no algorithm that would satisfy all users - those who need more
accuracy will be willing to spend more runtime than others.
Some programmers find that the usual math libraries are already too accurate
for some of their needs, and sometimes hand-code faster (but less accurate)
replacements.  Good for them!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27452