Menu
▾
▴
1 Attachments
#3564 pochhammer(a,u-v);pochhammer(a,v-u)
pochhammer(a,u-v) gives an incorrect answer
Apparently pochhammer() has an opinion about ascii ordering in the second argument; the same thing happens with m-n,n-m.
I looked at the lisp file but I am not that good at lisp.
I will make a macro work around for my work.
Here is a cut and paste
maxima
Maxima 5.42.0 http://maxima.sourceforge.net
using Lisp SBCL 1.4.5.debian
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) batch("maxima-poch.mac")$
read and interpret file: /home/rrogers/tmp/maxima-poch.mac
(%i2) pochhammer(a,u-v)
1
(%o2) --------------------
((- v) + u + a)
v - u
(%i3) pochhammer(a,v-u)
(%o3) (a)
v - u
(%i4)
Attached is maxima-poch.mac. My cut and paste didn't come through very well.
Diff:
Can you explain what is incorrect in the result of
pochhammer(x, u - v)?From what I can tell the result is correct, although perhaps needlessly complicated. If that's the case, then the problem to be solved is to suppress the simplification under some conditions. Let's verify what kind of problem we have to solve and go from there.
The rule does allow for simplifications such as
But it does make some expressions more complicated. It's kind of a trade-off of which simplications are most important.
Your right but I have a problem trying to fix it.
kill(a,b,aa,bb);
assume(a<b); ;pochhammer(x,a-b);="" pochhammer(x,b-a)="" assume(a="">b);
pochhammer(x,b-a) ;pochhammer(x,a-b);</b);>
assume(aa<bb); assume(aa="">bb);</bb);>
?? Apparently assume() is set in it's ways. Probably a misunderstanding
of assume() on my part.
I can't make pochhammer() fail but
http://mathworld.wolfram.com/PochhammerSymbol.html
Eq: 13
indicates that there may be a gotcha somewhere.
I don't have the reference (Boros and Moll 2004, p. 17).
so I can't say for sure.
I have a discrepancy between celine() (maxima) and sumrecursion() (reduce)
but I am working on reducing :-) it.
Ray
On 6/22/19 5:45 PM, Barton Willis wrote:
The simplification code for pochhammer uses an expression ordering function to decide when to use the reflection formula, not the sign of the second argument. Try this:
(%i1) pochhammer(x,a-b);
(%o1) 1/pochhammer(x-b+a,b-a)
(%i2) ordergreat(a,b)$
(%i3) pochhammer(x,a-b);
(%o3) pochhammer(x,a-b)
As for any bugs in celine, please let me know--as you might know, I wrote code for both pochhammer and celine, I think. And if you have found a pochhammer bug, please let me know and file a bug report too.
--Barton
From: Raymond Rogers rrogers@users.sourceforge.net
Sent: Sunday, June 23, 2019 11:02:55 AM
To: [maxima:bugs]
Subject: [maxima:bugs] Re: #3564 pochhammer(a,u-v);pochhammer(a,v-u)
Your right but I have a problem trying to fix it.
kill(a,b,aa,bb);
assume(a<b); ;pochhammer(x,a-b);="" pochhammer(x,b-a)="" assume(a="">b);
pochhammer(x,b-a) ;pochhammer(x,a-b);</b);>
assume(aa<bb); assume(aa="">bb);</bb);>
?? Apparently assume() is set in it's ways. Probably a misunderstanding
of assume() on my part.
I can't make pochhammer() fail but
http://mathworld.wolfram.com/PochhammerSymbol.htmlhttps://urldefense.proofpoint.com/v2/url?u=http-3A__mathworld.wolfram.com_PochhammerSymbol.html&d=DwMGaQ&c=Cu5g146wZdoqVuKpTNsYHeFX_rg6kWhlkLF8Eft-wwo&r=Ln0CjFotuA7GyhsRS-QpQA&m=O6BP6lNjewCXAzhg-FrmbT2VoWYjKGyRqrzljt-4HXI&s=2qg7j4p16aY-_ivrO7cG5_rrWpq9jzt6BIqrz9zmJ1c&e=
Eq: 13
indicates that there may be a gotcha somewhere.
I don't have the reference (Boros and Moll 2004, p. 17).
so I can't say for sure.
I have a discrepancy between celine() (maxima) and sumrecursion() (reduce)
but I am working on reducing :-) it.
Ray
On 6/22/19 5:45 PM, Barton Willis wrote:
pochhammer(x,b-a) * pochhammer(x+b-a,a-b);
[bugs:#3564]https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_maxima_bugs_3564_&d=DwMGaQ&c=Cu5g146wZdoqVuKpTNsYHeFX_rg6kWhlkLF8Eft-wwo&r=Ln0CjFotuA7GyhsRS-QpQA&m=O6BP6lNjewCXAzhg-FrmbT2VoWYjKGyRqrzljt-4HXI&s=SUO4ozQRY5Noapys9jAVpQ34_hThyB7iL6kui8ts7_E&e= pochhammer(a,u-v);pochhammer(a,v-u)
Status: open
Group: None
Labels: pochhammer
Created: Sat Jun 22, 2019 08:16 PM UTC by Raymond Rogers
Last Updated: Sat Jun 22, 2019 09:45 PM UTC
Owner: nobody
Attachments:
pochhammer(a,u-v) gives an incorrect answer
Apparently pochhammer() has an opinion about ascii ordering in the second argument; the same thing happens with m-n,n-m.
I looked at the lisp file but I am not that good at lisp.
I will make a macro work around for my work.
Here is a cut and paste
maxima
Maxima 5.42.0 http://maxima.sourceforge.net
using Lisp SBCL 1.4.5.debian
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) batch("maxima-poch.mac")$
read and interpret file: /home/rrogers/tmp/maxima-poch.mac
(%i2) pochhammer(a,u-v)
1
(%o2) --------------------
((- v) + u + a)
v - u
(%i3) pochhammer(a,v-u)
(%o3) (a)
v - u
(%i4)
Attached is maxima-poch.mac. My cut and paste didn't come through very well.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/maxima/bugs/3564/https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_maxima_bugs_3564_&d=DwMGaQ&c=Cu5g146wZdoqVuKpTNsYHeFX_rg6kWhlkLF8Eft-wwo&r=Ln0CjFotuA7GyhsRS-QpQA&m=O6BP6lNjewCXAzhg-FrmbT2VoWYjKGyRqrzljt-4HXI&s=SUO4ozQRY5Noapys9jAVpQ34_hThyB7iL6kui8ts7_E&e=
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_auth_subscriptions_&d=DwMGaQ&c=Cu5g146wZdoqVuKpTNsYHeFX_rg6kWhlkLF8Eft-wwo&r=Ln0CjFotuA7GyhsRS-QpQA&m=O6BP6lNjewCXAzhg-FrmbT2VoWYjKGyRqrzljt-4HXI&s=nW9cwRAZhshw-dGMVWejcmqZLY-kAAVDZowtsm8o5Io&e=
Related
Bugs:
#3564Thank you :)
I haven't quite found a bug in the celine() results. When done
(properly!) it gives and answer that looks like it might be right; if I
knew how to resolve the returned recursion. Reduce's zeilberger() gives
a short (two term) recursion that is obvious. For three terms I have to
renovate previous learning's. Gosper and zeilberger() in Maxima both
declare the problem to "not have a hypergeometric" term; or some such.
I am working my way back through A=B and should be able to find the answer.
This started with a friends problem/challenge.
I tried it by hand.
I tried it in Reduce (with a lot mote success)
I tried to verify it in Maxima (in process).
In software:
"Trust but Verify"
Ronald Reagan (1986 or so)
"It's mostly right"
Ray Rogers (innumerable times)
P.S. maybe some mention of ordergreat() could find it's way into the
celine() page to avoid upsetting the ignorant and why doesn't assume()
contain the functionality? But I will remember it in the future.
On 6/23/19 4:58 PM, Barton Willis wrote:
Related
Bugs:
#3564I'm closing this item as "won't fix" since it appears that the pochhammer result is correct (although more complicated than it needs to be). Issues related to celine, zeilberger, etc can be addressed in separate reports.