zip() argument after * must be a sequence

[Groover]

Hello,

It's been 20 years since I did any calculus, so please be gentle. :)

Using SymPy 0.7.2 and IronPython 2.7.4.

import sympy

from sympy import *

# calculate arc length

x = symbol('x')

d = diff(2 * pow(x, 2), x)

print d

length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))

print length

This outputs '4*x' as expected then 'zip() argument after * must be a sequence, not dictionary-itemiterator'.

I believe the integration is solvable to 75.173 [1], so I assume I have an error in my Python and/or SymPy syntax. Can anyone please give me some pointers? Thanks!

[1] http://www.integral-calculator.com/#expr=sqrt%281%2B%284x%5E2%29%29&ubound=10&lbound=5

[Matthew Rocklin]

Symbol should be upper case.  Other than that everything is fine.  You also might want to update your sympy version at some point

In [1]: from sympy import *

In [2]: x = Symbol('x')

In [3]: d = diff(2 * pow(x, 2), x)

In [4]: d

Out[4]: 4*x

In [5]: length = integrate(sqrt(1 + pow(d, 2)), (x, 5, 10))

In [6]: length

Out[6]: -5*sqrt(401)/2 - asinh(20)/8 + asinh(40)/8 + 5*sqrt(1601)

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/dfee71bf-d071-44a8-8772-f8d8f75ae855%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Rocklin]

Also, feel free to use x**2 rather than pow(x, 2) .  Your integrand here is not the same as what you put in to the integral calculator.

[Matthew Rocklin]

Also, any feedback from using SymPy with IronPython?  We don't get a lot of feedback from that community, your thoughts/concerns here would be appreciated.

[Groover]

Symbol/symbol was a typo - I didn't copy and paste from my python editor.

I tried x**2 and I still received the same error.

I've updated to SymPy 0.7.3 and I still get the error.

If I try to use SymPy 0.7.4, 0.7.4.1, 0.7.5 or the git master then I get the following:

>>>import sympy

unicode_escape_decode() takes no arguments

Thanks, Andy

[Groover]

I thought that x**y and the built-in pow(x, y) were the same? Can you please clarify for me how my python integrand is different, as I am a bit unsure. Thanks.

Andy

[Matthew Rocklin]

They are the same.  I was just suggesting x**y over pow(x, y).  Mostly because that's my aesthetic preference.  Feel free to ignore.

By googling unicode_escape_decode() takes no arguments I run into a stackoverflow question that references using Python from F# so I'm going to guess that this is more of an IronPython than a SymPy problem.

My guess is that your other issue boils down to this as well.  It looks like IronPython doesn't naturally expand iterators (it mentions dictionary-itemgetter) when used with the * operator. 

Question to the community, should we endeavor to support IronPython in the same way that we support CPython 2, 3, and PyPy?  

Question to Andy, do you have a sense of how big the IronPython community that might use SymPy is?  This is probably important information to answer the previous question.

Regarding your integrand.  d is 4x.  In the SymPy code you square this giving 16x^2 within the integrand.  In the link you posted you're only squaring x, not 4x, and so you get 4*x^2.

-Matt

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/7cc62e0c-898f-40aa-982b-97231b9f5140%40googlegroups.com.

[Groover]

Thanks for explaining the integrand mistake. It is correct in the SymPy code and incorrect in the calculator.

I guess I am stuck between a rock and a hard place. The primary purpose of my (free) application is to interface with a CAD package. The 3rd party interface uses .NET, so I naturally choose C# and IronPython for the development. Now I would like to add more functionality to the python side and I thought that SymPy was a nice fit. But it seems I am not going to be able to get it working with IronPython.

From the other way around - developing a CAD interface library for Anaconda for example - also seems to be fraught with problems if the library uses .NET. There are vague mentions of python to .NET bridges but that doesn't seem a popular approach.

