Hi Maurizio, I cced sage devel too.
On Mon, Mar 30, 2009 at 10:59 PM, Maurizio <maurizio.gran...@gmail.com> wrote: > > Hello, > > On 31 Mar, 01:39, Ondrej Certik <ond...@certik.cz> wrote: >> On Mon, Mar 30, 2009 at 4:14 PM, Maurizio <maurizio.gran...@gmail.com> wrote: >> >> > I know some of you guys are related to SAGE development. >> >> > I think it was polite behavior to forward this post I made in SAGE >> > group to your list as well. >> >> > Thank you very much for the great work! >> >> Thanks for forwarding it. I read the Sage list, but I missed this post. :) >> >> It's probably more Sage related --- with SymPy, we really want all the >> features that you mentioned, but we want it in a way that is easily >> extensible and hackable. Otherwise you can just use what is in maxima >> for example. >> > > what do you mean with this? I would really like to understand the > differences underlying the current SAGE's symbolic approach with > respect to yours. I think that for the moment I will stick with SymPy, The main stress in Sage, as I understand it, is speed (and robustness), e.g. the only reason for changing from Maxima is that it is slow, otherwise it would be fine. While in sympy it is really important for me to be able to hack on the code and fix it. So I want it in python/cython. The pynac based symbolics are pretty good though --- it builds quickly and one can call any python classes from within C++. This is something I was not aware of couple years ago, e.g. when I tried to wrap ginac, I used swig, and that's not the way. so pynac is fast and robust (ginac is pretty well tested after so many years). However, if i wanted to do something more advanced, be it integration, or limits, I would be stuck again with ginac, as it can't do it. I looked at the series expansion and I would have to fix it (improve it) a lot to be able to handle limits. So imho what is the most usable from ginac is the bare symbolics, e.g. expanding stuff like (x+y)**1000, (it can contain sin(x) etc) and imho this is what will be used in Sage (at least I understood it that way half a year ago), everything else will be done in Python/Cython (Burcin, William, please correct me, if I am wrong). So I think both approaches are doable (e.g. be it pynac, or speeding up sympy using cython etc), it only depends how many people will get excited about it and work really hard to make it happen. > it being the only package with a reasonable support to transforms and > staff like that. The problem with Maxima is that, apart for not having > found any function related to this (maybe it's there in maxima/share, > but I don't know whether it's well tested), I found rather complicated > to interact with maxima from SAGE, when issues are not plain simple > and straightforward (even "Assume()" is not always easy to use from > SAGE, imho). Do you have suggestions? I think so too it is too complicated if one wants to extend it. That's why sage will switch to pynac soon. > >> In my experience, for the more complicated integrals like for fourier >> transforms etc, it really helps if one has a good assumptions system >> working. In fact, it's a must, so we are working on as much as we can. >> >> Ondrej > > Which is the difficulty level for this staff? I don't know how SymPy > is currently developed, but what is the roadmap for this staff? I am Our roadmap is here: http://wiki.sympy.org/wiki/Plan_for_SymPy_1.0 > wondering if implementing a Fourier transform in Symbolics is just > writing down the well known formula and hope for the integrating > engine to perform the best :) Yes, the integration engine needs to be able to do the integrals, that's it. But in my experience you always want to tweak it a bit, fix it so that it does the job for the physical problem that you want to solve. So if you have Maurizio some ideas how to make the Sage community and SymPy community work more together, I am interested. I know that William wrote pynac with the idea so that we can rebase sympy on top of that, if it proves really superior to anything else. For that we need to refactor our assumptions system first, which we are working on. Ideally it could work on top of any core (e.g. sympycore as well), that'd be really awesome. Ondrej --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
