commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Fluent API, inheritance and immutability
Date Tue, 13 Aug 2013 12:17:58 GMT
>>> [...] 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 
(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 
not a guarantee that the combination "optimizer + data" is thread-safe 
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.


>>>  [...]

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

View raw message