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: [email protected]
For additional commands, e-mail: [email protected]
