On 5/23/07, Andrej Vodopivec <andrej.vodopivec at gmail.com> wrote:
>
> On 5/23/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> > A big issue in the design is: should nintegrate in fact be a separate
> > function from integrate?,,,
>
> I would prefer to have a separate function for numerical integration.
Why? We don't have a separate function for numerical evaluation of sin; why
should we have a separate function for numerical evaluation of integrals?
> The current nintegrate in fact doesn't simplify at all if the limits
> aren't numeric...
> > nintegrate(q,x,a,b) => no change
>
> [it] should return unchanged.
Why shouldn't it return (b-a)*q just like symbolic integration?
If q is a function then nintegrate(q,x,a,b) is equivalent to
> nintegrate(q(x),x,a,b).
If the meaning of nintegrate depends on whether its first argument is a
symbol, then it shouldn't be a simplifying function because it is no longer
invariant under substitution, a basic property of expressions.
This is very useful for functions which you can compute for numerical values
> but q(x) produces an error.
In those cases, you can use '(q(x)), but that shouldn't be necessary with
well-written functions. Maxima is a symbolic system, and functions should
operate properly on symbolic as well as numeric arguments. (And yes, I know
that conditional expressions are an issue...)
In the end, the behavior you're describing really isn't that of a
simplifying function, but of a command.
About the error cases, good error messages are always nice (though they can
complicate programmatic use...), but the problem here is that it is not an
error! Just because Maxima/Quadpack can't find the answer doesn't mean
there is an error. Now, if the *client* of nintegrate expects a float, then
of course *it* should give an error. But nintegrate should just return the
simplified result nintegrate(...)
> > I don't know much about numeric integration routines; should nintegrate
> be
> > using other, more robust ones in some of the above cases?
>
> These are really limitations of the quadpack functions. The first one
> happens because the exact value is 0 (it happens for all cases where
> the exact value is 0). The second one can be done if you increase the
> number of subintervals. Error code 5 says that convergence is too
> slow. I don't know how to get maxima to compute it.
>
Well, if we're going to have a standard numerical integration function, it
needs to work around at least some of these limitations. I suppose the
zero-result thing is because it can't bound the relative error, but
still....
By the way, here are some more bugs:
nintegrate(1/x,x,-1,1) => T is not of type (or rational lisp:float)
nintegrate(lambda([x],1/x),x,-1,1) => Division by zero
nintegrate(lambda([x],print(x),1/x),x,-1,1) => Error number 2
( l:[], nintegrate(lambda([x],l:cons(x,l),1/x^2),x,-1,1) => NIL is
not of type...
Why do these four cases act differently?
-s