Hi,
Le 26/11/2010 14:23, Gilles Sadowski a écrit :
>
>>> [...]
>>> Question is how reconfigure() is configured?
>>
>> It is entirely up to the user who implements it, and it depends on the
>> algorithm he chose. If the algorithm does have some setXxx() setter, he
>> could do:
>>
>> public Differ
>However, can we slow down on the new features? (Am I saying this? ;-)) [We
previously agreed that the main algorithm code should be put in place before
>any other bells and whistles.]
We didn't discuss when a possible enhancement of
MultiStartMultivariateRealOptimizer
will be implemented, just w
> > [...]
> > Question is how reconfigure() is configured?
>
> It is entirely up to the user who implements it, and it depends on the
> algorithm he chose. If the algorithm does have some setXxx() setter, he
> could do:
>
> public DifferentiableMultivariateVectorialOptimizer
> reconfigure(
Le 26/11/2010 13:34, Dr. Dietmar Wolz a écrit :
>> Should we simply allow user to register an instance of some optimizer
> reconfigurator interface in the constructor ? Something like:
>>
>> public MultiStartDifferentiableMultivariateVectorialOptimizer(
>> DifferentiableMultivariateVectori
>Should we simply allow user to register an instance of some optimizer
reconfigurator interface in the constructor ? Something like:
>
> public MultiStartDifferentiableMultivariateVectorialOptimizer(
> DifferentiableMultivariateVectorialOptimizer optimizer,
> int starts,
>
>> Yes, we can start with a bare implementation and add the bells and
>> whistles afterwards. In this case, they could also be integrated to the
>> other optimization algorithms if something general enough is found.
>+1
As soon as Nikolaus review is finished I will prepare the patch. Unit tests
>>
>> And an iterative algorithm that implements "HandlerSetter" will call
>> "update" after each iteration.
>Yes, this is the way user can monitor what he wants. Perhaps with a few
>set of more specialized handlers, the signature of the update method
>could be adapted for the algorithm type (i
>There is something loosely similar to what you need in the ODE packages.
>This kind of algorithms also need some information to be provided back to
>users during the algorithm run. For ODE solvers, it is at the end of each
>integration step.
>We have set this with a StepHandler interface. If t
>I really don't think that a general progress listener framework implies this
>clutter and for long running algorithms is a very nice thing. CM does not
>actually have all that many long running algorithms.
>On the other hand, the proposed interface is not a general progress listener
>and is n
>The problem is that we would again be re-inventing some wheel which IMHO
doesn't belong to a low-level math library such as CM.
>A basic logging interface already exists: It's "slf4j".
slf4j and the interface I had in mind are completely different things. slf4j
is a generic logging interface mea
10 matches
Mail list logo
