> > [...] > > > > So I agree with Phil that it would be nice to retrieve the "best" estimate > > of the solution, even if crash occurs. But I also agree with Gilles that > > this must be done carefully. All the iterative solvers implemented so far > > are almost state-less. The only class variables are related to the stopping > > criterion. No data relating to the current system being inverted is stored > > as a class variable (and is therefore not accessible). Again, event > > handlers might be the way to go, we could add an event which is fired prior > > to throwing the failure exception. > > I think that a "framework" is indeed the flexible way but this is a lot of > refactoring and not easy to get right as current attempts have shown. > My preference is still to allow extensive logging in CM, as this helps with > the presented uses-cases without getting in the way at all, and it's trivial > to add. > > I'll try and to see the implications of just adding a "getCurrentBest()" > method to the optimizers API.
Would it be OK to record one evaluated point per iteration? [That seems to be a relatively non-intrusive change, but the value could either be "null" or be worse than the starting point.] Ensuring that the current best will always be returned entails changes that will obscure the code: every call to "computeObjectiveValue" must be enclosed in try/catch, catching the exception, setting the "current best" then rethrowing. I still have the strong impression that it's working around the current design (which is based on the user's knowing how to choose "good" input values and exceptions indicating that it didn't work out.) Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
