int / Integer question
John Cremona
preparsing input, but had not realized until recently that the
following would not work:
sage: [q for q in range(100) if q.is_square()]
---------------------------------------------------------------------------
<type 'exceptions.AttributeError'> Traceback (most recent call last)
/home/jec/<ipython console> in <module>()
<type 'exceptions.AttributeError'>: 'int' object has no attribute 'is_square'
--rather, one has to do this
sage: [q for q in range(100) if Integer(q).is_square()]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
or even this:
sage: [Integer(q) for q in range(100) if Integer(q).is_square()]
[0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
if the elements of this list need further Integer methods to be called on them.
I did eventually find the srange() function, but find its name rather
un-guessable. Why s? Why not Irange, say?
--
John Cremona
Paul Zimmermann
> sage: [q for q in range(100) if q.is_square()]
>
> --rather, one has to do this
>
> sage: [q for q in range(100) if Integer(q).is_square()]
> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>
> or even this:
> sage: [Integer(q) for q in range(100) if Integer(q).is_square()]
> [0, 1, 4, 9, 16, 25, 36, 49, 64, 81]
>
> if the elements of this list need further Integer methods to be called on them.
>
> I did eventually find the srange() function, but find its name rather
> un-guessable. Why s? Why not Irange, say?
I also "enjoyed" several times converting from 'int' to 'Integer' and back.
For beginners, this is a real difficulty, and in my opinion range? or xrange?
should give a big warning that the "list of integers" output contains Python
integers, which cannot be mixed with SAGE integers 'Integer'.
It would also be nice to have a pointer from range? to srange (which does
mention the difference between SAGE integers and Python int's).
Finally, is there a valid reason why we have both 'int' and 'Integer'?
(The 'int' type does not seem to have any size limitation.)
Paul
Carl Witty
> I also "enjoyed" several times converting from 'int' to 'Integer' and back.
> For beginners, this is a real difficulty, and in my opinion range? or xrange?
> should give a big warning that the "list of integers" output contains Python
> integers, which cannot be mixed with SAGE integers 'Integer'.
>
> It would also be nice to have a pointer from range? to srange (which does
> mention the difference between SAGE integers and Python int's).
>
> Finally, is there a valid reason why we have both 'int' and 'Integer'?
> (The 'int' type does not seem to have any size limitation.)
types. As far as I know, we don't modify Python at all; removing
'int' would be major surgery, and we're not going to do it.
'Integer' is a Sage type. This means it has lots of useful
mathematical convenience methods (like .is_square()), it participates
in the coercion model, etc. Also, 'Integer' is implemented with GMP,
and 'long' is not, so 'Integer' is much faster for large numbers.
range() and xrange() are Python builtins, so they return Python values
('int' or 'long'), and have documentation that doesn't mention any
other types. srange() was written for Sage.
The final state of affairs, where we have multiple integral types that
show up in different contexts, is certainly annoying; but I don't see
how to avoid it while basing Sage on an unmodified Python; and we get
so much benefit from that decision that I wouldn't want to change it.
Some particular annoyances may be fixable. For instance, you can just
do:
sage: range=srange
to overwrite Python's built-in range with Sage's for the current
command-line session. I suppose we could do that globally on Sage
startup; but 1) this might break other Python code that expects to use
the original range(); and 2) I'm not sure we want to go down the path
of modifying Python's behavior, other than the preparser.
Carl
John Cremona
"Why the s in srange?"!
John
--
John Cremona
Jason Grout
> Thanks for the detailed explanation -- answering all points except
> "Why the s in srange?"!
>
srange = "sage range"?
Jason
William Stein
By the way, I very often use the [a..b] notation, which returns
Sage integers, and is very fast and has the (a..b) generator
notation as well (and is very familiar to Magma users like me):
sage: [q for q in [1..100] if q.is_square()]
[1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
sage: [q for q in (1..100) if q.is_square()]
[1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
sage: [q for q in [1,3,5,..100] if q.is_square()]
[1, 9, 25, 49, 81]
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
John Cremona
use rnage() for loop indices).
John
--
John Cremona
Paul Zimmermann
thank you for your explanations.
> The 'int' (and its bignum counterpart, 'long') are native Python
> types. As far as I know, we don't modify Python at all; removing
> 'int' would be major surgery, and we're not going to do it.
>
> 'Integer' is a Sage type. This means it has lots of useful
> mathematical convenience methods (like .is_square()), it participates
> in the coercion model, etc. Also, 'Integer' is implemented with GMP,
> and 'long' is not, so 'Integer' is much faster for large numbers.
Would it be possible to extend long by new methods like is_square, and get
rid of Integer?
I guess 'long' is based on GMP too, does it make sense to have two concurrent
interfaces to GMP integers?
Paul Zimmermann
pgdoyle
On Jan 22, 2:17 pm, Carl Witty <cwi...@newtonlabs.com> wrote:
> 'Integer' is a Sage type. This means it has lots of useful
> mathematical convenience methods (like .is_square()), it participates
> in the coercion model, etc. Also, 'Integer' is implemented with GMP,
> and 'long' is not, so 'Integer' is much faster for large numbers.
are so much faster?
Cheers,
Peter Doyle
William Stein
> thank you for your explanations.
>
> > The 'int' (and its bignum counterpart, 'long') are native Python
> > types. As far as I know, we don't modify Python at all; removing
> > 'int' would be major surgery, and we're not going to do it.
> >
> > 'Integer' is a Sage type. This means it has lots of useful
> > mathematical convenience methods (like .is_square()), it participates
> > in the coercion model, etc. Also, 'Integer' is implemented with GMP,
> > and 'long' is not, so 'Integer' is much faster for large numbers.
>
> Would it be possible to extend long by new methods like is_square, and get
> rid of Integer?
No, not without changing Python. The semantics of the two types are almost
totally different. As Carl Witty explained, having these two
distinct long integer
types is part of the "price" we pay by using an unmodified Python
interpreter for
Sage. The benefit is that we immediately are working with a language that
has *millions* of users, and huge standard library, and very powerful packages
available such as numpy, scipy, twisted etc. I think the pros more
than outweigh
the cons, though it won't be surprising of people disagree with me -- after all
every other popular computer algebra system besides Sage reinvents its own
language.
> I guess 'long' is based on GMP too, does it make sense to have two concurrent
> interfaces to GMP integers?
> Paul Zimmermann
long is _not_ based on GMP. long is implemented from scratch in C by the
Python developers. It is completely independent from GMP, and has much
different performance characteristics, storage formats, etc.
On Jan 23, 2008 5:18 AM, pgdoyle <petergr...@gmail.com> wrote:
> Why does Python not use the GMP routines for long integers, if they
> are so much faster?
Despite it's huge standard library, Python is relative easy to build
from source on a huge
range of architectures -- e.g., a full Python interpreter is installed
on my iphone; there
was one on my plam treo before. GMP is far more difficult to
build. I think that's
the core reason why Python does not use GMP, and it's a really good
one. Also, keep
in mind that very fast arbitrary precision integer arithmetic is
hardly relevant for 99.9999%
of Python applications (text processing, networking, quick and dirty
GUI's), and Python
longs aren't that bad when the integer size isn't too big.
mabshoff
On Jan 23, 2:29 pm, "William Stein" <wst...@gmail.com> wrote:
> On Jan 22, 2008 11:48 PM, Paul Zimmermann <Paul.Zimmerm...@loria.fr> wrote:
<SNIP>
> > I guess 'long' is based on GMP too, does it make sense to have two concurrent
> > interfaces to GMP integers?
> > Paul Zimmermann
>
> long is _not_ based on GMP. long is implemented from scratch in C by the
> Python developers. It is completely independent from GMP, and has much
> different performance characteristics, storage formats, etc.
GMP. Somebody posted prototype bindings on one of the GMP mailing
lists about 2 months ago.
<SNIP>
Cheers,
Michael
William Stein
I'm skeptical even though I wish you were right. Just because
somebody posted some
prototype bindings on Py3K mailing list doesn't mean anything about what will
actually go into Py3K. I remember watching Guido v. Rosum walking around
at Pycon 2005 in Washington D.C.. Basically people would walk up to him,
and try to convince him to make some change to Python. It was the
first time I heard
the phrase "this conversation is over", which he would utter when
pushed too hard.
Anyway, I searched the Py3K mailing list and there were some patches
in October 2007.
But they were just hacks to see how Python's standard benchmark
timings would change
with GMP versus without. Having GMP replacing all integer arithmetic
made Python
20% slower (since GMP doesn't special case small integers and Python
is very optimized
for small integers). Another patch just used GMP for Python long's
and only made Python's
standard benchmark 2% slower. But there was no discussion that I
could find, especially
nothing by Guido who has final say about everything in Python, about
the many subtle issues
with making Python depend on GMP by default.
I also remember seeing a very nice talk by Guido at SciPy 2006 in July
2006 about how Py3K
as about a year away :-), i.e., might come out in late 2007.
William