Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 04 Aug 2014 14:04:52 +0200
From: Gilles <gilles@harfang.homelinux.org>
To: <user@commons.apache.org>
Subject: Re: [math] UnivariateIntegrator stop conditions
In-Reply-To: <53DF6354.9050304@gmail.com>
References: <53DF6354.9050304@gmail.com>
Message-ID: <647c4d6f52cb29dd94bba13004820c62@scarlet.be>
User-Agent: Scarlet Webmail
X-DCC-scarlet.be-Metrics: hel; whitelist
X-Virus-Scanned: clamav-milter 0.98.1-exp at hel
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

On Mon, 04 Aug 2014 14:41:24 +0400, Alexander Nozik wrote:
> The univariate integrator class provides iterative integration
> procedure. It throws exception if the number of evaluations is larger
> than given number. The problem arises when one is limited by some
> performance issues and wants to minimize the number of evaluations
> even at the expense of accuracy. So for example I need to calculate 
> an
> integral with best possible accuracy with limited number of
> evaluations (and check the accuracy afterwards).

I agree that the current design doesn't care for that case.

> I can't do that
> because if UnivariateIntegrator throws the exception, I can not 
> access
> the result. Also it does not make sense why the accurasy is provided
> in the constructor and maximum number of evaluations is the parameter
> of integrate method.

These are decisions made a while back; I recall that there were some
fuzziness as to which parameters should go where.
It was supposedly a trade-off between robustness, efficiency and
flexibility.

The design could be challenged now, provided we can replace it with
something comprehensive. We could draw inspiration from the redesign
of the least-squares fitting implementation (see package
"o.a.c.m.fitting.leastsquares").

> Of course one could use the GaussIntegrator, but it does not
> implement UnivariateIntegrator class, so if one needs to use these
> integrators interchangeably (I do need), than the only option is to
> write some wrapper class.
> It would be good to have a default UnivariateIntegrator wrapper for
> GaussIntegrator.

"GaussIntegrator" is a building block for "IterativeLegendreIntegrator"
(that implements the "UnivariateIntegrator" interface).
It's a self-consistent implementation of a standard algorithm.
I don't think it would be a good idea to clutter it with methods which
you just said that are not flexible enough.

> Also perhaps it makes sense to move maximum
> evaluations to the constructor.

How would that help you?

>
> I believe this question has already been discussed somewhere last
> year but I can't remember the answer.

See above, and the "dev" ML archive.

You are most welcome to propose a new integration framework.


Regards,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org