Make sin(0), log(1) and similar expressions return Sage integers, not Python ints #10133
Description
From this thread:
> > sage: type(log(1))
> > <type 'int'>
> > sage: log(1).n()
> > ---------------------------------------------------------------------------
> > AttributeError: 'int' object has no attribute 'n'
> > sage: Integer(log(1)).n()
> > 0.000000000000000
> > sage: a = Integer(1)
> > sage: a.log()
> > 0
> > sage: type(a.log())
> > <type 'int'>
> > sage: from sage.functions.log import function_log
> > sage: function_log(Integer(1))
> > 0
> > sage: type(function_log(Integer(1)))
> > <type 'int'>
>
> > Is there any way to get around this in the code, or are we pretty much
> > stuck with this because of how GinacFunctions work? I'm not 100% sure
> > this is a bug in log; maybe instead we should extend int so that
>
> This is a bug in the log() function, and any other function which
> returns exact values like 0 or 1. We already work around most cases,
> see lines 720-722 and 736-761 of sage/symbolic/function.pyx.
>
> The correct fix is to change the corresponding pynac functions to
> coerce the exact value to the parent of the argument before returning
> it. For example, all the lines "return _ex1;" or "return _ex0;" in
>
> http://pynac.sagemath.org/hg/file/b233d9dadcfa/ginac/inifcns_trans.cpp
>
> has to be changed this way.
>
Yup, I see what you are talking about - e.g.
if (x.is_equal(_ex1)) // log(1) -> 0
return _ex0;
Although it might be nice to stay relatively close to Ginac and fix such things on the Sage level if that's not really bad.
This ticket's goal is to implement one of these solutions (that is, catch this in function.pyx or in Pynac).
We might as well also deal with sin(0), tan(0), sin(pi) from #10972 here as well, otherwise that really wasn't a duplicate.
Depends on #17130
CC: @eviatarbach
Component: symbolics
Keywords: type coercion symbolic
Author: Jeroen Demeyer
Branch: c8c26e1
Reviewer: Ralf Stephan
Issue created by migration from https://trac.sagemath.org/ticket/10133