On Mon, Aug 25, 2008 at 2:42 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote: > >> 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.
Your vote counts. > 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. Or hopefully find a way to just directly use sympy's series expansion code? Could you give an example to illustrate where you maybe found shortcomings in Ginac's series code? It's pretty straightforward code for the most part, and I don't know how it could go wrong. > As to integration, that will be I think a little more difficult to > port, but definitely doable as well. By "port" I will take it to mean "improve sympy so it can manipulate Pynac symbolic expressions in addition to its own". I.e., it's basically a "duck typing" thing, where as long as Pynac exports the right interface, sympy should be able to work with it. > 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. The GPL/BSD split in the mathematical Python community is unfortunate and a is very real problem. At scipy'08 it was the source of tension for some people... > 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), Why not both? Having the option of multiple pluggable cores is probably the best way to do a good job designing the right interface for the core. The only option for sympy is both or "no pynac", since pynac is GPL'd (as was decided by the Ginac developers long ago). So I can imagine some sympy users using pynac as the core because it is maybe better for large problems, and other users using csympycore or something, because it is BSD licensed. Yet others would use the purepython core for portability (e.g., me on my cell phone ;-) ). > 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. I definitely want to have a version of pynac outside sage. But keep in mind again that pynac is GPL'd, and given your mission statement for sympy, I think it is not an option for you to depend only on something GPL'd as the only option. As I see it, an important part of the sympy mission is to be the CAS for the "we will only use BSD'd code" side of the Python math software world, which is a very substantial important and well funded group of people. William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
