>
> > >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?
>
> I think numerical evaluation of integrals is inherently a much
> trickier process than evaluation of simple functions.
Agreed.
But generally, the process of numerical integration depends on several
> types of things which may not be well specified by a simple
> integrate(...) for example, which rules are you using, what are your
> error tolerances, what are the stopping conditions, did the rule
> detect convergence, is the rule used specially for particular types of
> functions and if so, is this one of those types of functions?
Understood.
On a related note, I generally tend to prefer that functions behave in
> a manner completely specified by the arguments, but I see your point
> about global variables in the interactive case and where we want many
> related things to behave the same (such as wanting numerical
> integration and numerical root finding and spline interpolation all to
> have the same relative stopping error...)
>
It's not just the interactive case. In general, you would like to be able
to manipulate the same expression and do different things with it
programmatically as well as interactively. If after manipulating an
expression you end up with a definite integral somewhere in the middle, what
do you do to get a numerical value? Do you have to traverse the tree
looking for integrals and then make explicit calls to nintegrate?
By the way, I have found some more simple cases where the current draft
nintegrate is buggy....
nintegrate(nintegrate(x*y,x,0,1),y,0,1) => internal error
nintegrate(nintegrate(1,x,0,a),y,0,1) => internal error
(this is no doubt the same case as nintegrate(q+1,x,0,1) )
(arghh, q+1 behaves differently from q because of the
function-name hack)
and it's really getting annoying that it insists on compiling the function
before evaluating it. In many cases, the overhead of compiling is much much
larger than the amount of time saved -- especially of course when it
immediately hits an error.. Is this under control of a switch?
-s