I have some doubts about that claim. But I guess this is not really the issue you want to discuss. :-)
Yeah, it wouldn't lead anywhere. :)
If you could suppress your revulsion of the Maple language, then I could send you information about a package I wrote a few years ago called TensorLite. I used it to do symbolic manipulation of tensors in Maple V release 5 for calculations similar to that which you describe. If you have Maple, you should be able to read this: http://synthesis.anikast.ca/maple/mathematics/tensor5c.mws If you have any interest, just let me know. With a little effort I could probably remember what I was doing at that time...
It's nice. I tried that on maple 9.5 and after a while it says: Execution stopped: Stack limit reached. Worksheet lost contact with kernel. You should save this worksheet and restart Maple. Well, this is exactly a reason, why I find Maple completely unusable... But anyway, I'll try to learn from your sheet in order to implement it nicely in SymPy. Thanks.
Yes, isn't that the way things go in computer algebra - everyone seems to write their own? :-( That's a pity. If what you really want to do is physics, then it's a trap that many people have fallen into. It took me a long time to get over that stage.
Well, it depends. You cannot stay at that, you need to get some real results, otherwise it's of course nonsense to create anything from scratch. But SymPy, besides fun (which is very important) also allows me to play with the differential geometry already. And I like it. I like to play with ideas, so I think it was not a lost time.
Actually I looked at SumPy a while back on Google Code. I think its pretty cool. Do you know anything about Sage? Sage is another
Sure. I corresponded with Bobby Moretti quite a lot about the symbolic manipulation, because he is writting something almost identical to SymPy in SAGE right now, but currently SymPy is much more mature than his code.
computer algebra system that is written in Python, but they incorporate a lot of other open source math software packages such as Maxima, Gap, gmp, mpfr, etc. to do things not implemented in native Python. Perhaps they would be interested in SymPy for it's symbolic capabilities.
They are. I guess we'll wait until the summer is over, as I expect some really good students to take part in. As we have on our webpage: To sum it up: It would be nice to have an opensource alternative to Maple/Mathematica, that is reasonably fast (maybe written in C++), could be easily extended with your own ideas, would be callable from python and could be used in real world problems (as Maple/Mathematica can). SAGE is also trying to achieve this goal, but from a different side - SymPy aims to be lightweight, whereas SAGE aims to glue together every useful open source mathematics software package and provide a transparent interface to all of them.
You will also need: section 1.13 Differential Equations (introduction) and section 8.10 Solution of Differential Equations Using these two parts of Axiom in principle it should not be too difficult to do the calculations you want to do.
Thanks. I'll look at that. What surprises me, that there are not already some examples of such usage of Axiom, as I think those are things that everybody wants to play with at the beginning.
But I do hope that it will be possible to build new systems based on past experience and previous investments rather than repeating past mistakes and re-inventing the wheel.
What I can say from my own experience - the time I spent implementing some particular algorithms (limits, series expansion, gcd or square free decomposition of polynomials) was completely negligible compared to time spent inventing and designing the interface. I took GiNaC as a starting point, but I improved things that I didn't like on it (removed unnecessary classes etc). From Axiom I can just learn how to do some particular symbolic algorithm, but as I said - this is not a problem, as what SymPy does so far is very trivial from the mathematical point of view. What is not trivial is how to actually represent everything, and that is an area, where noone actually knows how to do it. So even if the only contribution of SymPy is that we actually showed that the CAS can be done this way, it will be good. I learned however how not to do things - I am in no way trying to reinvent some new (better) language, even if that language was actually better than Python. Actually, all the languages turned out to be worse (Maple/Mathematica/Maxima). Maybe Aldor will turn out to be better, but currently, from the technical point of view it isn't (many bugs, almost nonexistent user base, not opensource, etc.). Your argument is, that it is not important the language is not widespread, but rather that it is the best option for a CAS. But then you are immediately creating an obstacle for newcomers. It has it's advantages, I understand that, but it also has a lot of disadvantages. SymPy is going to be a library in a standard widespread language. We chose Python. So I think we are not reinventing a wheel. We are just trying to bring the CAS to masses, if I can use this expression. :) Ondrej _______________________________________________ Axiom-mail mailing list Axiom-mail@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-mail
