[...] I have class that has to solve different NLLS problems
concurrently. The problems share the same convergence criteria, but
use
different model functions. With the current implementation that
means I
need one optimizer per thread.
How bad is that, actually? That is what I am not getting. Why do
you need a thread-safe facade when all you are doing is creating new
instances per thread? Sorry if I am missing something simple here.
[...]
How bad is it to use a library though wrapper classes? Well it is
annoying to have to design my own optimization API that delegates to
the
C-M implementations.
Sorry, I can't really comment on this without seeing some code.
I can agree that improvements can arise from modifying things at the
CM level but I need to see actual examples to be able to go forward.
From the posts on the users list I think other
people were confused by the old API and probably developed their own
wrappers to insulate themselves from it.
I gave the reasons on the API's evolution...
When I saw the optimization
package was being redesigned in an backward incompatible way, I
thought
it was an opportunity to address a range of concerns that are easiest
to
address early in the design process. Luc's original fluent +
immutable
proposal would have allowed thread safety.
No I don't think so; at least not as such. [Because some fields are
shallow
(reference) copies of the input.]
(If not initially, it could
be implemented through patches with no change to the API.) The
separation of algorithm and data would allow each to be much simpler
while still allowing for thread safety and a fluent API.
Even if the "algorithm data" is stored in a separate object, that is
still
not a guarantee that the combination "optimizer + data" is thread-safe
(same
as above but now in the "data" object).
(I.e. GN would
not need 5 superclasses and fields for storing upper and lower
bounds.)
Be careful: "GaussNewtonOptimizer" does _not_ support bounds!
With the API re-design you have the opportunity to design for thread
safety, which can be hard to add on to an existing API.
True in general, but in this case we didn't make a thorough analysis
of advantages and drawbacks of creating a new instance for each
application of a "withXxx" method.
I previously hinted that such a behaviour might not be desirable,
independently of the issue of thread-safety.
Thanks for the whole discussion; It has given me some new ideas. :)
You are most welcome to experiment with the current revision of the
code in "o.a.c.m.fitting.leastsquares", in order to pinpoint problems
for your use-cases.
You could also provide the concrete changes (patch) needed to move the
"data" to another object, as you suggested.
If it's better design and leads to simpler code, there shouldn't be
any problem in applying it for the next release.
Thanks,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
