commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Nozik <alta...@gmail.com>
Subject Re: [math] UnivariateIntegrator stop conditions
Date Mon, 04 Aug 2014 14:51:12 GMT

>> 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.
>
> Did you have a look at e.g.
>   GaussIntegratorFactory.legendre(int numberOfPoints, double 
> lowerBound, double upperBound)
> ?
>
> ["GaussIntegratorFactory" contains singleton factories that hold the
> rules and compute them _once_; only the rescaling is performed at each
> call of the above function.]

As far as I remember, I have tried it, but found that it still 
recalculates rule on call.
I just looked through the source code and found the problem:

public abstract class BaseRuleFactory<T extends Number> {
     /** List of points and weights, indexed by the order of the rule. */
     private final Map<Integer, Pair<T[], T[]>> pointsAndWeights
         = new TreeMap<Integer, Pair<T[], T[]>>();
     /** Cache for double-precision rules. */
     private final Map<Integer, Pair<double[], double[]>> 
pointsAndWeightsDouble
         = new TreeMap<Integer, Pair<double[], double[]>>();

It is not in fact a singleton. It stores generated rules only in the 
current instance, not across different factory instances. Perhaps these 
maps are meant to be static?

>> 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.
>
> But that's the reason why UnivariateIntegrator should _not_ be
> implemented by GaussIntegrator.
>
> Or you mean that we should change the interface itself?
> If breaking the compatibility, we should strive for a complete solution
> rather that move some parameters a little from here to there.

I agree that it is better to redo the whole thing than to place some 
patches.

>> 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).
>
> But this won't help you with the raised exception problem. Or
> I'm missing something.
> I think that a solution would be to be able to configure a
> callback (that will by default raise an exception, but could
> otherwise be defined to simply return after the number of
> evaluations have been exhausted).

It will do, but still probably it is better to redesign the whole 
framework. Probably we need something like Condition class which could 
contain either number of evaluations condition either accuracy criterion.

>> 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.
>
> Concrete (i.e. code) proposal for going ahead?

I have a piece of code for multivariate Monte-Carlo integration 
(supports different sampling algorithm). I will try to make some 
proposal on Integrator API which could include both univariate and 
multivariate cases.  Will report to you when I am done. Not promising 
that it will be soon.


>
> Regards,
> Gilles


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


Mime
View raw message