Make sin(0), log(1) and similar expressions return Sage integers, not Python ints

[kcrisman]

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

[kcrisman]

comment:1

#10972 was closed as a duplicate. Ironic that I reported both, though in my defense, that ticket does list a few specific functions beyond log for which that happens, and it was 8 months ago :)

[sagetrac-dsm]

comment:2

ping. I just noticed this in a different context.

[kcrisman]

comment:4

See also this sage-devel thread.

[kcrisman]

comment:5

See also this sage-devel thread, where it seems that the consensus is that such things should give Sage Integers, though at #10972 Burcin seems to suggest that symbolic expressions are appropriate.

[kcrisman]

Changed keywords from none to type coercion symbolic

[jdemeyer]

Dependencies: #17130

[jdemeyer]

Author: Jeroen Demeyer

[jdemeyer]

Branch: u/jdemeyer/ticket/10133

[jdemeyer]

Commit: c8c26e1

[jdemeyer]

New commits:

6d10729	Simplify numerical evaluation of BuiltinFunctions
b6e1ed4	Merge remote-tracking branches 'origin/u/jdemeyer/ticket/17131' and 'origin/u/jdemeyer/ticket/17133' into ticket/17130
382f97a	Merge branch 'u/jdemeyer/ticket/17130' of trac.sagemath.org:sage into 6.5beta1
7265989	17130: reviewer's patch: fix typo
c47dbd4	Fix Trac #17328 again in a better way
a486db2	Call the factorial() method of an Integer
c8c26e1	Convert Ginac function results to the correct parent

[rwst]

comment:15

Looks good and passes make ptestlong.

[rwst]

Reviewer: Ralf Stephan

[vbraun]

Changed branch from u/jdemeyer/ticket/10133 to c8c26e1

[rwst]

comment:17

Actually this should have been fixed in Pynac. Now, accidentally the recent patches dealing with pynac/pynac#7 automatically produce this behaviour. Which will be Pynac-0.4.4. The wrapper from this ticket should then be removed.

[rwst]

Changed commit from c8c26e1 to none