log(1) returns int, not Integer

[kcrisman]

Dear all, but mostly Burcin,

----------------------------------------------------------------------
| Sage Version 4.6.alpha3, Release Date: 2010-10-08 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
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

sage: int(3).n()
AttributeError: 'int' object has no attribute 'n'
sage: n(int(3))
3.00000000000000

have the same output.

Thanks for any feedback,

- kcrisman

[Burcin Erocal]

Hi Karl-Dieter,

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.

Unfortunately I won't have time to work on this at least until January.

Cheers,
Burcin

[kcrisman]

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.

Anyway, thanks for the feedback; this is all now
http://trac.sagemath.org/sage_trac/ticket/10133

- kcrisman

[Francois Maltey]

Hi Karl-Dieter and Burcin,

You wrote (I cut a lot)

> 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 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.
>

I don't understand where and when these lines are used ?
I notice there are no name about usual functions (sin, cos, log, exp) in
this file
So I don't understand how this filter (from int(0) to integer(0)) can be
done.

Are they just call just arround Pynac.
But I feel it's ...local/lib/python2.6/site-packages/sage/functions/log.py

Francois M.

[Burcin Erocal]

Hi Francois,

On Fri, 15 Oct 2010 21:46:36 +0200
Francois Maltey <fma...@nerim.fr> wrote:

> You wrote (I cut a lot)
> > 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 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.
> >
> I don't understand where and when these lines are used ?
> I notice there are no name about usual functions (sin, cos, log, exp)
> in this file
> So I don't understand how this filter (from int(0) to integer(0)) can
> be done.

That file defines the basic behavior of symbolic functions in Sage.

The class GinacFunction is the base class for functions provided by
GiNaC/pynac. The wrapper classes for these functions inherit from this
class, so they get the __call__() method, which is used when you call a
function. So the command ln(1) actually goes through that __call__()
method.

Cheers,
Burcin