On Wed, Jun 11, 2008 at 2:56 PM, William Stein <[EMAIL PROTECTED]> wrote: > > On Wed, Jun 11, 2008 at 2:46 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: >> >> On Wed, Jun 11, 2008 at 2:32 AM, mabshoff <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> On Jun 10, 5:27 pm, "William Stein" <[EMAIL PROTECTED]> wrote: >>>> On Tue, Jun 10, 2008 at 2:04 PM, mabshoff <[EMAIL PROTECTED]> wrote: >>>> >>>> > Riccardo Gori wrote: >>>> >> Hello, >>>> >>>> > Hi Riccardo, >>>> >>>> > I have also forwarded your email to sage-devel. >>>> >>>> >> In SAGE-3.0.2 with a Intel Mac OSX 10.5 I found the following bug: >>>> >>>> >> If I create a sympy matrix and if I try to access it it gives me an >>>> >> error. >>>> >> Step to reproduce: >>>> >>>> >> sage: import sympy >>>> >> sage: M = sympy.Matrix( (2,3) ) >>>> >> sage: sympy.pprint M[0] >>>> >> Traceback (most recent call last): >>>> >> File "<stdin>", line 1, in <module> >>>> >> File >>>> >> "/Users/riccardo/.sage/sage_notebook/worksheets/admin/3/code/299.py", >>>> >> line 7, in <module> >>>> >> M[Integer(1)] >>>> >> File >>>> >> "/Applications/sage/local/lib/python2.5/site-packages/sympy/plotting/", >>>> >> line 1, in <module> >>>> >> File >>>> >> "/Applications/sage/local/lib/python2.5/site-packages/sympy/matrices/matrices.py", >>>> >> line 150, in __getitem__ >>>> >> assert len(key) == 2 >>>> >> TypeError: object of type 'sage.rings.integer.Integer' has no len() >>>> >> sage: sympy.pprint M[int(0)] >>>> >> 2 >>>> >>>> > This is most likely an integration issue and I assume that if you use >>>> > Python ints the problem will go away. One aspect there is certainly >>>> > that Sympy is not integrated into Sage's coercion model. >>> >>> Hi, >>> >>>> This is a bug in Sympy: >>> >>> we do not ship the latest Sympy release and some very similar sounding >>> issue was fixed in the last release, so maybe somebody should verify >>> that it is still broken in the latest release and then file a bug >>> report with Sympy. Otherwise we should upgrade Sympy in Sage to the >>> latest release. >>> >>>> sage: import sympy >>>> sage: M = sympy.Matrix( (2,3) ) >>>> sage: M >>>> [2] >>>> [3] >>>> sage: M[0] >>>> TypeError Traceback (most recent call last) >>>> ... >>>> >>>> Sympy *should* call the __index__ method on the input object >>>> in __getitem__, but it doesn't. The __index__ method is supported >>>> by Sage integers, and was added (by Travis Oliphant) in Python 2.5 >>>> for exactly the above reason. >>>> >>>> I've cc'd this email to Ondrej Certik and hope he can post a bug >>>> report to the sympy bug tracker. >> >> http://code.google.com/p/sympy/issues/detail?id=882 >> >> I'll fix it by the next release and then create a Sage spkg. >> >> So far I was updating sympy in Sage once in couple releases (or if >> there was a bug like this one), but if there is interest, I'll update >> it with each release. >> >> Thanks a lot for all these bug reports, we always write a test for it, >> so once it's fixed, it will never happen again. >> >> In the long term, how can we easily and reliably test these things? >> I.e. this happens when 1 is preparsed to Integer(1). I was thinking >> for example of putting sympy tests into the installed files, so that >> once can do >> >> import sympy >> sympy.test() >> >> just like numpy or scipy. But this would not catch the problems with >> preparsing 1 to Integer(1). (But maybe it could catch some other >> problems, so I think it's worthy.) >> >> So the only method that I know of is simply write a precise test for >> each case by hand and try to cover all possible combinations. That's >> also the most robust. > > There is a file in sage: > > SAGE_ROOT/devel/sage/sage/calculus/test_sympy.py > > for testing use of sympy from Sage. You could submit a patch > that greatly increases the number of tests in there. In particular, > you could add a test for the above problem. That way if this > were to happen again it would get picked up by the Sage test > suite.
Right, that's the way to go, because the test_sympy.py uses preparsing. > > I think this is reasonable since this problem was a Sympy/Sage > integration bug, rather than a Sympy bug. It is a sympy bug, because sympy should just work with any user defined classes (that support either __int__ or __float__). But I just fixed that and send a patch for a review here: http://code.google.com/p/sympy/issues/detail?id=881 Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
