[sage-support] Re: randint - Maybe one bug !
On 09/19/2012 07:23 PM, Christophe BAL wrote: Hello, you're right my example is too long. Here is a better example where you can see that the use of ``1*randint(-20, 20)`` instead of ``randint(-20, 20)`` will produce fractions instead of integer divisisons. I really think that this is illogical. Don't you ? This is not illogical. It is how the Sage preparser works. sage: 1*randint(1,20)/randint(20,30) 16/25 sage: preparser(False) sage: 1*randint(1,20)/randint(20,30) 0 Look at preparse? and preparser? -- 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.
Re: [sage-support] randint - Maybe one bug !
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.
Re: [sage-support] randint - Maybe one bug !
On Wed, Sep 19, 2012 at 12:42 PM, 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 ? It's not Sage division vs. Python division, it's Sage Integers vs. Python ints. At the Sage console, input lines are preparsed to wrap numbers like 1 to 4 in Integer calls: sage: 1/4 1/4 sage: preparse(1/4) 'Integer(1)/Integer(4)' In fact, you could even turn the preparser off, and recover Python's behaviour: sage: preparser(False) sage: 1/4 0 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.
Re: [sage-support] randint - Maybe one bug !
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.
