November 2000 - GiNaC-devel

polynomial arithmetic over ginac
by Parisse Bernard 23 May '01

23 May '01

I have now a little bit improved the package of my polynomial and rational fractions utilities over GiNaC (0.6.4) It provides now gcd normalization, factor (square-free and rational roots), partfrac & integrate (assuming factor works on the denominator), for example: integrate '1/(x^4-1)^5' returns -1155/8192*log(1+x)-1155/4096*atan(x)+1155/8192*log(-1+x)+1/2048*(-893*x-1375*x^9+1755*x^5+385*x^13)*(-1+x^4)^(-4) # Time for (integrate)0.04 You can retrieve and test it at ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz Bye, Bernard Parisse

4 9

sqrfree
by Parisse Bernard 11 Mar '01

11 Mar '01

Hi, Doing some tests with square-free factorization, I believe I have found a bug. Let e by (x+y)^2*(x-y) expanded and call sqrfree(e,x). You do not get the original expression, it remains expanded. If y is replaced by 1 it seems it works. Bernard

3 3

Re: Autoconf
by Richard B. Kreckel 17 Nov '00

17 Nov '00

Hi Bernard, I just put this on the devel-list, maybe Christian or Alex have comments on the topic (or someone else): >>>>> On Fri, 27 Oct 2000, Parisse Bernard wrote: >>>>>[ ...talking about converting the expairseq-representation of add and mul >>>>>to a sparse tensor representation by pulling out all of the numbers... ] >>>>> I don't think there are efficiency problems there, maybe we loose a >>>>> small constant factor but that's not where time is critical. >>>>> What do you think of the idea of adding member functions to provide >>>>> read-only access to .rest and .coeff? That would keep my code more >>>>> readable and keep member protection. >>>>> >>>> On Fri, 27 Oct 2000, Richard Kreckel wrote: >>>> Grudgingly so. We might wish to change the internal representation of add >>>> and mul, although this doesn't seem very likely at the moment. The .op() >>>> access method is the preferred one. I think that it can be done more >>>> elegantly than what I did (and also more correctly). >>>> >>> On Sat, 28 Oct 2000, Parisse Bernard wrote: >>> I'm afraid that using e.g. >>> is_exactly_of_type(obj.op(obj.nops()),numeric) >>> instead of obj.overall_coeff would be as well broken if you change the >>> internal representation of add. >>> I don't think that internal representation can be fully hidden >>> when converting representations to another one. That's not a big >>> issue as long as you keep all the dependant code well isolated >>> and documented. And I believe that the most important thing for the >>> future is code maintenance ease where readability is a key feature. >>> >> On Sat, 28 Oct 2000, Richard Kreckel wrote: >> Not really. We want to have it this way: The last one (obj.nops()-1 that >> is) is *supposed* to be the numeric overall coefficient, if it is >> different from the default coefficient, 0 for add, 1 for mul. It is just >> as in Maple, but we don't have a head part, so the counting is different. >> But the last one returned is always the numeric part. That's a kind of >> contract and we are in some other pieces of code really relying on it. I >> guess I should add checking this in the exam part... >> > On Sun, 29 Oct 2000, Parisse Bernard wrote: > OK, but I'm not a Maple expert. In fact, I want to use C++ because > there are some aspects of CAS langages that I do not like at all (and > of course I don't want to use proprietary software anymore) like > those you mention in your article (e.g. using list of lists to represent > complex data structures). > As I said before I find more natural to learn the internal structure > of symbolic objects than to learn conventions that are not intrinsic. > At first, it seems a better idea to have such sort of conventions and > allow internal representation changes, but I don't believe you can > keep this working. Algorithms, at least if you need efficient ones > (and that's always the case for CAS algorithms), depends too much of > the data structure. I've read in Stroustrup's book a lot of > recommendations about good programming that have always exceptions when > you deal with maths. This would still leave us with the question how to access expairseq::seq.coeff and expairseq::overall_coeff from outside. Is the foo.op(foo.nops()-1) approach something one should live with or should we accept that others expect the representation as it is and add inspector methods? I would really appreciate some input on this. [ ...talking about the merits of add and mul's representation... ] > I did not know about such a representation before reading GiNaC doc > and source. I have experience with the HP calculator system that > represent symbolic objects as programs to be evaluated using a > stack (for exemple '1+x' as SYMBOL 1 identifier_X + ;). > This kind of representation is fairly easy to evaluate but more > difficult to split into subtrees because embedded algebraics were not > allowed. And it does accept the + as a binary operator only. Which > makes rather difficult to code some operations, like a+d+b+c -> a+b+c+d. > Moreover there are a lot of operations allowed inside symbolics: /, INV, > SQRT, SQ, ... so that early simplifications like 1/INV(x) -> x are > much harder to code than using your representation. > Hence I adopted your representation because it solves some of these > issues. I don't think you will find the need to change internal > representation of these fundemental objects. > The main problem I see currently is that you can not bind objects > to a symbol (I would like to do that and I would like to be able > to make assumptions on symbols as well). And I have to get a better > understanding of your coding of operations like SIN, ... > There is another problem I see with using CLN to compute e.g. > transcendental functions if special values are found, e.g. ATAN(1), > because symbolic values belong to GiNaC, not to CLN (or maybe I've > missed something). Ah, yes. We cannot really do much here. Automatically, all that is allowed is a simple evaluation if one thinks the resulting expression is "simpler". (In the case of atan(1) not doing so is clearly a bug and I'll fix it right now.) Following common jargon (eg R.J. Fateman in his article "Symbolic Mathematics System Evaluators" in Michael Westers "CAS - A practical guide") we can call this process of what is done automatically the "evaluator". We thought a useful convention is that automatically only fast transformations are done: on container-objects consisting of n things, this includes everything that goes like n*log(n) in complexity. Of course CLN does not have such a thing like Pi/4 because Pi doesn't fit into one of the algebraic domains there. So GiNaC simply tries to trap those arguments and give you a closed result in terms of well-known constants, including non-nested surds. Regards -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

4 4