Dear All, I want to celebrate the 10th anniversary of this patch https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html by its re-submission. Since it was not objected since the original submission by anyone, it may be the time now to add this basic calculus-textbook rule to GiNaC. 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 (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): https://codeocean.com/capsule/7952650/tree
Dear Vladimir, On 10/14/19 4:57 PM, Vladimir V. Kisil wrote:
I want to celebrate the 10th anniversary of this patch
https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html
by its re-submission. Since it was not objected since the original submission by anyone, it may be the time now to add this basic calculus-textbook rule to GiNaC.
Well, after celebrating this patch, we should discuss it breaking check/exam_paranoia.cpp:217. That particular check has nothing to do with the exp() function, so we could re-write it in terms of Li2() or some other function and be done with it. But François Maltey objected about exp(x)/exp(x) not eval'ing to 1 any more: https://www.ginac.de/pipermail/ginac-devel/2009-October/001680.html And, somehow, that should be addressed, I guess. I propose writing generic functions outside the automatic eval system along these lines https://www.ginac.de/FAQ.html#treetraverse searching for common arguments of exp() which may be combined. Would you like to venture? -richy.
Dear Richard, Thanks for reminding me the exp(x)/exp(x) cancellation and other issues. I am going to look on all of this together, but it will take some time (hopefully not another 10 years). 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 (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): https://codeocean.com/capsule/7952650/tree
On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Dear Vladimir, On 10/14/19 4:57 PM, Vladimir V. Kisil wrote: >> I want to celebrate the 10th anniversary of this patch >> >> https://www.ginac.de/pipermail/ginac-devel/2009-October/001675.html >> >> by its re-submission. Since it was not objected since the >> original submission by anyone, it may be the time now to add this >> basic calculus-textbook rule to GiNaC. 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. I propose RK> writing generic functions outside the automatic eval system RK> along these lines https://www.ginac.de/FAQ.html#treetraverse RK> searching for common arguments of exp() which may be RK> combined. Would you like to venture? RK> -richy. _______________________________________________ RK> GiNaC-devel mailing list GiNaC-devel@ginac.de RK> https://www.cebix.net/mailman/listinfo/ginac-devel
Dear Richard,
On Tue, 15 Oct 2019 09:23:21 +0200, "Richard B. Kreckel" <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. It seems that both mentioned issues are connected. I am attaching a revised patch which applies the law of exponents, but keeps exp(x)^(-1) as exp(x)^(-1). With this patch check/exam_paranoia.cpp (as well as all other checks) went well (at least on my computer.) RK> I propose RK> writing generic functions outside the automatic eval system RK> along these lines https://www.ginac.de/FAQ.html#treetraverse RK> searching for common arguments of exp() which may be RK> combined. Would you like to venture? I will keep thinking on implementation of the rule e^t * e^s = e^(t+s). At the moment, I am in a favour to make it a part of a more general mechanism which will allow a user to apply some specific transformations for particular functions on demand (beyond wildcard substitutions). So it will not be done with the automatic evaluation and will not slow down the traditional performance. May be it is worth to add some more properties like add_func(), mul_func(), ncmul_func() to complement the existing power_func()... 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 (Colab): https://github.com/vvkisil/MoebInv-notebooks Jupyter (CodeOcean): https://codeocean.com/capsule/7952650/tree
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
Hi Vladimir! On 06.04.20 14:34, Vladimir V. Kisil wrote:
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.
Your new patch is much better since it doesn't break any existing test suite. Playing around with it, it still seems to raise some fundamental questions: What justifies treating exp(x)^a fundamentally different than any other (b^x)^a with a (positive) base b? With the patch, there seems to be this discrimination: exp(x)^5 is rewritten to exp(5*x) but (b^x)^5 is _not_ rewritten to b^(5*x). It's a nice pastime to fancy consequences of this. Let y=b^x, then normal((y^2-1)/(y+1)) returns b^x-1. But if y=exp(x), the patch prevents the normalization to exp(x)-1. Ugh. Or, consider this gedankenexperiment: If we didn't have exp(x) as a function but instead a symbol e, would it be justified to have special re-writing rules for (e^x)^a but not for (b^x)^a? I'm not sure... Best wishes, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
Dear Richard, Thank you for pointing out an issue with notmalisation of expressions. What about the attached _draft_ of the patch? It allows to reduce all suitable exponents with arguments different by a rational numeric factor to monomials of the same temporary variable. Thus it reduces (exp(2*x)-1)/(exp(x)-1) to exp(x)+1 as well as other more complicated cases like (exp(15*x)+exp(12*x)+2*exp(10*x)+2*exp(7*x))/(exp(5*x)+exp(2*x)) to exp(5*x)^2+2*exp(5*x) The patch modifies some signatures of functions, which however are not advertised as user interface. A footprint on the performance with expressions without exponents shall not be really noticeable. If the approach is suitable I can add a similar behaviour for powers, then the simplification (a^(2x)-1)/(a^x-1) to a^x+1 will work as well. Some tests shall be added for the final version of the patch. Once this will be working, shall we add the automatic simplification (a^b)^c=a^(b*c) for suitable cases as well? 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 Thu, 9 Apr 2020 01:51:09 +0200, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Hi Vladimir! RK> On 06.04.20 14:34, Vladimir V. Kisil wrote: >> 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. RK> Your new patch is much better since it doesn't break any RK> existing test suite. RK> Playing around with it, it still seems to raise some fundamental RK> questions: What justifies treating exp(x)^a fundamentally RK> different than any other (b^x)^a with a (positive) base b? With RK> the patch, there seems to be this discrimination: exp(x)^5 is RK> rewritten to exp(5*x) but (b^x)^5 is _not_ rewritten to b^(5*x). RK> It's a nice pastime to fancy consequences of this. Let y=b^x, RK> then normal((y^2-1)/(y+1)) returns b^x-1. But if y=exp(x), the RK> patch prevents the normalization to exp(x)-1. Ugh. RK> Or, consider this gedankenexperiment: If we didn't have exp(x) RK> as a function but instead a symbol e, would it be justified to RK> have special re-writing rules for (e^x)^a but not for (b^x)^a? RK> I'm not sure... RK> Best wishes, -richy. -- Richard B. Kreckel RK> <https://in.terlu.de/~kreckel/>
Dear All, Coming back to the previous discussion on exponent/power functions I am sending the collection of three patches. The first two are corrected/polished versions of two patches described in my previous email (see forwarded below). Briefly: 1. First patch adds the rule (e^a)^b = e^(ab) to automatic evaluation in safe cases. 2. Second improves normalisation method for exponents, it is able to reduce (exp(2*x)-1)/(exp(x)-1) to exp(x)+1. 3. Third patch add the similar functionality for powers, it is able to reduce (x-1)/(sqrt(x)-1) to sqrt(x)+1. Patches have check components which illustrate further examples of normalisation. 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 Fri, 10 Apr 2020 08:43:52 +0100, "Vladimir V. Kisil" <V.Kisil@leeds.ac.uk> said:
VVK> Dear Richard, VVK> Thank you for pointing out an issue with notmalisation VVK> of expressions. What about the attached _draft_ of the patch? VVK> It allows to reduce all suitable exponents with arguments VVK> different by a rational numeric factor to monomials of the same VVK> temporary variable. Thus it reduces VVK> (exp(2*x)-1)/(exp(x)-1) to exp(x)+1 VVK> as well as other more complicated cases like VVK> (exp(15*x)+exp(12*x)+2*exp(10*x)+2*exp(7*x))/(exp(5*x)+exp(2*x)) VVK> to exp(5*x)^2+2*exp(5*x) VVK> The patch modifies some signatures of functions, which VVK> however are not advertised as user interface. A footprint on VVK> the performance with expressions without exponents shall not be VVK> really noticeable. VVK> If the approach is suitable I can add a similar behaviour for VVK> powers, then the simplification VVK> (a^(2x)-1)/(a^x-1) to a^x+1 VVK> will work as well. VVK> Some tests shall be added for the final version of the patch. VVK> Once this will be working, shall we add the automatic VVK> simplification (a^b)^c=a^(b*c) for suitable cases as well? 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: VVK> https://github.com/vvkisil/MoebInv-notebooks
On Thu, 9 Apr 2020 01:51:09 +0200, "Richard B. Kreckel" VVK> <kreckel@in.terlu.de> said:
RK> Hi Vladimir! RK> On 06.04.20 14:34, Vladimir V. Kisil wrote: >>> 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. RK> Your new patch is much better since it doesn't break any RK> existing test suite. RK> Playing around with it, it still seems to raise some fundamental RK> questions: What justifies treating exp(x)^a fundamentally RK> different than any other (b^x)^a with a (positive) base b? With RK> the patch, there seems to be this discrimination: exp(x)^5 is RK> rewritten to exp(5*x) but (b^x)^5 is _not_ rewritten to b^(5*x). RK> It's a nice pastime to fancy consequences of this. Let y=b^x, RK> then normal((y^2-1)/(y+1)) returns b^x-1. But if y=exp(x), the RK> patch prevents the normalization to exp(x)-1. Ugh. RK> Or, consider this gedankenexperiment: If we didn't have exp(x) RK> as a function but instead a symbol e, would it be justified to RK> have special re-writing rules for (e^x)^a but not for (b^x)^a? RK> I'm not sure... RK> Best wishes, -richy. -- Richard B. Kreckel RK> <https://in.terlu.de/~kreckel/>
Dear Developers, I am resending actualised versions of my previous patches from https://www.ginac.de/pipermail/ginac-devel/2020-June/002460.html The first patch (the exponent power law) has added exam now. Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Maps https://doi.org/10.1142/p835 Soft: Geometry of cycles http://moebinv.sourceforge.net/ Jupyter notebooks: https://github.com/vvkisil/MoebInv-notebooks
On Thu, 4 Jun 2020 16:45:56 +0100, "Vladimir V. Kisil" <V.Kisil@leeds.ac.uk> said:
VVK> Dear All, VVK> Coming back to the previous discussion on exponent/power VVK> functions I am sending the collection of three patches. The VVK> first two are corrected/polished versions of two patches VVK> described in my previous email (see forwarded below). Briefly: VVK> 1. First patch adds the rule (e^a)^b = e^(ab) to automatic VVK> evaluation in safe cases. VVK> 2. Second improves normalisation method for exponents, it is VVK> able to reduce (exp(2*x)-1)/(exp(x)-1) to exp(x)+1. VVK> 3. Third patch add the similar functionality for powers, it VVK> is able to reduce (x-1)/(sqrt(x)-1) to sqrt(x)+1. VVK> Patches have check components which illustrate further VVK> examples of normalisation. VVK> Best wishes, Vladimir -- Vladimir V. Kisil
On Fri, 10 Apr 2020 08:43:52 +0100, "Vladimir V. Kisil" VVK> <V.Kisil@leeds.ac.uk> said:
VVK> Dear Richard, VVK> Thank you for pointing out an issue with notmalisation of VVK> expressions. What about the attached _draft_ of the patch? It VVK> allows to reduce all suitable exponents with arguments VVK> different by a rational numeric factor to monomials of the same VVK> temporary variable. Thus it reduces VVK> (exp(2*x)-1)/(exp(x)-1) to exp(x)+1 VVK> as well as other more complicated cases like VVK> (exp(15*x)+exp(12*x)+2*exp(10*x)+2*exp(7*x))/(exp(5*x)+exp(2*x)) VVK> to exp(5*x)^2+2*exp(5*x) VVK> The patch modifies some signatures of functions, which however VVK> are not advertised as user interface. A footprint on the VVK> performance with expressions without exponents shall not be VVK> really noticeable. VVK> If the approach is suitable I can add a similar behaviour for VVK> powers, then the simplification VVK> (a^(2x)-1)/(a^x-1) to a^x+1 VVK> will work as well. VVK> Some tests shall be added for the final version of the patch. VVK> Once this will be working, shall we add the automatic VVK> simplification (a^b)^c=a^(b*c) for suitable cases as well? VVK> Best wishes, Vladimir -- Vladimir V. Kisil
On Thu, 9 Apr 2020 01:51:09 +0200, "Richard B. Kreckel" VVK> <kreckel@in.terlu.de> said:
RK> Hi Vladimir! RK> On 06.04.20 14:34, Vladimir V. Kisil wrote: >>>> 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. RK> Your new patch is much better since it doesn't break any RK> existing test suite. RK> Playing around with it, it still seems to raise some fundamental RK> questions: What justifies treating exp(x)^a fundamentally RK> different than any other (b^x)^a with a (positive) base b? With RK> the patch, there seems to be this discrimination: exp(x)^5 is RK> rewritten to exp(5*x) but (b^x)^5 is _not_ rewritten to b^(5*x). RK> It's a nice pastime to fancy consequences of this. Let y=b^x, RK> then normal((y^2-1)/(y+1)) returns b^x-1. But if y=exp(x), the RK> patch prevents the normalization to exp(x)-1. Ugh. RK> Or, consider this gedankenexperiment: If we didn't have exp(x) RK> as a function but instead a symbol e, would it be justified to RK> have special re-writing rules for (e^x)^a but not for (b^x)^a? RK> I'm not sure... RK> Best wishes, -richy. -- Richard B. Kreckel RK> <https://in.terlu.de/~kreckel/>
participants (3)
-
Richard B. Kreckel
-
Vladimir V. Kisil
-
Vladimir V. Kisil