[Date Index]
[Thread Index]
[Author Index]
Re: 2D Integration
*To*: mathgroup at yoda.physics.unc.edu
*Subject*: Re: 2D Integration
*From*: Robert Singleton <bobs at thnext.mit.edu>
*Date*: Mon, 14 Jun 93 15:12:13 -0400
I previously wrote,
> A while back I posted a question on 2D integration - i.e. is
> there a good way to do this in Mma? It would be nice if WRI
> would make a decent 2D or 3D integration routine (hint hint) --
> the built in Mma NIntegrate is much too slow for multiple
> integration involving interpolating functions.
> ...
and Jerry Keiper replies,
> It is not clear what is meant by "decent", but presumably the
> idea is to sacrifice accuracy for speed. The default options for
> NIntegrate are set to give 6 digits (assuming machine precision
> calculations) in the final result. Moreover the estimate of the
> error is rather conservative so you often get a relative error
> that is much less than 10^-6.
>
> But that is no reason to consider NIntegrate[ ] "indecent".
> As a user you are perfectly free to choose a different
> AccuracyGoal or PrecisionGoal.
Jerry goes on to give an example where he changes the default
values of AccuracyGoal and PrecisionGoal in NIntegrate[] to
integrate the function Exp[-x+2 y^2]. The result is very fast.
This post is to warn people that Jerry's reply was VERY misleading.
There is a definite deficiency in NIntegrate[] that would be in the
best interest of WRI to correct. In my original post I specified that
I was working with an InterpolatingFunction. In this case there is
*NOTHING* that I have been able to do to make NIntegrate "decent" -
except I now use Terry Robb's very nice routine ArrayIntegrate[]
that integrates a list of data (or I use Maple).
Terry Robb writes:
>As I understand it, [Bob Singleton] had an array of data values,
>and he thought of fitting an InterpolatingFunction through it and
>then calling NIntegrate[]. This of course does turn out to be slow.
>
>It's a pity that NIntegrate[] doesn't realize that if it is dealing
>with an InterpolatingFunction[range,table] object, then it could
>directly produce the integral from the information in the table.
>After all D[] knows how to handle InterpolatingFunction's, so why
>not NIntegrate[] and Integrate[] too?
This is VERY good suggestion! Why not make NIntegrate[] simply use
the data points when it receives an InterpolatingFunction?!?
BTW, the type of problem I'm doing can be rather common in physics.
If you have a system that is described by some differential
equations that you can only solve numerically (using NDSolve[] which
gives it's output in the form of an InterpolatingFunction[]), and you
then want to find the energy or some other other property that
involves integrals over functions of the solutions, then you will run
into trouble using NIntegrate[] (unless you just get lucky and only
need to do a 1D integral). This is a serious deficiency on the part
of NIntegrate and I hope that WRI takes the necessary steps to fix
it. Until they do I recommend either Maple or Terry Robb's very nice
ArrayIntegrate[] (the reason it's so nice is because the program is
so short and elegant).
Regards,
Bob Singleton
Prev by Date:
**Re: trig functions**
Next by Date:
**D and InterpolatingFunction**
Previous by thread:
**Re: 2D Integration**
Next by thread:
**Re: 2D Integration**
| |