On Mon, Oct 26, 2009 at 9:12 AM, Nathann Cohen <nathann.co...@gmail.com> wrote: > Hello !! > > I am writing about a problem I had some time ago. Minh helped me to sort it > out. This time, I found an ugly trick, which is fine for the moment ( see > patch #7314 and the Integer(1) instead of 1 at line 6000 of patch > http://trac.sagemath.org/sage_trac/attachment/ticket/7314/trac_7314.patch > ).... > I talked about it with timdumol on IRC, but we had no idea of how to fix it. > Here is the problem : > > Create a file "aaa" containing : > def a(b=8): > return b/3 > > Then, in Sage : > > > sage: def a(b=8): > ....: return b/3 > ....: > sage: a() > 8/3 > sage: execfile("aaa") > sage: a() > 2 > > There is some nasty rounding there, which should not occur.
That is exactly what I would expect to occur. If you do execfile, it's just going to evaluate the *Python* code in the file. In python 8 and 3 are Python int's, which have floor division semantics. Most people agree that floor division semantics as the default for Python int's is a bad design choice. That's why Guido removed it in Python 3.x. > I know the > result could have been different, if I had used "load" instead of > "execfile". Well, I had the same problem when defining a function in the > Graph class, for which this answer is not admissible. If you define any code in any .py (or .pyx) file anywhere in Sage, then the integer literals will be Python ints, which have floor division semantics. This is one of the (thankfully few!) gotcha's that we face as Sage developers as a result of choosing a mainstream programming language instead of inventing our own (like say the Mathemagix developers did). > This kind of bug is not just confusing, it is also the kind of things that > could take hours to debug when the users does not know about it. It is > almost impossible to to it anyway if you do not suspect such a thing. What > could we do about it ? This will simply disappear when we transition to Python 3.x, which will probably happen in about 2 years (?). Of course, then it will be replaced by a new subtlety, which is that you'll get: sage: a() 2.6666666666666665 But at least then it is easier to figure out what happened. Note that one can also turn on the future division behavior now: sage: from __future__ import division sage: int(8)/int(3) 2.6666666666666665 -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
