Collect() with a list of variables doesn't work in ginsh
Hi, all. In section 5.7.2 of the docs (Expanding and collecting) there is this example of ginsh usage: > a=expand((sin(x)+sin(y))*(1+p+q)*(1+d)); > collect(a,{p,q}); The docs say I should get this: d*sin(x)+(d*sin(x)+sin(y)+d*sin(y)+sin(x))*p ... but actually: cannot modify multiply referenced object This is with GiNaC V1.7.6, V1.7.8, and the latest commit of V1.8.0. How do I make this work?
On Wed, 17 Mar 2021 14:57:57 +0100, Vitaly Magerya <vmagerya@gmail.com> said:
VM> Hi, all. In section 5.7.2 of the docs (Expanding and collecting) VM> there is this example of ginsh usage: >> a=expand((sin(x)+sin(y))*(1+p+q)*(1+d)); collect(a,{p,q}); VM> The docs say I should get this: VM> d*sin(x)+(d*sin(x)+sin(y)+d*sin(y)+sin(x))*p VM> ... but actually: VM> cannot modify multiply referenced object VM> This is with GiNaC V1.7.6, V1.7.8, and the latest commit of VM> V1.8.0. VM> How do I make this work? Running the code from cginac import * x=realsymbol("x") y=realsymbol("y") p=realsymbol("p") q=realsymbol("q") d=realsymbol("d") a=expand((sin(x)+sin(y))*(1+p+q)*(1+d)) print(a.collect([p,q])) with in PyGiNaC [1] with GiNaC 1.8.0 produces: sin(x)+d*sin(x)+q*(sin(x)+d*sin(x)+sin(y)+d*sin(y))+sin(y)+p*(sin(x)+d*sin(x)+sin(y)+d*sin(y))+d*sin(y) Thus, the issue can be with ginsh itself. Do not treat this is an advert of PyGiNaC, but if you are looking for more ginsh-ish behaviour, the previous code can be replaced by: from cginac import * reader=parser() a=reader("(sin(x)+sin(y))*(1+p+q)*(1+d)").expand() print(a.collect([reader("p"),reader("q")])) 1. V.V. Kisil, What is PyGiNaC, anyway?, http://moebinv.sourceforge.net/pyGiNaC.html -- 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 17/03/2021 16:44, Vladimir V. Kisil wrote:
1. V.V. Kisil, What is PyGiNaC, anyway?, http://moebinv.sourceforge.net/pyGiNaC.html
I didn't know this existed, and it looks potentially useful. Any plans to make it installable via pip?
On Wed, 17 Mar 2021 16:57:33 +0100, Vitaly Magerya <vmagerya@gmail.com> said:
VM> On 17/03/2021 16:44, Vladimir V. Kisil wrote: >> 1. V.V. Kisil, What is PyGiNaC, anyway?, >> http://moebinv.sourceforge.net/pyGiNaC.html VM> I didn't know this existed, and it looks potentially useful. Any VM> plans to make it installable via pip? I did not consider this path in details, but due to the GiNaC binary library dependence, it does not seems to be very universal (at least without significant labour). I do provide binary packages for actual Debian/Ubuntu amd64 architecture. Installation-free cloud services with Google Colab or CodeOcean are also available for low-profile usage or testing. -- 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
Dear Vitaly, On 17.03.21 14:57, Vitaly Magerya wrote:
Hi, all. In section 5.7.2 of the docs (Expanding and collecting) there is this example of ginsh usage:
> a=expand((sin(x)+sin(y))*(1+p+q)*(1+d)); > collect(a,{p,q});
The docs say I should get this:
d*sin(x)+(d*sin(x)+sin(y)+d*sin(y)+sin(x))*p
... but actually:
cannot modify multiply referenced object
This is with GiNaC V1.7.6, V1.7.8, and the latest commit of V1.8.0.
How do I make this work?
Does the attached patch work for you? -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
On 22.03.21 10:32, Vitaly Magerya wrote:
On 21/03/2021 13:10, Richard B. Kreckel wrote:
Does the attached patch work for you?
Yeah, that seems to work.
Great! (If I only knew why the original code fails or why ex::operator[] leads straight into lst::let_op(size_t), then I would submit it. I intend to do a little bit of debugging before submitting a patch. Please be patient.) -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
On 22.03.21 22:03, Richard B. Kreckel wrote:
On 22.03.21 10:32, Vitaly Magerya wrote:
On 21/03/2021 13:10, Richard B. Kreckel wrote:
Does the attached patch work for you?
Yeah, that seems to work.
Great!
The little "beauty" attached to this email fixes it, too. What happens is that, within basic::collect(const ex& s), s.operator[i] calls ex::operator[](size_t) const, i.e. the const overload, as the author apparently expected. So far, so good. But, contrary to what the author of said operator[] expected, it does not call basic::operator[](size_t) const for two slightly surprising reasons: 1) ex::bp is of type ptr<basic>, not of type const ptr<basic>, 2) ptr<basic>::operator*() returns a basic &, not a const basic &. Well, this is @%o&X#$* brain-dead. -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>
participants (3)
-
Richard B. Kreckel
-
Vitaly Magerya
-
Vladimir V. Kisil