python ints vs sage ints with respect to powers

[Rado]

Is this by design? I find it more reasonable if ALL arithmetic operation between sage and python int returned a sage int. Am I overlooking some consequences?

>>>print type(int(3) + 3)
>>>print type(int(3) * 3)

>>>print type(3 ** int(3))
>>>print type(int(3) ** 3)

<type 'sage.rings.integer.Integer'>

<type 'sage.rings.integer.Integer'>

<type 'sage.rings.integer.Integer'>

<type 'int'>

We had students experiencing an unpleasant surprise when using range and ^ -2 thus getting back floats instead of QQ (of course they should have been using srange).

Rado

[Dima Pasechnik]

One cannot always get an integer, e.g. 3^-3 cannot be an integer. So the choices for type(int(3)^-3) are QQ or floats - currently Python's.

I see no reason for int(3)^3 not to return a Sage Integer, and for int(3)^-3 not to return a QQ.

I'll report on testing the Sage library after such a change.

Dima

PS. Looking in the corresponding code fragment, one also seems there a weird place, allowing for "blah"^3 to 

be replaced by "blah"*3... This is really strange --- is there a reason for this?

[Simon King]

Hi Dima, hi Rado,

On 5 Sep., 11:58, Dima Pasechnik <dimp...@gmail.com> wrote:
> I see no reason for int(3)^3 not to return a Sage Integer, and for int(3)^-3
> not to return a QQ.

I see a reason:

x^n is recursively defined by
x if n==0
x*x^(n-1) otherwise

Hence, if x is a Python int then x^n should be a Python int (namely
the n-fold product of x with itself) even if n is a Sage Integer.

Cheers,
Simon

[Dima Pasechnik]

On Monday, 5 September 2011 18:45:42 UTC+8, Simon King wrote:

Hi Dima, hi Rado,

On 5 Sep., 11:58, Dima Pasechnik <dim...@gmail.com> wrote:
> I see no reason for int(3)^3 not to return a Sage Integer, and for int(3)^-3
> not to return a QQ.

I see a reason:

x^n is recursively defined by
  x if n==0
  x*x^(n-1) otherwise

x if n==1...

To be precise, I can propose that

x^0 should be 1, (and not int(1)), then 

x^n := x*x^{n-1} for n>0, 

and then multiplication result will a  Sage Integer.

 

Hence, if x is a Python int then x^n should be a Python int (namely
the n-fold product of x with itself) even if n is a Sage Integer.

what about negative n? 

sage: int(3)^-3

0.037037037037037035

sage: type(int(3)^-3)

<type 'float'>

sage: int(3)^QQ(-3)

1/27

sage: type(int(3)^QQ(-3))

<type 'sage.rings.rational.Rational'>

Will you tell me that it is OK that  int(3)^-3 is not equal to int(3)^QQ(-3) ?!

Well, I know that if you compare them then 1/27 gets converted to a float, so == will tell

you they are equal, but still...

This is very weird, to see this happening.

Or, for non-integer n>0? Then it's always a Sage object...

So, somehow an integer exponent is an outcast...

 

Cheers,
Simon

[Simon King]

Hi Dima,

On 5 Sep., 13:12, Dima Pasechnik <dimp...@gmail.com> wrote:
> x if n==1...

Oops...

> To be precise, I can propose that
> x^0 should be 1, (and not int(1)), then
> x^n := x*x^{n-1} for n>0,
> and then multiplication result will a  Sage Integer.

Right, that would be sound.

> sage: int(3)^-3
> 0.037037037037037035
> sage: type(int(3)^-3)
> <type 'float'>
> sage: int(3)^QQ(-3)
> 1/27
> sage: type(int(3)^QQ(-3))
> <type 'sage.rings.rational.Rational'>

That is certainly inconsistent. So, there IS a bug.

> This is very weird, to see this happening.

Agreed.

Best regards,
Simon

[Dima Pasechnik]

this is now #11779

[rjf]

is 4^(-2) (use various kinds of integers) integer rational float?
ditto for
5^(-2) ?

Seems to me that the presence of python integers is an inconsistency
waiting to appear, and
the only proper use of python ints is as a sage integer which happens
to be, at the moment,
small in magnitude.
Lisp does this right, with fixnums automatically promoted to bignums
if they get too big.
Coercion from rational to integer happens if the rational has a
denominator of 1.
There are lots more of these, e.g complex with imag part zero etc.
Do you want
these all to be equal....
1+0*i, 1/1, 1, int(1)? 1.0 1.0d0? maybe.
RJF

