Thread: Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_36-base-10

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

[moved to maxima-discuss from the old maxima list]

On 05/18/2015 01:16 AM, Raymond Toy wrote:
> 
> 
> On Sat, May 16, 2015 at 9:10 PM, Kris Katterjohn
> <kj...@us... <mailto:kj...@us...>> wrote:
> 
>     This is an automated email from the git hooks/post-receive script.
>     It was
>     generated because a ref change was pushed to the repository containing
>     the project "Maxima CAS".
> 
>     The branch, master has been updated
>            via  2b1366c1ffb07f117f3a4256aff2efe718141122 (commit)
>            via  4746f47c5491593dd7c7e2ef757fdd8a7c43d675 (commit)
>            via  59ec160bfe9883b3e0a76b6529adca90f61ee99d (commit)
>            via  2f63280ffda2eb51ebb5ff44d7c93cfc30a3672e (commit)
>            via  bfafbab18bfe8a5fc76d8c415218d3b372e318dc (commit)
>           from  f238ef41c0cbfa828b0a2e8cef3d16f70cf659b7 (commit)
> 
>     Those revisions listed above that are new to this repository have
>     not appeared on any other notification email; so we list those
>     revisions in full, below.
> 
>     - Log -----------------------------------------------------------------
>     commit 2b1366c1ffb07f117f3a4256aff2efe718141122
>     Author: Kris Katterjohn <kat...@gm...
>     <mailto:kat...@gm...>>
>     Date:   Sat May 16 22:53:02 2015 -0500
> 
>         Fix issues with gamma_incomplete's GRAD and psi's INTEGRAL
>     properties
> 
>         Part of the GRAD property for gamma_incomplete and the INTEGRAL
>         property for psi are implemented with Lisp lambda expressions.  The
>         parameters in the lambda lists should have been used to
>     construct the
>         return values, but this was not done correctly (symbols matching the
>         parameters' names were used in quoted lists instead of using the
>         parameters' values).
> 
>         The parameter names in the lambda lists match the dummy variable
>     names
>         in the CARs of the GRAD and INTEGRAL properties, so the intended
>         functionality still happened to work.  If the dummy variables were
>         consistently renamed then this would cease to work.
> 
> 
> Is there a test case for this?  I think that would be a useful addition.
> 

I think that maybe I wasn't explicit enough in describing my use of the
phrase "dummy variables" in the commit message, so I'll give a more
in-depth description here (so hopefully the commit message will make
more sense).  I'm assuming that this caused confusion.

The dummy variables I mentioned in the commit message are not the "dummy
variables" we use in calling diff, integrate, etc.  So prior to this
commit using different variable names would work as expected:

(%i1) assume(a>0, b>0)$

(%i2) diff(gamma_incomplete(a,z), a);
(%o2) (-(gamma(a)-gamma_incomplete(a,z))*log(z))
 +gamma(a)^2*hypergeometric_regularized([a,a],[a+1,a+1],-z)*z^a
 +(psi[0])(a)*gamma(a)

(%i3) diff(gamma_incomplete(b,x), b);
(%o3) (-(gamma(b)-gamma_incomplete(b,x))*log(x))
 +gamma(b)^2*hypergeometric_regularized([b,b],[b+1,b+1],-x)*x^b
 +(psi[0])(b)*gamma(b)

In this example, the dummy variables I mentioned are the ones stored in
the symbol plist for gamma_incomplete:

(%i1) :lisp (get '%gamma_incomplete 'grad)
((A Z)
 #<Anonymous Function #x300001F1B84F>
 ((MTIMES) -1 ((MEXPT) $%E ((MTIMES) -1 Z)) ((MEXPT) Z ((MPLUS) -1 A))))

(%i1) diff(gamma_incomplete(f,s),s);
(%o1) -s^(f-1)*%e^-s

So these A and Z are the dummy variables (as seen being used in the
expression for the derivative wrt the second argument).

Consistently renaming the (visible) dummy variables from A, Z to Q, R
still gives a working derivative wrt the second arg:

(%i2) :lisp (get '%gamma_incomplete 'grad)
((Q R)
 #<Anonymous Function #x30200077556F>
 ((MTIMES) -1 ((MEXPT) $%E ((MTIMES) -1 R)) ((MEXPT) R ((MPLUS) -1 Q))))

(%i2) diff(gamma_incomplete(f,s),s);
(%o2) -s^(f-1)*%e^-s

However, prior to this commit, the derivative wrt the first arg would
then give the wrong variables in the result (the bare Lisp symbols ?a
and ?z instead of f and s):

(%i3) lispdisp:true$
(%i4) assume(f>0)$

(%i5) diff(gamma_incomplete(f,s),f);
(%o5) (-gamma_incomplete_generalized(?a,0,?z)*log(?z))
 +gamma(?a)^2*hypergeometric_regularized([?a,?a],[?a+1,?a+1],-?z)*?z^?a
 +(psi[0])(?a)*gamma(?a)

After this commit it works correctly.

So the problem would occur only when changing the dummy variables in the
plist (which should be a valid thing to do, since they're supposed to be
dummy variables...).  It doesn't make sense to me for the lambda
expression (anonymous function) to depend on its parameters and also the
dummy variables in the plist if its parameters are all that it needs.

So I'm not sure of a good test for this.  Or perhaps I misunderstood
your suggestion?

Either way, I hope this helps explain what's going on in the commit.

Cheers,
Kris Katterjohn

Thread: Re: [Maxima-discuss] [Maxima-commits] [git] Maxima CAS branch, master, updated. branch-5_36-base-10

Computer Algebra System written in Common Lisp

maxima-discuss