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.66666666666666663 > 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 -~----------~----~----~----~------~----~------~--~---
