#10133: Make sure log(1) returns an Integer, not an int
-------------------------+--------------------------------------------------
Reporter: kcrisman | Owner: burcin
Type: defect | Status: new
Priority: major | Milestone: sage-5.0
Component: symbolics | Keywords:
Work_issues: | Upstream: N/A
Reviewer: | Author:
Merged: | Dependencies:
-------------------------+--------------------------------------------------
Description changed by kcrisman:
Old description:
> From [http://groups.google.com/group/sage-
> devel/browse_thread/thread/cceabb7271022b1c/944c94af910269a0 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).
New description:
From [http://groups.google.com/group/sage-
devel/browse_thread/thread/cceabb7271022b1c/944c94af910269a0 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.
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10133#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
