Hi, Alexei Sheplyakov schrieb:
Also I'd like to implement more efficient representation of polynomails and rational functions.
please go ahead if you have a good idea! I couldn't come up with one, yet, because one usually ends up duplicating a lot of complicated code.
At the moment the copyright/GPL headings are missing.
Do we really have to put legalistic boilerplate into *every* file?
Don't know. Ask the lawyers. Maybe a short reference to some text file containing the licences etc. could do the trick.
You are using the hpp extension now for some header files. Why?
AFAIK this is the standard naming convention for C++ headers.
It is not the standard naming convention for GiNaC. It is just creating a mess.
And why are there files with a tcc extension?
These files contain 'simple' functions implemented as templates. Whenever I need some particular function I #include corresponding tcc file. 'tcc' suffix prevents automake from compiling those files on their own.
So, it is like a header?!?
Also factor.cpp is quite far from being optimal. In particular, univariate polynomials and operations on them are implemented in very inefficient way.
I know, thanks, see the email exchange with Richy. UniPoly is going to be removed and be replaced by cln stuff. Again, UniPoly is there because I didn't understand the necessary algorithms and their demands when I started to program the code. I wanted to be flexible, not efficient. Something like umodpoly will do the job. That was the reason why I asked about the future plans of the gcd code because I would then directly use umodpoly and would have to add the addional functionality I need into upoly.cpp. But if this code is still going to change heavily, then I will wait and make a copy-implementation in factor.cpp for the time being. I usually have only a few hours per week to work on factor.cpp so the progress will be as slow as it was in the past and I can wait for the polynomial/* code to mature. Regards, Jens