On Sep 5, 6:52 am, Dima Pasechnik <dimp...@gmail.com> wrote:
> this is now #11779

[Dima Pasechnik]

On Monday, 5 September 2011 22:41:50 UTC+8, rjf wrote:

is 4^(-2)  (use various kinds of integers)  integer rational float?
ditto for
  5^(-2) ?

Seems to me that the presence of python integers is an inconsistency
waiting to appear,

as brilliantly uncovered by our 2nd year undergrads :)

With the patch I propose one has

sage: type(int(5)^-2)         

<type 'sage.rings.rational.Rational'>

sage: type(int(5)^int(-2))

<type 'float'>

with the idea that if you want to stay Pythonic, you can (the 2nd example), but otherwise you get promoted to the better situation (the 1st example), when everything is exact.

Presently, int()^whatever stays Pythonic, no matter it causes a loss of precision, or not.

One gets bizzare things like:

sage: def f(x): return x^-3

....: 

sage: f(int(3))

0.037037037037037035

sage: var('x')

x

sage: p(x)=x^-3

sage: p(int(3))

1/27

i.e. symbolic functions and the procedures behave drastically differently, etc...

Certain purists argue that I am wrong, and that the loss of precision must be preferred...

 

and
the only proper use of python ints is as a sage integer which happens
to be, at the moment,
small in magnitude.
  Lisp does this right, with fixnums automatically promoted to bignums
if they get too big.
Coercion from rational to integer happens if the rational has a
denominator of 1.
 There are lots more of these, e.g complex with imag part zero etc.
Do you want
these all to be equal....
1+0*i,  1/1, 1, int(1)?   1.0 1.0d0?  maybe.
RJF

[Dima Pasechnik]

By the way, the patch I propose on #11779 passes all (long) tests with Sage 4.7.1 on 64bit Linux.

[Robert Bradshaw]

On Mon, Sep 5, 2011 at 7:41 AM, rjf <fat...@gmail.com> wrote:
> is 4^(-2)  (use various kinds of integers)  integer rational float?
> ditto for
>  5^(-2) ?
>
> Seems to me that the presence of python integers is an inconsistency
> waiting to appear, and
> the only proper use of python ints is as a sage integer which happens
> to be, at the moment,
> small in magnitude.
>  Lisp does this right, with fixnums automatically promoted to bignums
> if they get too big.

Umm... Python ints do this too. Does that mean Python gets it right?

What Python is missing is a rational type, so 5^(-2) is either
truncated or approximated in floating point. (It can be argued that
rationals are not what one wants--computing with rationals can easily
become atrociously expensive.)

Anyway, +1 to fixing this.

> Coercion from rational to integer happens if the rational has a
> denominator of 1.
>  There are lots more of these, e.g complex with imag part zero etc.
> Do you want
> these all to be equal....
> 1+0*i,  1/1, 1, int(1)?   1.0 1.0d0?  maybe.

Yes. We have a clear rule about this in Sage as delineated in the
coercion manual.

> On Sep 5, 6:52 am, Dima Pasechnik <dimp...@gmail.com> wrote:
>> this is now #11779
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

[William Stein]

This is what Sage *should* do, IMHO.

> Certain purists argue that I am wrong, and that the loss of precision must
> be preferred...

These "purists" are usually actually "applied-ists", and for numerical
computation they are often "right". When I'm doing lots of numerical
computation (which I do actually do sometimes), I tend to agree, and
set the relevant modes in Sage.

That said, for consistency with the rest of Sage, e.g., that int(1) +
Integer(2) is an Integer, we should have int(3)^Integer(2) be an
Integer.

>
>>
>> and
>> the only proper use of python ints is as a sage integer which happens
>> to be, at the moment,
>> small in magnitude.
>>   Lisp does this right, with fixnums automatically promoted to bignums
>> if they get too big.
>> Coercion from rational to integer happens if the rational has a
>> denominator of 1.
>>  There are lots more of these, e.g complex with imag part zero etc.
>> Do you want
>> these all to be equal....
>> 1+0*i,  1/1, 1, int(1)?   1.0 1.0d0?  maybe.
>> RJF
>>
>> On Sep 5, 6:52 am, Dima Pasechnik <dim...@gmail.com> wrote:
>> > this is now #11779
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to
> sage-devel+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[rjf]

