On Mon, 04 Aug 2014 16:54:06 +0400, Alexander Nozik wrote:
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).
A shame that we didn't work together to create that framework two
years ago... ;-)
I think it is rather good
approach to any iterative process. This way one can control any stage
of it.
Thanks to Evan Ward for the redesign effort.
We are lagging behind with the documentation (user/developer guide) of
this approach, as well as applying to other areas of CM (the "optim"
package, and "integration" and "solvers" and ...
Help is needed!
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.
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.]
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.
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).
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?
Regards,
Gilles
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]
