I second the idea of making a long-range plan to work on limit and
taylor. It seems to me that the following rough outline might be a
workable approach:
1) Understand in detail the mathematics behind the existing code.
2) Decide on any changes, etc. in the mathematical part of the
problem.
3) Implement those decisions, i.e., modify the code accordingly.
4) Keep testing it:)
Regarding 1), my knowledge of Lisp is way too inadequate to be able to
read that code now, but my curiosity is strong enough that I am not
likely to give up on that soon. If somebody else would like to to try
to "read together", that might be fun and even get us somewhere. One
way this "read together" might be achieved - I think, could be to open
Maxima Wiki for that kind of collaboration ...
* Richard Fateman <fateman@cs.berkeley.edu> [2005-09-24 14:01:11 -0700]:
> The limit package, and the definite integration (via
> contour integration) was written by Paul S. Wang, now
> at Kent State University. The Taylor series was written
> by Richard Zippel, most recently at DEC/Compaq/HP labs
> in Cambridge MA.
>
> I believe that the commercial Macsyma has a rewritten
> limit package. Since it has some major heuristic
> components, it might not hold up so well under stress
> (like asking it questions not about real functions).
>
This makes me think that perhaps a separate package, say climit, whose
job would be handling complex limits might be worth creating. Then the
limit package could be just for real functions. However, the limit
package could have a built in option to call the climit when needed.
Milan
> I think Taylor is better defined and
> more likely to be correct, though it may have bugs.
>
> I think the "quotient is not exact" bug should be
> stamped out. What is the smallest example exhibiting
> that? I guess there is a way of searching through the
> bug reports, but I haven't figured it out.
> RJF
>
>
> Robert Dodier wrote:
>
> > hello,
> >
> > limit and taylor, between the two of them, account for a
> > substantial fraction of the known bugs in maxima.
> > i wonder if we can formulate some kind of long-range
> > plan to rework or replace those functions.
> > i realize it's likely a very arduous task, but given that
> > those are fairly common operations, it might considerably
> > increase maxima's appeal to fix them.
> > i don't have any clear ideas about how to proceed.
> >
> > for what it's worth,
> > robert dodier
> >
> > _______________________________________________
> > Maxima mailing list
> > Maxima@math.utexas.edu
> > http://www.math.utexas.edu/mailman/listinfo/maxima
>
> _______________________________________________
> Maxima mailing list
> Maxima@math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
--