On Sep 5, 9:31 am, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> On Mon, Sep 5, 2011 at 7:41 AM, rjf <fate...@gmail.com> wrote:
> > is 4^(-2)  (use various kinds of integers)  integer rational float?
> > ditto for
> >  5^(-2) ?
>
> > Seems to me that the presence of python integers is an inconsistency
> > waiting to appear, and
> > the only proper use of python ints is as a sage integer which happens
> > to be, at the moment,
> > small in magnitude.
> >  Lisp does this right, with fixnums automatically promoted to bignums
> > if they get too big.
>
> Umm... Python ints do this too. Does that mean Python gets it right?

In that case, I think it does get it right. I was under the
(apparently mistaken)
impression from the given example, that it got something wrong.

>
> What Python is missing is a rational type, so 5^(-2) is either
> truncated or approximated in floating point.

Ah. So it does get it wrong.

(It can be argued that
> rationals are not what one wants--computing with rationals can easily
> become atrociously expensive.)

And so it is preferable to give a mathematically wrong answer to spend
the time to do it right?

>
> Anyway, +1 to fixing this.
>
> > Coercion from rational to integer happens if the rational has a
> > denominator of 1.
> >  There are lots more of these, e.g complex with imag part zero etc.
> > Do you want
> > these all to be equal....
> > 1+0*i,  1/1, 1, int(1)?   1.0 1.0d0?  maybe.
>
> Yes. We have a clear rule about this in Sage as delineated in the
> coercion manual.

There is a whole manual on coercion?
I looked at section 4.7.1

Unless one is (minimally) schooled in modern algebra and python, it's
not going to make sense.

e.g, will a+b*i divided by c+d*i return a ratio of complex numbers?
or a complex number over a fraction field? If a,b,c are integers, but
d is a float,
what then?

One relatively clean resolution of some of the problems
is to replace every float -- on input -- to
an equivalent rational.

Convert rational to float only when explicitly demanded.

Another model is to do something like what Mathematica does.
I do not recommend it.

RJF

[Jason Grout]

On 9/5/11 5:40 PM, rjf wrote:
> One relatively clean resolution of some of the problems
> is to replace every float -- on input -- to
> an equivalent rational.

It seems like we've had some big problems with this, in that maxima will
sometimes simplify things because it assumes an exact rational number
was entered, when in reality, an approximate number was entered [1].
Maybe a more correct "clean" resolution is to convert every float to a
rational interval, or a float interval, and do interval arithmetic? Of
course, that can get really nasty too...

Jason

[1] See http://trac.sagemath.org/sage_trac/ticket/2400 for example, or
http://trac.sagemath.org/sage_trac/search?q=keepfloat

[leif]

On 5 Sep., 14:13, Simon King <simon.k...@uni-jena.de> wrote:
> Hi Dima,
>
> On 5 Sep., 13:12, Dima Pasechnik <dimp...@gmail.com> wrote:
>
> > x if n==1...
>
> Oops...
>
> > To be precise, I can propose that
> > x^0 should be 1, (and not int(1)), then
> > x^n := x*x^{n-1} for n>0,
> > and then multiplication result will a  Sage Integer.
>
> Right, that would be sound.

BU**SH**.

Who would take the one-element from a different domain (or choose it
to be of different type)?

(I've made some comments on the ticket, also suggesting to put this on
sage-devel, without noticing there had been already this thread. A
back-reference from the ticket wouldn't have been bad.)

The "funniest" thing is the current behaviour of int(3)^CC(-3) or even
int(3)^CC(3) .


-leif

[leif]

On 5 Sep., 17:44, Dima Pasechnik <dimp...@gmail.com> wrote:
> Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> precision, or not.

Not true:

sage: 3r^ZZ(-3)
0.037037037037037035
sage: 3r^QQ(-3)
1/27


I'm strongly against making the result of exponentiation (of e.g.
Python ints) depend on the exponent's *type*; it should only depend on
its *value*, in this case yielding either Python ints or floats in
turn.

Exponentiation isn't commutative (nor associative), in contrast to
multiplication and addition, where a factor / summand of type Integer
makes the product / sum be of Sage's Integer type.


-leif

[leif]

On 5 Sep., 18:33, William Stein <wst...@gmail.com> wrote:
> That said, for consistency with the rest of Sage, e.g., that int(1) +
> Integer(2) is an Integer, we should have int(3)^Integer(2) be an
> Integer.

These are completely different things; see my previous post.


