[avr-libc-dev] Re: [avr-gcc-list] Problem with asin() and acos()

[E. Weddington]

On 2 Oct 2002 at 10:45, Joerg Wunsch wrote:

> address@hidden wrote:
> 
> > In a posting on the avr-gcc mailing list july 27th 
> > Jamie Morken (address@hidden) describes 
> > exactly the same problem.
> > What strokes me in Jamie's desciption is that he gets
> > the same (wrong) result as I did:
> 
> Then it's probably really at fault.
> 
> acos() calls asin(), and just adds Pi/2 to the result, so it's no
> surprise that both are incorrect.  Maybe this approach is error-prone
> for small numbers?
> 
> At a glance, i don't quite understand the algorithm used.  You might
> want to have a look at the implementation of both functions under
> 
> http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/avr-libc/avr-lib
> c/libm/fplib/cos.S?rev=HEAD&content-type=text/plain
> 
> http://savannah.nongnu.org/cgi-bin/viewcvs/*checkout*/avr-libc/avr-lib
> c/libm/fplib/acos.S?rev=HEAD&content-type=text/plain
> 
> It's probably better to discuss this on the avr-libc developer's
> mailing list since it's actually a problem with the library, not
> the compiler:
> 
> address@hidden
> 

My earlier reply got lost in the ether... :-/

Technically, acos(x) = Pi/2 - asin(x). The code in acos.s *looks* 
like it's doing just that. It calls asin(), negates that result, then 
adds it to Pi/2.

So the problem resides in asin(). I took a look at the asin 
implementation in newlib. It calculates a Taylor series for asin(), 
probably to reduce that amount of code needed. The equation there 
looks similar, but not the same, as the one in avrlibc(fplib).

The asin() in avrlibc seems broken. I don't know if the asin() in 
newlib is correct either. I tried some modelling of both algorithms 
in a spreadsheet and I wasn't thrilled with either one.

Jamie Morken said that replacing acos(x); with 
atan2(x, sqrt(1-(x*x))); gave the correct answer. 

asin(x) can be replaced with atan2(sqrt(1-(x*x)), x);

Using this as a replacement would give a correct answer. The down 
side is that it would pull in the atan2 function from the library 
which is not exactly a small footprint.

Any thoughts on rewriting asin() with the atan2() equivalent?

Eric