I agree that this is a surprising and unfortunate wart in the was Sage
is built. I would explain it like this:

Python has an integer type int that has several surprising behaviors
(from a mathematicians perspective, e.g. division). For this reason we
created our own time, Integer, that behaves better (and has a whole
lot more functionality, e.g. factoring). It's not the division that's
different, but the types (the same way integers and floating point
numbers and polynomials, etc. are all different types and do their own
kind of division). These are We do some magic so that any integer you
type becomes the Sage Integer, but builtin Python functions still
return Python integers so beware.

At this level, it's probably safe to wrap anything your unsure of in
ZZ(...) or Integer(...). Changing internal Python functions to return
Sage integers would be technically difficult and very backwards
incompatible (considering the number of Python packages, including
internally in our own libraryies, that understand and expect Python
ints).

- Robert

On Wed, Sep 19, 2012 at 9:42 AM, Christophe BAL <projet...@gmail.com> wrote:
> What I think very confusing is that 1/4 is the Sage division and not the
> Python standard one, so why it would be different for randint ?
>
> I'm a teacher and the problem is not from my point of view but it will be a
> tricky thing to explain to my students which are in "french lycée" (sorry, I
> don't know the english equivalent level). There are only 18 years old and
> the programmation is only a tool...
>
> Christophe
>
>
> 2012/9/19 D. S. McNeil <dsm...@gmail.com>
>
>> > I really think that this is illogical. Don't you ?
>>
>> No, because it's perfectly consistent.
>>
>> I can see why it's not obvious, though -- and for related reasons, in
>> Python 3 the division of two ints produces a float (or in Python 2 if
>> you `from __future__ import division`).  That won't help us much
>> though because we need to preprocess ints into Integers anyway.
>>
>> > I guess that here there are some Sage-type conversions coming from
>> > ``+/- 1*...``.
>>
>> Yep.  You're multiplying a Sage Integer by a Python integer, which
>> produces a Sage Integer.
>>
>> > From my point of view, using in Sage,  ``randint`` should produce Sage
>> > integers and not Python integer.
>>
>> Not an unreasonable expectation, although I would probably suggest
>> using a different name for the function instead to prevent confusion
>> with random.randint.
>>
>> But in the case of integers, you could also get a random integer right
>> from ZZ instead (with randrange behaviour instead of randint):
>>
>> sage: ZZ.random_element(10, 20)
>> 13
>>
>> So I could take or leave adding another function.
>>
>>
>> Doug
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sage-support" group.
>> To post to this group, send email to sage-support@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sage-support+unsubscr...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/sage-support?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-support" group.
> To post to this group, send email to sage-support@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-support+unsubscr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-support?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To post to this group, send email to sage-support@googlegroups.com.
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support?hl=en.


Reply via email to