SERIOUS simpsum bug



On Sat, 23 Nov 2002, Stavros Macrakis wrote:

> > > Finally, I'd like to ask why simpsum does not call the Gosper
> > > algorithm (nusum)? I guess that simpsum is only called on demand,
> > > when the user REALLY wants to have a simple answer and believes
> > > that there is one?
> 
> There are two main issues here.
> 
> One is how much simplification you do on 'fun(...).  Even in the case of
> integrate, limit, diff, etc., the quoted form still does some
> simplification, e.g. 'integrate(1,x,1,3) => 2, limit(x,y,0) => x.  Along
> those lines, 'sum(1,i,1,10^7) => 10^7.  In general, Maxima tries not to
> be too aggressive in simplifying, because the original form of the
> expression may have some value.  Also, nusum (for example) is not robust
> when it fails -- though I suppose it should be.
> 
> The other is what does fun(...) mean.  In the case of integrate, limit,
> diff, etc., it invokes a good algorithm for finding closed-form
> solutions.  This is not necessarily the most powerful algorithm known,
> or even the best or most powerful one available within Maxima.
> 
> For most of these operators, there are the two possibilites for exact
> answers: light simplification or finding a closed-form solution.  There
> is also the possibility of numerical evaluation, but that is no longer
> exact.  In the case of sum, there are three possibilities with exact
> answers: light simplification, carrying out the sum term-by-term (in
> some cases), and finding a closed-form solution.  All three are useful,
> and there is no obvious way to mark the difference within existing
> Maxima conventions.

OK, what I meant was: do some "light" simplification by default. Provide a
sum-simplifyer which is state of the art. I thought simpsum/simpsum2 does
follow this approach.  So what I mean is: keep simpsum, let simpsum2 try
hard. (including Zeilberger, perhaps)

In fact, I think mma does a rather bad job here. Zeilberger is ALWAYS
called!

Another issue: I think simpsum2 should only be called when we have an 
indefinite summation or (perhaps) when hi-lo is LARGE. Now it seems that 
it is called also for

'sum(f(k),k,0,2), simpsum;

which is no use. (except it made me discover the bug)

Did you look at the bug?

Thanks,
Martin

--------------------------------------------------------------------------
------ the rest is an example to illustrate ?simpsum and ?simpsum2 -------
--------------------------------------------------------------------------

trace(?simpsum,?simpsum2);
trace_options(?simpsum,lisp_print);
trace_options(?simpsum2,lisp_print);

(C25) sum(binomial(n,k),k,0,n);


(1 ENTER SIMPSUM
 (((%SUM) ((%BINOMIAL SIMP) |$n| |$k|) |$k| 0 |$n|) 1 T)) 
(1 EXIT SIMPSUM ((%SUM SIMP) ((%BINOMIAL SIMP) |$n| |$k|) |$k| 0 |$n|)) 
			      n
			     ====
			     \
(D25) 			      >	   BINOMIAL(n, k)
			     /
			     ====
			     k = 0
(C26) sum(binomial(n,k),k,0,n),simpsum;


(1 ENTER SIMPSUM
 (((%SUM) ((%BINOMIAL SIMP) |$n| |$k|) |$k| 0 |$n|) 1 T)) 
 (1 ENTER SIMPSUM2 (((%BINOMIAL SIMP) |$n| |$k|) |$k| 0 |$n|)) 
 (1 EXIT SIMPSUM2 ((MEXPT SIMP) 2 |$n|)) 
(1 EXIT SIMPSUM ((MEXPT SIMP) 2 |$n|)) 
				       n
(D26) 				      2

-------- here simpsum2 is not called - only "light" simplification ------

(C9) sum(1,k,0,n),simpsum;


(1 ENTER SIMPSUM (((%SUM) 1 |$k| 0 |$n|) 1 T)) 
(1 EXIT SIMPSUM ((MPLUS SIMP) 1 |$n|)) 
(D9) 				     n + 1