On Mon, 11 Apr 2016 22:03:23 +0200, "Richard B. Kreckel" <kreckel@in.terlu.de> said: RK> Yes, for the reason quoted above I think this should be a RK> separate function.
RK> Considering that there is a public constructor with a paramset RK> as argument, we can as well provide a const accessor member RK> function to parameter_set and that's it. (True also, however, RK> that said constructor could be protected.) RK> Or maybe some completely different interface? What about this RK> one: // how many times this function is derived with respect to RK> parameter number param unsigned derived(unsigned param) const; I did not get the last reason. If GiNaC would provide a user with the full paramset, then (s)he will have a freedom to do anything with it. However, if GiNaC will pre-filter it out for one user's demand, then another user may not be able to (easily) get what (s)he want... -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/