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 (athena.apache.org: domain of altavir@gmail.com designates
 209.85.215.43 as permitted sender)
Message-ID: <53DF826E.4070706@gmail.com>
Date: Mon, 04 Aug 2014 16:54:06 +0400
From: Alexander Nozik <altavir@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: user@commons.apache.org
Subject: Re: [math] UnivariateIntegrator stop conditions
References: <53DF6354.9050304@gmail.com>
 <647c4d6f52cb29dd94bba13004820c62@scarlet.be>
In-Reply-To: <647c4d6f52cb29dd94bba13004820c62@scarlet.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thank you for pointing to fitting.leastsquares package. It should be 
rather new (from 3.3 as i see), since I haven't noticed it last time I 
looked through the library. In fact I have my own fitting framework 
which is rather similar in the structure (developed it two years ago, a 
shame there was no such framework then). I think it is rather good 
approach to any iterative process. This way one can control any stage of it.

As for:
>> Also perhaps it makes sense to move maximum
>> evaluations to the constructor.
>
> How would that help you? 

The problem is that I need a lot of integrations done. So I have one 
integrator object configured and use different functions and different 
borders as arguments. I can't create multiple GaussIntegrator rules 
because rule calculation is very time consuming, so it is easier to 
calculate the rule one time and then transform it for different 
boundaries. So I made a wrapper which does it automatically. It is 
obviously logical (consider me an esthete) that such wrapper should 
implement UnivariatieIntegrator. The only problem is than 
UnivariateIntegrator interface requires also maximum number of 
evaluations which is useless in case of Gauss rule integrator. Also even 
in problems with no performance issues one usually does not know a 
priory how much evaluations he will need. I think the whole 
inconvenience could be solved by providing additional 
integrate(UnivariateFunction f, double min, double max) method in 
UnivariateIntegrator which uses some default value for maxEval (meaning 
that maxEval is in general provided by function but have default value 
stored in the integrator). Of course, implementing design from 
fitting.leastsquares completely solves any problems since it applicable 
for both fixed nodes integrators and iterative integrators.

With best regards, Alexander Nozik.

P. S. Probably it is wise to think slightly ahead and develop 
integration framework so it could be applied to non-univariate cases.


On 04-Aug-14 16:04, Gilles wrote:
> 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
>


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