Steven D'Arpano wrote:

> On Fri, Jun 08, 2018 at 11:11:09PM +0200, Adam Bartoš wrote:
> 
>> But if there are both sin and dsin, and you ask about the difference
>> between them, the obvious answer would be that one takes radians and the
>> other takes degrees. The point that the degrees version is additionally
>> exact on special values is an extra benefit.
> 
> No, that's not an extra benefit, it is the only benefit!
> 
> If we can't make it exact for the obvious degree angles, there would be 
> no point in doing this. We'd just tell people to write their own 
> two-line functions:
> 
> def sindeg(angle):
>     return math.sin(math.radians(angle))
> 
> 
> The only reason to even consider making this a standard library function 
> is if we can do better than that.

I agree completely, I just think it doesn't look obvious. 

>> It would be nice to also fix the original sin,
>
> The sin function is not broken and does not need fixing.
> 
> (Modulo quirks of individual platform maths libraries.)
> 
> 
>> or more precisely to provide a way to give it a
>> fractional multiple of pi. How about a special class PiMultiple that would
>> represent a fractional multiple of pi?
 >
> What is the point of that? When you pass it to math.sin, it still needs 
> to be converted to a float before sin can operate on it.
> 
> Unless you are proposing a series of dunder methods __sin__ __cos__ and 
> __tan__ to allow arbitrary classes to be passed to sin, cos and tan, the 
> following cannot work.

The idea was that the functions could handle the PiMultiple instances in a special way and fall back to float only when a special value is not detected. It would be like the proposed dsin functionality, but with a magic class instead of a new set of functions, and without a particular choice of granularity (360 degrees).
But maybe it isn't worth it. Also what about acos(0)? Should it return PiMultiple(1, 2) and confuse people or just 1.5707963267948966 and loose exactness?

Best regards,
Adam Bartoš