Maxima integration bug



Hi,

I know this thread is very old, but I'm trying to harvest all the
unapplied patches on the list. Below you refer to "my previous patch." I
can't seem to find that patch. Could you please resend it?

Has anyone else looked at the patch below? It sounds OK to me, but I
haven't looked at it in detail.

--Jim

On Sat, 2002-04-20 at 20:06, Juan Pablo Hierro Álvarez wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> El Sáb 20 Abr 2002 00:25, escribió:
> > when you enter integrate(diff(f(x,y),x,1,y,1),y) into maxima you get f(x,y)
> > - a fix for this had been worked out for commercial macsyma but I do not
> > have it - can someone help out?
> >
> > note that integrate(diff(f(x,y),x,1,y,1),x) returns the correct result
> >
> > thanks
> > Peter Vafeades
> 
> More on the problem. Although the previous patch I send solves this problem. 
> There are deeper problems in the algorithm which appear if one tries
> h(x,y):=x*y*diff(f(x,y),x,1,y,1);
> integrate(h(x,y),x);
> integrate(h(x,y),y);
> 
> One gets:
>                                          /       2
> 			  [     d
> (D2) 			 (I x (----- (f(x, y))) dx) y
> 			  ]    dx dy
> 			  /
> and
> 					  2
> 				  x f(x, y )
> (D3) 				  ----------
> 				      2
> respectively.
> 
> After applying my previous patch the second result looks better but it is 
> still wrong.
> 			           d         2
> 			       x (-- (f(x, y   )))
> 			          dx
> (D3) 			       -----------------
> 				  2
> 
> This time the problem does not lie in checkderive1 but in rat10.
> To realize it, it is a good idea to simultaneously trace: integrator, 
> powerlist and rat10. There is a call to powerlist close to the end of 
> integrator which returns nil when one integrates over x and a different 
> expresion where the ((RAT SIMP) 1 2) has already appeared when the 
> integration is performed over y. In the end, that difference arises from a 
> call to rat10 which returns nil in the first situation and t in the other one.
> 
> My proposal to solve this last problem is the following patch:
> __________________
> 475c478,485
> < 	(T (RAT10 (CAR (MARGS EX))))))
> - ---
> > 	(T
> >            (let ((examine (margs ex)))
> >              (if (atom (first examine))
> >                (do* ((element examine (rest element))
> >                        (result (rat10 (first examine))
> >                                  (and result (rat10 (first element)))))
> >                       ((or (null result) (null element)) result))
> >                (rat10 (first examine)))))))
> ___________________
> which affects the last condition considered in rat10. The present version 
> recursively searchs in the car of the list of arguments which is good if such 
> list is nested but not if the list is flat. The different behaviour is 
> appreciated when a recursive call to rat10 with arguments (|$x| |$y|) is made.
> With the present code, only |$x| is compared with the variable of 
> integration. My patch forces to compare all arguments, when the first of them 
> is an atom, and stops if there is someone which returns nil, passing up that 
> nil whose meaning is that there is some argument "alike1" the variable the 
> integration.
> - -- 
> Juan Pablo Hierro Álvarez
> hierro en ideafix punto litec punto csic punto es
> Clave pública: 0xA8707ADF en pgp.rediris.es 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE8whCDd1aMoahwet8RAmSBAJ9vhJGNj5r5JXV8LxBFTYVLPs+5GQCcCtrh
> vUP3Bwajp7vmQI8lFd11QTg=
> =Jb86
> -----END PGP SIGNATURE-----
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>