Does this patch look OK?



The thread "Maxima integration bug," which started on April 19,
contained a couple of integration bugs in Maxima. I have added the
following tests to rtest15.mac:

------------------------------------------------------------
/* Maxima has a bug causing an incorrect answer for the second integral.
*/
integrate(diff(f(x,y),x,1,y,1),x);
'DIFF(f(x,y),y,1)$
integrate(diff(f(x,y),x,1,y,1),y);
'DIFF(f(x,y),x,1)$
/* The same bug causes a bug with the second integral in this set. */
h(x,y):=x*y*diff(f(x,y),x,1,y,1);
h(x,y):=x*y*DIFF(f(x,y),x,1,y,1)$
integrate(h(x,y),x);
'INTEGRATE(x*'DIFF(f(x,y),x,1,y,1)*y,x)$
integrate(h(x,y),y);
'INTEGRATE(x*'DIFF(f(x,y),x,1,y,1)*y,y)$
------------------------------------------------------------

Juan Pablo Hierro Álvarez proposed two patches in the attached messages.
They look good to me. The above tests pass after applying his patches.
As always with the maxima math core, I would like to have others
(particularly Richard) take a look at patches before I commit them.

Thanks,
Jim

Date: Sun, 21 Apr 2002 03:06:01 +0200
From: Juan Pablo Hierro =?iso-8859-1?q?=C1lvarez?= <BUSCAIDEAS at terra>
Subject: Re: [Maxima] Maxima integration bug

-----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=20
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=20
_______________________________________________
Date: Wed, 24 Apr 2002 00:47:09 +0200
From: Juan Hierro <BUSCAIDEAS at terra>
Subject: Fwd: Re: [Maxima] Maxima integration bug
To: maxima@mail.ma.utexas.edu

I forgot to send this mail to the list.
----------  Mensaje reenviado  ----------

Subject: Re: [Maxima] Maxima integration bug
Date: Sat, 20 Apr 2002 06:01:39 +0200
From: Juan Pablo Hierro Álvarez <BUSCAIDEAS at terra>
To: Phroexus@aol.com

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

Try the following patch
___________________
371c371,374
<                expr                           ;single
---

>                  (if (null old-wrt)
>                      expr                     ;single
>                      `((%derivative), expr    ;partial in old-wrt
>                        ,.(nreverse old-wrt)))

_____________________
in file sin.lisp

The line numbers may be changed in your file as I have already applied
Jenkner's patch. Anyway, the problem lies in the function checkderiv1 and the
patch begins in its sixth line.

It is very instructive to make
to_lisp();
(trace sinint checkderiv1)
and look at what is happening with maxima compiled with cmucl18d because gcl
hides a recursive call in checkderiv1. On the other hand, to realize that the
problem was inside checkderiv1, I had to trace the algorithm with gcl, as
cmucl does not like to trace many functions of maxima.

I think now that the use of different compilers to test maxima code is one of
the best tools to debug it, as each one covers up the troubles of the other.
--
Juan Pablo Hierro Álvarez
hierro en ideafix punto litec punto csic punto es
Clave pública: 0xA8707ADF en pgp.rediris.es

-------------------------------------------------------