1. You can use srange which works like range but gives a list of Sage
integers.
2. To coerce an int to a Sage Integer just use ZZ():
sage: srange(1,4)
[1, 2, 3]
sage: [type(i) for i in srange(1,4)]
[,
,
]
sage: range(1,4)
[1, 2, 3]
sage: [type(i) for i in range(1,4)]
[, , ]
sage: [type(ZZ(i))
Well, the real cure is to use IntegerRange instead of range.
Sorry to bother those of you who actually can read a manual.
On Friday, February 15, 2019 at 2:56:14 PM UTC-8, Michael Beeson wrote:
>
> def test(p,q):
> t = p/q;
> print(p,q,p/q,t)
> def test2():
> for p in range(1,4):
> for q in
And it can be fixed by inserting
p = sage.rings.integer.Integer(p)
after p is generated by range.
Comments on this still welcome. This may be a dumb question but
now I'm worried that perhaps this problem exists silently elsewhere in my
code.
On Friday, February 15, 2019 at 2:56:14 PM
I see by inserting print(type(p)) that range produces objects of type int,
while when it's called from top-level the types of p and q are
sage.rings.integer.Integer.
So that answers "why" but not "how to prevent".
On Friday, February 15, 2019 at 2:56:14 PM UTC-8, Michael Beeson wrote:
>
>
