argument for integrate and nintegrate being separate AS COMMANDS.
it is perfectly reasonable to prefer to numerically integrate something that
can also be done symbolically.
how does one write that?
It would be troublesome to have to type
'integrate(...),numer with the quote in there, to avoid doing the
symbolic integral. or some such odd arrangement.
Also, there are many many options to numerical integration that make no
sense to integrate. Like number of panels, error bounds, methods.
For sin() it is sometimes troublesome that sin(1) is an expression but
sin(1.0d0) is a number. But sin(0) is a number.
So I would not use that as a guideline.
If you want to talk about the abstract notion of integration with an
expression having an integral sign, I'm not sure that Maxima's integrate()
does it.
Lebesgue integration? Riemann integration? ... etc.
_____
From: maxima-bounces at math.utexas.edu [mailto:maxima-bounces at math.utexas.edu]
On Behalf Of Stavros Macrakis
Sent: Wednesday, May 23, 2007 2:28 PM
To: Andrej Vodopivec
Cc: Maxima - list
Subject: Re: [Maxima] nintegrate function
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