[GiNaC-list] Python wrapper for a GiNaC derived library

[Ondrej Certik]

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 at 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 at maths.leeds.ac.uk
> --                      www: http://maths.leeds.ac.uk/~kisilv/
> _______________________________________________
> GiNaC-list mailing list
> GiNaC-list at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-list
>