[GiNaC-list] Given a formal iterated derivative	(GiNaC::fderivative), what actually is it?
    Vladimir V. Kisil 
    kisilv at maths.leeds.ac.uk
       
    Thu Apr 14 12:28:19 CEST 2016
    
    
  
	Dear Richard,
	Partial derivatives are not very trivial mathematically either,
  probably their implementation in GiNaC reflects this. I think your
  patch provides a good rod, so any user can do his own fishing using it.
  Best wishes,
  Vladimir
-- 
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/
>>>>> On Thu, 14 Apr 2016 00:04:56 +0200, "Richard B. Kreckel" <kreckel at in.terlu.de> said:
    RK> 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...
    RK> Hmm, I don't feel fully comfortable with the abstraction in
    RK> fderivative where the derivative structure is represented as a
    RK> multiset<unsigned>.
    RK> But you're probably right that, given the way this class is
    RK> written, it is probably best to provide the full paramset. Patch
    RK> suggestion attached. Will commit soon if no objection is raised.
    RK> All my best, -richard.  -- Richard B. Kreckel
    RK> <http://in.terlu.de/~kreckel/>
    RK> _______________________________________________ GiNaC-list
    RK> mailing list GiNaC-list at ginac.de
    RK> https://www.cebix.net/mailman/listinfo/ginac-list
  
    
    
More information about the GiNaC-list
mailing list