Sigh. :(

Andy

[Aaron Meurer]

I haven't heard much from people using IronPython. I had assumed that the project was somewhat dead.  I'd be happy to work around bugs. The biggest issue for us is testing it. You have to have Windows (I tried using Mono a while back, but I didn't have much luck). There is this open issue https://github.com/sympy/sympy/issues/3159.

Maybe there are other ways to either call Python from C# or call C# from Python. I've always thought that using a glue library was a better approach than trying to reimplement all of Python in .NET (or whatever language). You could probably make your own poor-man's glue by just calling some Python script in a subprocess.

Aaron Meurer

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/b337d123-9ec0-4772-bc2a-94f616b9de53%40googlegroups.com.

[Groover]

Latest stable release was seven months ago. Latest commit to github was two days ago.

Andy

[Matthew Rocklin]

One low tech way around this problem is for Andy to fix iron Python compatibility issues in sympy as he runs into them.  Presumably he has a suitable environment.

For example he could find where we call this zip and wrap the arguments in a list and submit that as a change to sympy.

Alternatively (and perhaps better in general) is to alert the apparently active IronPython group about these issues.

--

You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ad819f2d-758b-4fa9-940b-f3080718828a%40googlegroups.com.

[Groover]

I get where you are coming from.

I'm developing this free application in my limited spare time. Having SymPy support is a nice-to-have add-on, not core functionality (which is the CAD part). I'm not sure the zip call is the real problem - it would be much better to run the latest version of SymPy instead. But while 0.7.3 imports OK, 0.7.4 does not. So it seems to me that a change was made between those versions that stopped it working with IronPython, but debugging that is beyond my current time and capabilities.

Thanks, Andy

[Aaron Meurer]

Yes, you'd need to test against the git version if you intend to make any fixes.

Aaron Meurer

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/fe4c9ff9-bef1-4c9d-a7dd-61aafabe86fe%40googlegroups.com.

[Groover]

I now have sympy git-master working with IronPython 2.7.5b1 and this problem no longer occurs. I get the same result as Matthew.

[Ondřej Čertík]

On Wed, Apr 9, 2014 at 3:43 AM, Groover <aja...@gmail.com> wrote:
> I now have sympy git-master working with IronPython 2.7.5b1 and this problem
> no longer occurs. I get the same result as Matthew.

Nice!

Ondrej

[Matthew Rocklin]

Yeah, that's pretty fantastic.  I'm curious to know how much work was involved.  Is it possible to push your changes back to our codebase?  We'd be happy to enable this.

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To post to this group, send email to sy...@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CADDwiVBCckDrpjir%3DHMNr%2Boe9wd3MW%3DPqkLXL%3DVDx8G8VVo8Hg%40mail.gmail.com.

[Joachim Durchholz]

Am 10.04.2014 06:03, schrieb Matthew Rocklin:
> Yeah, that's pretty fantastic. I'm curious to know how much work was
> involved. Is it possible to push your changes back to our codebase? We'd
> be happy to enable this.

We'd need to run automated testing on Windows make it worth it;
otherwise, we're going to inadvertently add another IronPython problem
any day, which isn't going to make SymPy very useful.

Travis seems to be preparing for multiple OSes, newer entries in
https://github.com/travis-ci/travis-ci/issues/216 sound like it's Real
Soon Now(tm); it could till take a few months until it's really there
though.
The other approach would be Mono. Travis would like to support that as
well (see https://github.com/travis-ci/travis-ci/issues/649 ), but
that's been hitting roadblocks and seems to be inactive.

I'd be +1 on running tests on Windows and MacOS as soon as Travis
supports that.
It would triple the running time of tests, unfortunately. I'm not sure
how bad that really is. On the plus side, we could state better
guarantees for platforms.

For IronPython, I'm not -1 but I'd like to see some things verified.
I'm not sure how viable the project is actually. IronPython was created,
adopted by MS, then dropped again; any project will suffer from such a
history (it might actually have sorted out the fallout). Also, there
might be performance issues - IronPython is sometimes faster, sometimes
slower than CPython. OTOH I guess people will prefer a slow SymPy over
no SymPy so that's not a biggie (but we'll want to check the Travis
running times).

[Groover]

The fix is trivial.

Firstly there is an import bug in IronPython that I guess they are going to fix - I will double check.

The only other issue is the unicode_escape_decode not having parameters. This is something to do with the fact that IronPython is already fully unicode. So all that needs to happen is something like this in core/compatibility.py:

    def u(x):
        return codecs.unicode_escape_decode(x)[0]

becomes:

    def u(x):
        try:
            return codecs.unicode_escape_decode(x)[0]
          except:
              return x

Thanks, Andy

[Groover]

OK, it's confirmed, the only issue on the SymPy side is supporting unicode_escape_decode when it has no parameters.

Thanks, Andy

[Aaron Meurer]

When you say that it works, do you mean that you ran all the tests and they passed? 

import sympy

sympy.test()

Aaron Meurer

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/ebf20aa9-4e43-4cc6-8162-3a8451a503d8%40googlegroups.com.