Dear Vladimir, On 04/12/2016 11:10 AM, Vladimir V. Kisil wrote:
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...
Hmm, I don't feel fully comfortable with the abstraction in fderivative where the derivative structure is represented as a multiset<unsigned>. But you're probably right that, given the way this class is written, it is probably best to provide the full paramset. Patch suggestion attached. Will commit soon if no objection is raised. All my best, -richard. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>