> VOTE: > [ ] Yes, include Pynac in Sage > [ ] No, do not (please explain) > [ ] Hmm, I have questions (please ask).
I don't know if my vote counts, but I am of course +1. Thanks for pioneering the use of Python in C projects, I hope people will now try much more to reuse C/C++ code. > (e) how does this relate to sympy? > (I dont' know. > Sympy does several things Ginac doesn't, such as symbolic > integration and > sophisticated limits. I would like to find a way to somehow > reuse that code directly, > especially since sympy is in sage already, and is already often better > than using Sage's current maxima + pexpect symbolic manipulation. > On the other hand, Burcin is I think driven mostly by his Ph.D. thesis > research, and has told me he will only write GPL'd code, which means > it can't go into Sympy.) I think porting the limits is quite easy, but unfortunately ginac series expansion is not sophisticated enough for more complicated limits (at least last time I tried, it was I think 2 years ago), so you will have to port the sympy's series expansion as well, or improve ginac series expansion. As to integration, that will be I think a little more difficult to port, but definitely doable as well. As to GPL vs BSD, I am sad that some people will not contribute to a BSD project and some other people will not use a GPL project. But my intuition says that the license is not the main reason. If sympy was as fast as ginac (as I hope it will be in not so distant future), I am sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that if the license was the only reason, I am willing to consider switching to GPL (i.e. try to persuade all 44+ contributors), if that would mean more people would be developing sympy. Currently it seems to be the opposite, i.e. when we switched from GPL to BSD, people and developers seemed to like it, but I may well be mistaken. But as I said, I think the main problem of sympy is not the license, but speed. I myself like the way sympy is designed, e.g. pure python + now we are working on the Cython core (+possibly pynac if it's a better alternative, even though some sympy developers seems to prefer pure Cython solution if we can made it as fast as pynac), because that allows to use sympy easily in the google app engine, hopefully soon in pypy and jython, and also as a compiled library when we get the core in with exactly the same interface, i.e., whenever there is python, it should work on it. On the other hand, if you are willing to release and maintain pynac outside sage, so that it's easy to use and basically implement or port all sympy to it, I'll be more than happy that someone else will do my job and I can move to do some more advanced things. I really don't want to have two codebases for the same thing. 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 -~----------~----~----~----~------~----~------~--~---