Btw., functions like e.g. gcd() do not preserve the type either, i.e.
type(gcd(int(x),int(y)) is Integer, which is IMHO yet a different
case, but still a bit odd, since the result can certainly be of the
same type as the inputs (assuming they agree), and therefore should
be.

gcd(QQ(x),y) yields a Rational even if x is integer, while xgcd()
returns (Integer,Integer,Integer) for the same inputs.


-leif

[kcrisman]

On Sep 5, 11:43 pm, leif <not.rea...@online.de> wrote:
> On 5 Sep., 18:33, William Stein <wst...@gmail.com> wrote:
>
> > That said, for consistency with the rest of Sage, e.g., that int(1) +
> > Integer(2) is an Integer, we should have int(3)^Integer(2) be an
> > Integer.
>
> These are completely different things; see my previous post.

I don't have a horse in this race, but I think this is certainly worth
thinking carefully about. Neither solution (assuming we want as much
compatibility with Python as possible, pace rjf) is ideal.

What happens in Python 3.x, where I understand there *is* some kind of
rational object? Maybe we should be oriented toward compatibility
with that, if it's relevant. I didn't see a discussion of that in
this thread, my apologies if I missed it.

- kcrisman

[rjf]

On Sep 5, 4:43 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> On 9/5/11 5:40 PM, rjf wrote:
>
> > One relatively clean resolution of some of the problems
> >   is to replace every float -- on input -- to
> > an equivalent rational.
>
> It seems like we've had some big problems with this, in that maxima will
> sometimes simplify things because it assumes an exact rational number
> was entered, when in reality, an approximate number was entered [1].

Is a floating point "input" number an approximate number, or an exact
rational number
that is expressed in a decimal form? Most reasonable numerical
analysis
(exception: Mathematica's significance arithmetic, which is not, in my
opinion, reasonable),
starts from the view that a floating point representation is
fraction X base^exponent.

Not (fraction +-slush) X base^exponent.

> Maybe a more correct "clean" resolution is to convert every float to a
> rational interval, or a float interval, and do interval arithmetic?

no, a float is NOT an interval. it is a number.

 Of
> course, that can get really nasty too...

Presumably you must support intervals, since some of the M's do so,
and Sage is supposed to be an alternative to them...

RJF

[Alex Ghitza]

On Tue, Sep 6, 2011 at 1:51 PM, kcrisman <kcri...@gmail.com> wrote:
> What happens in Python 3.x, where I understand there *is* some kind of
> rational object?  Maybe we should be oriented toward compatibility
> with that, if it's relevant.  I didn't see a discussion of that in
> this thread, my apologies if I missed it.

I'm finding it hard to understand what's going on in Python 3, but here it is:

Python 3.2.2 (default, Sep 5 2011, 04:33:58)
[GCC 4.6.1 20110819 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1/4
0.25
>>> 2**(-2)
0.25

Hmmm. OK, so what's this rational concept number that Python 3 has?
It must be:

>>> from fractions import Fraction
>>> Fraction(1, 4)
Fraction(1, 4)
>>> Fraction(1, 4) + Fraction(2, 3)
Fraction(11, 12)

Ah, alright. However:

>>> Fraction(1/4)
Fraction(1, 4)
>>> Fraction(2/3)
Fraction(6004799503160661, 9007199254740992)

So this can get confusing really quick. What's going on is that
Fraction takes a python float and finds the closest rational
approximation where the denominator is bounded by a default (large)
bound that can be modified by passing an optional argument.

Note that the fractions module is actually present in python 2.6 (so
it's in Sage right now!) but (a) Fraction(1/2) will fail from the sage
prompt because 1/2 is first preprocessed into a Sage rational, and
Fraction() doesn't know what to do with that and (b) even if you do
sage -python you will see different behaviour than in Python 3, e.g.
Fraction(2/3) will return Fraction(0, 1) because in python 2.6 you
have 2/3=0, while in python 3+ you have 2/3=0.66666...

I'm not sure we can stay compatible with Python on this *and* retain our sanity.

Best,
Alex

--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- http://aghitza.org

[Dima Pasechnik]

On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:

On 5 Sep., 17:44, Dima Pasechnik <dim...@gmail.com> wrote:
> Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> precision, or not.

Not true:

sage: 3r^ZZ(-3)
0.037037037037037035
sage: 3r^QQ(-3)
1/27

what is "Not true"? Surely conversion into float is a loss of precision.

No, really, the current behaviour of int()^-k cannot be defended.

If one thinks of  int()^-k as 1/int()^k, and this is, mathematically, the usual

definition of a negative power, it must be an Integer, even if you hold that

int()^k is int; this is the way Sage division works. 

(unless you want to stay Pythonic, and get int(1)/int()^k, i.e. 0 in Python 2, which would be

even more stupid than the current conversion into float)

Now, as int()^-k should to be Integer, so should be int()^k, too.

[leif]

On 6 Sep., 06:05, rjf <fate...@gmail.com> wrote:
> Presumably you must support intervals,  since some of the M's do so,
> and Sage is supposed to be an alternative to them...

Sage does have real and complex interval arithmetic, partially backed
by MPFI.


-leif

[leif]

On 6 Sep., 06:36, Dima Pasechnik <dimp...@gmail.com> wrote:
> On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
>
> > On 5 Sep., 17:44, Dima Pasechnik <dim...@gmail.com> wrote:
> > > Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> > > precision, or not.
>
> > Not true:
>
> > sage: 3r^ZZ(-3)
> > 0.037037037037037035
> > sage: 3r^QQ(-3)
> > 1/27
>
> what is "Not true"?

That currently int()^whatever stays Pythonic (w.r.t. the type of the
result).

> No, really, the current behaviour of int()^-k cannot be defended.
> If one thinks of  int()^-k as 1/int()^k, and this is, mathematically, the
> usual
> definition of a negative power, it must be an Integer, even if you hold that
> int()^k is int; this is the way Sage division works.

Of course int(n)^-k should be int(1)/int(n)^k, yielding either a
Python int or float, to stay "pythonic", or, more precisely, within
Python types.

> (unless you want to stay Pythonic, and get int(1)/int()^k, i.e. 0 in Python
> 2, which would be
> even more stupid than the current conversion into float)

I consider this just a Python "bug" (perhaps inherited from early bad
design), since Python (now) does have explicit integer / truncating
division, a // b.

> Now, as int()^-k should to be Integer, so should be int()^k, too.

The former shouldn't, so the latter shouldn't either. ;-)


-leif

[leif]

On 6 Sep., 07:01, leif <not.rea...@online.de> wrote:
> On 6 Sep., 06:36, Dima Pasechnik <dimp...@gmail.com> wrote:
>
> > On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
>
> > > On 5 Sep., 17:44, Dima Pasechnik <dim...@gmail.com> wrote:
> > > > Presently, int()^whatever stays Pythonic, no matter it causes a loss of
> > > > precision, or not.
>
> > > Not true:
>
> > > sage: 3r^ZZ(-3)
> > > 0.037037037037037035
> > > sage: 3r^QQ(-3)
> > > 1/27
>
> > what is "Not true"?
>
> That currently int()^whatever stays Pythonic (w.r.t. the type of the
> result).

FWIW, float(x)^any indeed always yields a Python float (even for e.g.
x=3.0), with the exception of "any" being CC(y), which (again) fails
with an attribute error, no matter what the value of y is.


-leif

[Dima Pasechnik]

On Tuesday, 6 September 2011 13:01:53 UTC+8, leif wrote:

On 6 Sep., 06:36, Dima Pasechnik <dim...@gmail.com> wrote:
> On Tuesday, 6 September 2011 11:08:02 UTC+8, leif wrote:
> 

[...] 

Of course int(n)^-k should be int(1)/int(n)^k, yielding either a
Python int or float, to stay "pythonic", or, more precisely, within
Python types.

In Python 2, int(1)/int(m) is either 0 or 1, so, what are you talking about?

Do you propose to change how Python 2 behaves?

 

> (unless you want to stay Pythonic, and get int(1)/int()^k, i.e. 0 in Python
> 2, which would be
> even more stupid than the current conversion into float)

I consider this just a Python "bug" (perhaps inherited from early bad
design), since Python (now) does have explicit integer / truncating
division, a // b.

how does this help?

$ python

Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49) 

[GCC 4.2.1 (Apple Inc. build 5646)] on darwin

Type "help", "copyright", "credits" or "license" for more information.

>>> 1//3

0

>>> 

indeed, one can do 

>>> from __future__ import division

>>> 1/3

0.33333333333333331

bu this is beside the point. 

 

> Now, as int()^-k should to be Integer, so should be int()^k, too.

The former shouldn't, so the latter shouldn't either. ;-)

it shouldn't in your imagination only, but not in present Sage's Python.

Dima

 

-leif

[Dima Pasechnik]

 well, on #11779 I am in minority, as some people refuse to acknowledge that exponentiation is often 

a binary operation (say, on positive reals)...

If anyone is still willing to review this ticket, and not just demonstrate how stubborn they can be, this will be appreciated.

[William Stein]

Done.