commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")
Date Mon, 03 Dec 2012 13:16:06 GMT
On Sat, Dec 01, 2012 at 04:58:30PM -0500, Konstantin Berlin wrote:
> > 
> > I would propose to simply revert my changes on the optimization package 
> > and prepare for a reorganization for 4.0. I understand I focused only on
> > the type of problems Gilles and myself routinely use, i .e. small size problems

> > where the cost of the evaluation is several orders of magnitude larger than the
> > data copying. I forgot the dual case with  very large data sets. I apologize for
> > 
> > When 3.1 will be out, we will have to solve this so both  cases are handled efficiently,

> > and this would probably be implemented in 4.0.
> > 
> > Does this seems reasonable? 
> > 
> > Best regards 
> > Luc
> > 
> Don't blame yourself, its hard to think of all possible uses.

Indeed. And it is also hard to get a design right without being guided by
actual use-cases.
Thus... [see below]

> I think reverting back to original interface is the best choice for 3.1.

I don't understand (cf. my other post); in the "orignal" interface (i.e.
"DifferentiableMultivariateVectorFunction"), you have exactly the same
problem as with what Luc proposed earlier: 2 separate functions, one for
the value and one for the Jacobian.
Please indicate whether my proposal is better from this point-of-view: One
function call will return an array of "value and gradient" objects, and
references to those can be accessed directly inside the optimizer's code
to get the Jacobian data, without copying.

> In the future it is worth finding and adding "standard" industry benchmarks to the tests.

... this issue came up several times, but was not able to gather the
necessary "human-power": see

> Speaking of optimizers... Would it not be better to move all the getRMS, getChiSquared
> the return class, along with all other information, like how many iterations it took,
> evaluations, etc? That is how I find it more natural to use, so I end up creating a wrapper.
> These properties are not properties of the optimizer but are properties of the specific
> optimization evaluation of the function with the specific initial value.

As always, patches are welcome that practically demonstrate the improvement.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message