This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]