Which reminds me, do you find ginac quite difficult to extend? I find the whole ginac unnecessary complex: for example declaring new symbolic functions requires using 2 macros, adding new classes is even more complicated. Then there are several types of functions "pow" (for example), one for ex, another for numeric and another for general typemaps T1 and T2. then there are both methods of classes and standalone functions, which do the same thing. there are several almost the same constructors for most of the classes. There is the "ex" class - it seem to me it's not needed at all. In the source, it's written, its for counting references and acts like a proxy. But imho it's just making everything complicated. I am just curious, if there is some basis for those decisions, or if you just decided to do it that way. I understand that ginac just works and is doing the job (and my own code does nothing yet), so from this point of view my complains are irrelevant. But I think there were more people than me, who tried to extend ginac, and find it too much difficult, so they gave up. I like the idea of ginac and I think it would be even better to use python as the language for calling all the ginac commands (because python is exactly a language for CAS imho - the code looks much nicer and is much shorter than in C++). There is pyginac (with the problems I mentioned in my last email) and I wrote (together with Ola Skavhaug) swiginac. It's doing the job, but it's difficult to extend, as I have just said. (BTW, both pyginac and swiginac are unwrapping "ex"s, which really makes one ask the question of the necessity of ex.) Half a year ago I wrote some proof of concept of a CAS (computer algebra system) in python: http://ondrej.certik.cz/cas.php which shows, that it should be possible to rewrite ginac in much simpler way. The code is still a little bit messy, but it's really short taking into account what it can achieve already. The idea is to test everything in python first, and then maybe rewrite it to C++ for speed. The biggest lesson I learned is, that it is not that difficult to write new CAS. I wanted to write to this list later, when I have more functioning code, but because I don't have much time to continue on it, I decided to write now. Is anybody having similar experience or do you think it's not worthy to write another CAS from scratch? Of course I understand nobody has time for new venture and ginac works pretty well after all. My question is just if you think there is a room for such a thing. If not me, maybe somebody else would be encouraged to do it. I think there are people, who would implement for example the factorization (you can copy it from http://eigenmath.net/ for example) and other stuff like limits and integration, if the code weren't so complex (or am I wrong?). Ondrej P.S. I also wrote almost the same question to comp.lang.python, with no big response: http://groups.google.com/group/comp.lang.python/msg/8aa724d2642ec890?hl=en& On 7/20/06, Vladimir Kisil <kisilv@maths.leeds.ac.uk> wrote:
Ondrej Certik ondrej at certik.cz write on Thu Jul 20 00:13:29 CEST 2006
We also created swiginac (http://swiginac.berlios.de/), for those, who are interested in using ginac from python.
just my opinion: boost-python took ages to compile on my machine and the errors were completely unreadable. swig compiles much faster, and also it seems easier to learn. Do others have similar experience, or totally different?
I agree that both BoostPython and pyGiNaC have some issues and may be willing to make my library wrap in swiginac as well. However the swiginac is not supporting the new tinfo system and I cannot see right now how to patch it.
Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ _______________________________________________ GiNaC-list mailing list GiNaC-list@ginac.de https://www.cebix.net/mailman/listinfo/ginac-list