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 that. > > > > 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 https://issues.apache.org/jira/browse/MATH-678 and https://issues.apache.org/jira/browse/MATH-763 > > Speaking of optimizers... Would it not be better to move all the getRMS, > getChiSquared into > the return class, along with all other information, like how many iterations > it took, function > 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. Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
