Dear All, Coming back to our previous discussion (with a long history) on the power law (e^x)^a=e^(x*a). I am attaching a patch which does not break the automatic simplification exp(x)/exp(x)=1. I am also continuing to think on a generic tool to implement various transformation rules. Current "self"-isolation regime may provide a space for its implementation. 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/ Jupyter: https://github.com/vvkisil/MoebInv-notebooks
On Tue, 15 Oct 2019 14:18:03 +0100, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:
VVK> Dear Richard,
On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" VVK> <kreckel@in.terlu.de> said: RK> Well, after celebrating this patch, we should discuss it RK> breaking check/exam_paranoia.cpp:217.
RK> That particular check has nothing to do with the exp() function, RK> so we could re-write it in terms of Li2() or some other function RK> and be done with it. RK> But François Maltey objected about exp(x)/exp(x) not eval'ing to RK> 1 any more: RK> https://www.ginac.de/pipermail/ginac-devel/2009-October/001680.html RK> And, somehow, that should be addressed, I guess. VVK> It seems that both mentioned issues are connected. I am VVK> attaching a revised patch which applies the law of exponents, VVK> but keeps exp(x)^(-1) as exp(x)^(-1). With this patch VVK> check/exam_paranoia.cpp (as well as all other checks) went well VVK> (at least on my computer.) RK> I propose writing generic functions outside the automatic eval RK> system along these lines RK> https://www.ginac.de/FAQ.html#treetraverse searching for common RK> arguments of exp() which may be combined. Would you like to RK> venture? VVK> I will keep thinking on implementation of the rule e^t * e^s VVK> = e^(t+s). At the moment, I am in a favour to make it a part VVK> of a more general mechanism which will allow a user to apply VVK> some specific transformations for particular functions on VVK> demand (beyond wildcard substitutions). So it will not be done VVK> with the automatic evaluation and will not slow down the VVK> traditional performance. May be it is worth to add some more VVK> properties like add_func(), mul_func(), ncmul_func() to VVK> complement the existing power_func()... VVK> Best wishes, Vladimir -- Vladimir V. Kisil VVK> http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius VVK> Transformations http://goo.gl/EaG2Vu Software: Geometry of VVK> cycles http://moebinv.sourceforge.net/ Jupyter (Colab): VVK> https://github.com/vvkisil/MoebInv-notebooks Jupyter VVK> (CodeOcean): https://codeocean.com/capsule/7952650/tree VVK> _______________________________________________ GiNaC-devel VVK> mailing list GiNaC-devel@ginac.de VVK> https://www.cebix.net/mailman/listinfo/ginac-devel