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