[sage-support] Re: using len invokes bad division
On Mon, May 4, 2009 at 10:45 AM, kcrisman kcris...@gmail.com wrote: Dear support, I assume this is known, but I am wondering whether it should be treated as a bug, This is not a bug. It's a stupid design decision in Python, which we have to live with until we switch to Python 3.0 or switch to doing from __future__ import division: sage: from __future__ import division sage: len([2,2])/len([2,3,4]) 0.3 or whether someone using len() on lists should be assumed to know it might then be operated on with Python /, not Sage /, as opposed to the preparser catching this sort of thing. sage: len([2,2])/len([2,3,4]) 0 Thanks for any suggestions on what to do with this - right now I have to do sage: Integer(len([2,2]))/Integer(len([2,3,4])) 2/3 Trust me, I understand that Python's int floor division sucks. I'm teaching undergrads about stats using Sage now, and the most obvious line of code to compute the mean of a list gets the answer totally wrong because of this problem. This already caused a lot of confusion. This is definitely not something that should be addressed by the preparser. It could be addressed by rewriting len, but I'm very hesitant to do that, because it will introduce subtle bugs when moving code from preparsed to the library (.py files). The way one might rewrite len would be: sage: import __builtin__ sage: len = lambda x: Integer(__builtin__.len(x)) sage: len([2,2])/len([2,3,4]) 2/3 -- William --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On May 4, 2009, at 10:45 AM, kcrisman wrote: Dear support, I assume this is known, but I am wondering whether it should be treated as a bug, or whether someone using len() on lists should be assumed to know it might then be operated on with Python /, not Sage /, as opposed to the preparser catching this sort of thing. len() is a Python builtin, which is a good indication that it will return Python types (especially when acting on a Python type). In fact, there's no way on the c-api level to return a Sage integer, as len() always returns a c long. This is similar to range returning a list of python ints. sage: len([2,2])/len([2,3,4]) 0 Thanks for any suggestions on what to do with this - right now I have to do sage: Integer(len([2,2]))/Integer(len([2,3,4])) 2/3 Yep, that's how to do it. (Note that only one of the numerator/ denominator needs to be cast, as coercion will cast the other.) sage: Integer(2)/int(3) 2/3 sage: int(2)/Integer(3) 2/3 sage: int(2)/int(3) 0 - Robert --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On May 4, 2009, at 10:53 AM, William Stein wrote: On Mon, May 4, 2009 at 10:45 AM, kcrisman kcris...@gmail.com wrote: Dear support, I assume this is known, but I am wondering whether it should be treated as a bug, This is not a bug. It's a stupid design decision in Python, which we have to live with until we switch to Python 3.0 or switch to doing from __future__ import division: sage: from __future__ import division sage: len([2,2])/len([2,3,4]) 0.3 And I'm not a fan of this behavior either, but in many ways it's less surprising than 0. or whether someone using len() on lists should be assumed to know it might then be operated on with Python /, not Sage /, as opposed to the preparser catching this sort of thing. sage: len([2,2])/len([2,3,4]) 0 Thanks for any suggestions on what to do with this - right now I have to do sage: Integer(len([2,2]))/Integer(len([2,3,4])) 2/3 Trust me, I understand that Python's int floor division sucks. I'm teaching undergrads about stats using Sage now, and the most obvious line of code to compute the mean of a list gets the answer totally wrong because of this problem. This already caused a lot of confusion. This is definitely not something that should be addressed by the preparser. It could be addressed by rewriting len, but I'm very hesitant to do that, because it will introduce subtle bugs when moving code from preparsed to the library (.py files). The way one might rewrite len would be: sage: import __builtin__ sage: len = lambda x: Integer(__builtin__.len(x)) sage: len([2,2])/len([2,3,4]) 2/3 Good point, I hadn't though about that. We could introduce a size() or cardinality() method that returns an Integer, or possibly infinity. - Robert --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On Mon, May 4, 2009 at 11:01 AM, Robert Bradshaw rober...@math.washington.edu wrote: On May 4, 2009, at 10:53 AM, William Stein wrote: On Mon, May 4, 2009 at 10:45 AM, kcrisman kcris...@gmail.com wrote: Dear support, I assume this is known, but I am wondering whether it should be treated as a bug, This is not a bug. It's a stupid design decision in Python, which we have to live with until we switch to Python 3.0 or switch to doing from __future__ import division: sage: from __future__ import division sage: len([2,2])/len([2,3,4]) 0.3 And I'm not a fan of this behavior either, but in many ways it's less surprising than 0. I also don't like it either, but it is *massively* better than getting 0. or whether someone using len() on lists should be assumed to know it might then be operated on with Python /, not Sage /, as opposed to the preparser catching this sort of thing. sage: len([2,2])/len([2,3,4]) 0 Thanks for any suggestions on what to do with this - right now I have to do sage: Integer(len([2,2]))/Integer(len([2,3,4])) 2/3 Trust me, I understand that Python's int floor division sucks. I'm teaching undergrads about stats using Sage now, and the most obvious line of code to compute the mean of a list gets the answer totally wrong because of this problem. This already caused a lot of confusion. This is definitely not something that should be addressed by the preparser. It could be addressed by rewriting len, but I'm very hesitant to do that, because it will introduce subtle bugs when moving code from preparsed to the library (.py files). The way one might rewrite len would be: sage: import __builtin__ sage: len = lambda x: Integer(__builtin__.len(x)) sage: len([2,2])/len([2,3,4]) 2/3 Good point, I hadn't though about that. We could introduce a size() or cardinality() method that returns an Integer, or possibly infinity. We could also redefine len.Can you think of any problems this will cause *besides* when moving code from .sage preparsed files to Python in the Sage library?I can't think of any. -- William --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On May 4, 11:01 am, Robert Bradshaw rober...@math.washington.edu wrote: On May 4, 2009, at 10:53 AM, William Stein wrote: SNIP Good point, I hadn't though about that. We could introduce a size() or cardinality() method that returns an Integer, or possibly infinity. Combinat already uses cardinality() since they need lists to be longer than a C long or even infinity. - Robert Cheers, Michael --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
I assume this is known, but I am wondering whether it should be treated as a bug, This is not a bug. It's a stupid design decision in Python, which we Right, I knew that Python ints behaved this way, I was just surprised that somehow in Sage / didn't change this - I guess it's because most integer input gets preparsed to Integer, right? Trust me, I understand that Python's int floor division sucks. I'm teaching undergrads about stats using Sage now, and the most obvious line of code to compute the mean of a list gets the answer totally wrong because of this problem. This already caused a lot of confusion. Luckily I haven't had that problem - just my own getting weird answers just now! Good point, I hadn't though about that. We could introduce a size() or cardinality() method that returns an Integer, or possibly infinity. That sounds useful; there are already other things that have cardinality() implemented, right? We could also redefine len. I'm not touching that one! :) Thanks for all the insight, - kcrisman --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
Robert Bradshaw wrote: On May 4, 2009, at 10:45 AM, kcrisman wrote: len() is a Python builtin, which is a good indication that it will return Python types (especially when acting on a Python type). In fact, there's no way on the c-api level to return a Sage integer, as len() always returns a c long. This is similar to range returning a list of python ints. Another Python builtin is pow(), but how is it possible that type(pow(2,9,11)) returns type 'sage.rings.integer_mod.IntegerMod_int' Or am I mistaken? Jaap (This comes from a question from a private e-mail) --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On Mon, May 4, 2009 at 12:19 PM, Jaap Spies j.sp...@hccnet.nl wrote: Another Python builtin is pow(), but how is it possible that type(pow(2,9,11)) returns type 'sage.rings.integer_mod.IntegerMod_int' Or am I mistaken? The pow() builtin just calls __pow__ on the first argument in that case, which we control so we can return one of our types. len() will call __len__, but forces whatever is returned to be an int. This is what will be changing in Python 3.0. --Mike --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
On Mon, May 4, 2009 at 12:23 PM, Mike Hansen mhan...@gmail.com wrote: On Mon, May 4, 2009 at 12:19 PM, Jaap Spies j.sp...@hccnet.nl wrote: Another Python builtin is pow(), but how is it possible that type(pow(2,9,11)) returns type 'sage.rings.integer_mod.IntegerMod_int' Or am I mistaken? The pow() builtin just calls __pow__ on the first argument in that case, which we control so we can return one of our types. len() will call __len__, but forces whatever is returned to be an int. This is what will be changing in Python 3.0. However that change will in now way help with the original question. Even in python 3.0 the len(...) of a list is still a Python int. wst...@sage:~$ python3.0 Python 3.0 (r30:67503, Jan 23 2009, 04:39:45) [GCC 4.2.4 (Ubuntu 4.2.4-1ubuntu3)] on linux2 Type help, copyright, credits or license for more information. type(len([1,2,3,4])) class 'int' William --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes bad division
Mike Hansen wrote: On Mon, May 4, 2009 at 12:19 PM, Jaap Spies j.sp...@hccnet.nl wrote: Another Python builtin is pow(), but how is it possible that type(pow(2,9,11)) returns type 'sage.rings.integer_mod.IntegerMod_int' Or am I mistaken? The pow() builtin just calls __pow__ on the first argument in that case, which we control so we can return one of our types. len() will call __len__, but forces whatever is returned to be an int. This is what will be changing in Python 3.0. Than pow? gives a misleading text: Type:type 'builtin_function_or_method' Definition: pow( [noargspec] ) Docstring: pow(x, y[, z]) - number With two arguments, equivalent to x**y. With three arguments, equivalent to (x**y) % z, but may be more efficient (e.g. for longs). type(pow(2,9)) returns type 'sage.rings.integer.Integer' type(pow(2,9) % 11) returns type 'sage.rings.integer.Integer' same for type(2^9 % 11) and type(2**9 % 11) Jaap --Mike --~--~-~--~~~---~--~~ 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 For more options, visit this group at http://groups.google.com/group/sage-support URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
