Re: [musl] catan(z)

[Rich Felker <dalias@libc.org>]

On Mon, Aug 12, 2024 at 11:00:22AM +0200, Szabolcs Nagy wrote:
> * Damian McGuckin <damianm@esi.com.au> [2024-08-12 13:56:18 +1000]:
> > On Mon, 12 Aug 2024, Damian McGuckin wrote:
> > 
> > > There is some argument that if you handle the special cases at infinity
> > > separately (which I think MUSL should do but I do not have time at the
> > > moment), then one can assume that because pi/2 is irrational, then one
> > > should never have to deal with the end points in the chunk of code where
> > > those two lines of code seen above should appear. I will have a chat
> > > sometime with the guy who wrote that logic in a WG14 paper when I get a
> > > really clear head and can line him up.
> > 
> > Consider
> > 
> > 	atan2(y, x)
> > 
> > For any finite y and finite non-zero x floating point number arguments, i.e.
> > rational numbers, the result of atan2(y, x) must be rational and so is never
> > +/- pi (which is irrational and only occurs when the ration y/x is a
> > mathematical infinity, not an overflowing infinity). So, we can ignore the
> > endpoints as long as our special case handling takes care of the case of
> > zero x.
> > 
> > I think that is correct .... or is my brain still not working properly after
> > too many late nights watching the Olympics.
> 
> well atan2 cannot return exact +-pi, but one would still
> expect the right sign for the quadrant (y=+-0, x<0 case
> or finite y, x=-inf case)
> 
> and then _redupi uses (int)(t/pi+-0.5) where that /pi is
> not exact the same way the +-pi returned from atan2 was
> not exact.
> 
> i.e currently in the atan2==+-pi case the sign gets flipped
> by _redupi (even though double pi < exact pi so no need to
> reduce)
> 
> i doubt the sign flip is needed, but even if that's the
> right result there are better ways to handle that case.

If I'm following, it sounds like the current behavior is either a
no-op or wrong and removing the _redupi step entirely would make it
correct or at least closer to correct. Do you agree?

Any suggestions for a test to run? I did some basic smoke testing for
large positive real inputs and got expected results.

Rich