On Wed, Jun 11, 2008 at 3:16 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > 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
Actually here: http://code.google.com/p/sympy/issues/detail?id=882 (the patch above is for the other bug). When both patches get reviewed and into sympy, I'll expand the test coverage in SAGE_ROOT/devel/sage/sage/calculus/test_sympy.py, even though we do test for these two bugs in sympy too now. But the tests in Sage will be useful too, because they will fail if something changes in Sage in an incompatible way. 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 -~----------~----~----~----~------~----~------~--~---
