[sage-support] Re: using len invokes "bad" division
Mike Hansen wrote: > On Mon, May 4, 2009 at 12:19 PM, Jaap Spies wrote: >> Another Python builtin is pow(), but how is it possible that >> type(pow(2,9,11)) returns >> >> >> 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: >> 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(pow(2,9) % 11) returns 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 -~--~~~~--~~--~--~---
[sage-support] Re: using len invokes "bad" division
On Mon, May 4, 2009 at 12:23 PM, Mike Hansen wrote: > > On Mon, May 4, 2009 at 12:19 PM, Jaap Spies wrote: >> Another Python builtin is pow(), but how is it possible that >> type(pow(2,9,11)) returns >> >> >> 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])) 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 Mon, May 4, 2009 at 12:19 PM, Jaap Spies wrote: > Another Python builtin is pow(), but how is it possible that > type(pow(2,9,11)) returns > > > 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
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 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 11:13 AM, kcrisman wrote: > >> >>> 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! :) Well it's really just random chance that I didn't redefine len in sage.all back in 2005. If I had, then len would likely still be redefined now and we wouldn't be having this conversation. I'm not sure this isn't a good idea. I just don't know. It's a question of pros versus cons, and so far I see more pros than cons. -- 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
> >>> 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
On May 4, 11:01 am, Robert Bradshaw wrote: > On May 4, 2009, at 10:53 AM, William Stein wrote: > 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
On Mon, May 4, 2009 at 11:01 AM, Robert Bradshaw wrote: > > On May 4, 2009, at 10:53 AM, William Stein wrote: > >> On Mon, 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, >> >> 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, 2009, at 10:53 AM, William Stein wrote: > On Mon, 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, > > 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 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 Mon, 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, 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 -~--~~~~--~~--~--~---
