[GiNaC-list] Given a formal iterated derivative (GiNaC::fderivative), what actually is it?

Richard B. Kreckel kreckel at in.terlu.de
Thu Apr 14 00:04:56 CEST 2016


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 at 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/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fderivative.patch
Type: text/x-diff
Size: 1368 bytes
Desc: not available
URL: <http://www.cebix.net/pipermail/ginac-list/attachments/20160414/4d938646/attachment.bin>


More information about the GiNaC-list mailing list