From cbauer at student.physik.uni-mainz.de Thu Nov 2 16:30:15 2000 From: cbauer at student.physik.uni-mainz.de (Christian Bauer) Date: Thu, 2 Nov 2000 16:30:15 +0100 Subject: Autoconf In-Reply-To: ; from kreckel@zino.Physik.Uni-Mainz.DE on Sun, Oct 29, 2000 at 03:13:53PM +0100 References: <39FC2307.92F918BB@fourier.ujf-grenoble.fr> Message-ID: <20001102163015.H6288@iphcip1.physik.uni-mainz.de> Hi! On Sun, Oct 29, 2000 at 03:13:53PM +0100, Richard B. Kreckel wrote: > 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? IMHO, users of GiNaC should not reply on the internal representation of algebraic objects (even that op(nops()-1) thing is suspicious to me), because that representation has changed, and will change sometime in the future. Extensions to GiNaC in the form of new classes, however, may benefit from or even require access to the internal representation, in which case the C++ "friend" mechanism can be used. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ From parisse at mozart.ujf-grenoble.fr Thu Nov 2 18:06:41 2000 From: parisse at mozart.ujf-grenoble.fr (Parisse Bernard) Date: Thu, 02 Nov 2000 18:06:41 +0100 Subject: Autoconf References: <39FC2307.92F918BB@fourier.ujf-grenoble.fr> <20001102163015.H6288@iphcip1.physik.uni-mainz.de> Message-ID: <3A019F21.A5717EE8@fourier.ujf-grenoble.fr> > > IMHO, users of GiNaC should not reply on the internal representation of > algebraic objects (even that op(nops()-1) thing is suspicious to me), because > that representation has changed, and will change sometime in the future. > Extensions to GiNaC in the form of new classes, however, may benefit from > or even require access to the internal representation, in which case the > C++ "friend" mechanism can be used. The main problem is however that the friend declaration must be present in GiNaC source code not in the extension source code. Anyway, I don't see any difference in accessing internal representation via a friend class or via members as soon as it is documented that these members might change in the future. I don't like bureaucraty! From kreckel at thep.physik.uni-mainz.de Thu Nov 16 18:52:52 2000 From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel) Date: Thu, 16 Nov 2000 18:52:52 +0100 (CET) Subject: Autoconf In-Reply-To: <3A019F21.A5717EE8@fourier.ujf-grenoble.fr> Message-ID: Hi Bernard, Sorry it took me so long to answer this but the changes in CLN 1.1 kept me busy... On Thu, 2 Nov 2000, Parisse Bernard wrote: > > IMHO, users of GiNaC should not reply on the internal representation of > > algebraic objects (even that op(nops()-1) thing is suspicious to me), because > > that representation has changed, and will change sometime in the future. Okay, it has changed and it will change sometime in the future. But still, I would argue that op(nops()-1) thing is trivial to guarantee and should be guaranteed because it can be useful in times. > > Extensions to GiNaC in the form of new classes, however, may benefit from > > or even require access to the internal representation, in which case the > > C++ "friend" mechanism can be used. > > The main problem is however that the friend declaration must be > present in GiNaC source code not in the extension source code. > Anyway, I don't see any difference in accessing internal representation > via a friend class or via members as soon as it is documented that > these members might change in the future. I don't like bureaucraty! Sure. The other clean option would be that you provide us with a method sitting in expariseq, add and mul which maps the object to a data structure that you need and we'll simply put that into GiNaC. Maybe this is what should be done. Regards -richy. -- Richard Kreckel From Bernard.Parisse at ujf-grenoble.fr Fri Nov 17 09:55:51 2000 From: Bernard.Parisse at ujf-grenoble.fr (Bernard Parisse) Date: Fri, 17 Nov 2000 09:55:51 +0100 (MET) Subject: Autoconf In-Reply-To: from "Richard B. Kreckel" at "Nov 16, 2000 06:52:52 pm" Message-ID: <200011170855.JAA18361@mozart.ujf-grenoble.Fr> > > Sure. The other clean option would be that you provide us with a method > sitting in expariseq, add and mul which maps the object to a data > structure that you need and we'll simply put that into GiNaC. Maybe this > is what should be done. I'm not sure it is easy because we need to find an intermediate data representation. This could be an idea: provide the ex class with a splitting function oper split(const ex & e, vector & v) that splits e in its arguments and the operator you must apply to get e from the argument list. oper would be a class like: struct oper { ex (* op) (const vector & arg); oper(const ex (* myop) (const vector & )) : op(myop) {} ex operator () (const vector & arg) const; }; ex oper::operator () (const vector & arg) const{ return op(arg); } Then we would define the usual operators, e.g. for + const ex __plus(const vector & args){ vector::const_iterator it=args.begin(), itend=args.end(); ex sum; for (;it!=itend;++it) sum += (*it); return sum; } oper _plus(__plus); An example of usage of split, testing that the operator is + ... ex e; vector v; oper o=split(e,v); if (o.op==__plus){ // or if (o==_plus), provided == is defined ... Any suggestions? Regards, Bernard