commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [math] UnivariateIntegrator stop conditions
Date Mon, 04 Aug 2014 14:01:47 GMT
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?


> 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:
For additional commands, e-mail:

View raw message