From Bernard.Parisse at ujf-grenoble.fr Thu Oct 19 11:00:35 2000 From: Bernard.Parisse at ujf-grenoble.fr (Parisse Bernard) Date: Thu, 19 Oct 2000 11:00:35 +0200 Subject: strange behavior of ex constructor from string Message-ID: <39EEB833.6A720683@fourier.ujf-grenoble.fr> I'm currently testing the latest version of the Z-factorization code and found some weierd results that I believe show there is a bug in the ex constructor from a string. You can reproduce this bug the following way: compile the latest ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz (make install then make factor) Try ./factor zimmer7 answer is 0 Looking in my code, it seems that the call args.push_back(ex(string(ss2),lst(sym))); line 480 of polygauss.cc pushes a 0 instead of the correct expression (i.e. what's in the zimmer7 file) (you can check this by putting a breakpoint in factor.cc, l.27, p it->dbgprint() prints 0) The same call works when applied to zimmer1, zimmer2, zimmer3. Any ideas? Bye, Bernard From cbauer at student.physik.uni-mainz.de Tue Oct 24 16:44:08 2000 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Tue, 24 Oct 2000 16:44:08 +0200 Subject: strange behavior of ex constructor from string In-Reply-To: <39EEB833.6A720683@fourier.ujf-grenoble.fr>; from Bernard.Parisse@ujf-grenoble.fr on Thu, Oct 19, 2000 at 11:00:35AM +0200 References: <39EEB833.6A720683@fourier.ujf-grenoble.fr> Message-ID: <20001024164408.A10151@iphcip1.physik.uni-mainz.de> Hi! On Thu, Oct 19, 2000 at 11:00:35AM +0200, Parisse Bernard wrote: > Looking in my code, it seems that the call > args.push_back(ex(string(ss2),lst(sym))); > line 480 of polygauss.cc > pushes a 0 instead of the correct expression (i.e. what's in the zimmer7 > file) That's probably because the zimmer7 file is syntactically incorrect, containing terms like 20734047820658568988275936059402711947017728*^286 and 604703470567171052x^32 Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From Bernard.Parisse at ujf-grenoble.fr Tue Oct 24 17:08:09 2000 From: Bernard.Parisse at ujf-grenoble.fr (Bernard Parisse) Date: Tue, 24 Oct 2000 17:08:09 +0200 (MET DST) Subject: strange behavior of ex constructor from string In-Reply-To: <20001024164408.A10151@iphcip1.physik.uni-mainz.de> from Christian Bauer at "Oct 24, 2000 04:44:08 pm" Message-ID: <200010241508.RAA12327@mozart.ujf-grenoble.fr> > > That's probably because the zimmer7 file is syntactically incorrect, > containing terms like > > 20734047820658568988275936059402711947017728*^286 > > and > > 604703470567171052x^32 Sorry! I didn't check for a correct syntax since every time I had something incorrect, I got Abort. I will look more carefully in the futur... Thank you very much! Bernard From cbauer at student.physik.uni-mainz.de Tue Oct 24 17:16:55 2000 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Tue, 24 Oct 2000 17:16:55 +0200 Subject: strange behavior of ex constructor from string In-Reply-To: <200010241508.RAA12327@mozart.ujf-grenoble.fr>; from Bernard.Parisse@ujf-grenoble.fr on Tue, Oct 24, 2000 at 05:08:09PM +0200 References: <20001024164408.A10151@iphcip1.physik.uni-mainz.de> <200010241508.RAA12327@mozart.ujf-grenoble.fr> Message-ID: <20001024171655.A11787@iphcip1.physik.uni-mainz.de> Hi! On Tue, Oct 24, 2000 at 05:08:09PM +0200, Bernard Parisse wrote: > I didn't check for a correct syntax since every time I had something > incorrect, I got Abort. The input parser throws an exception when it encounters a syntax error. Printing that exception might give a clue on what's wrong (OK, not in this case because the expression is very long and all it says is 'parse error at ^'). Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From kreckel at thep.physik.uni-mainz.de Sun Oct 29 15:13:53 2000 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Sun, 29 Oct 2000 15:13:53 +0100 (CET) Subject: Autoconf In-Reply-To: <39FC2307.92F918BB@fourier.ujf-grenoble.fr> Message-ID: <Pine.LNX.3.96.1001029140302.193A-100000@higgs.physik.uni-mainz.de> 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 at Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>