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 <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>