Hi. > >"BOBYQAOptimizer" is a horrible Java code (e.g. it contains lots of > >"simili-goto" statements).[2] > >In a library, the source codes should share coding standards. Consequently, > >if a code is not following the standard, it should not be part of the > >library. We simply should not have included it. > >It is not, and cannot be, maintained; it is just there. You could as well > >copy/paste it to your personal toolbox. > > Although I understand your concern about the (un)maintainability of > "BOBYQAOptimizer" as a CM contributor/maintainer, I fully share Patrick's > point of view as a user! Unless CM is a toy for the own pleasure of its > contributors, it should not make the life of its users miserable every time > some CM officionados have yet another great idea about how to 'improve' > the design/implementation of an algorithm already in place, especially if > the adopted design results essentially from a philosophical orientation.
Actually the issue is: When providing a library, the maintainers implicitly commit to be able to... maintain it. It follows logically that unmaintainable code should not be forced on benevolent contributors. Indeed, as a user, I don't care if the "BOBYQAOptimizer" class is unmaintainable; as a developer, I don't want to justify in lengthy emails, every now and then, that users should not use it if they encounter problems (be they wrong usage or a bug, because we cannot sort it out anyways). > Following the discussions on the dev ML, I see that some components which > were to be deprecated are now restored, ... Such a rather unstable API > is really bad from a user point of view. Given the low number of contributors, CM is gathering new functionalities at an impressive rate. Given the low number of contributors, that makes a lot of code to maintain per regular contributor. If the design is not improved where it can be, the project will slowly but surely turn to cruft. Unfortunately not many people seem to be aware or care about this risk. > As Patrick wrote, we do not want > to waste hours or days catching up with the deprecations (especially as we > have to figure out the refactoring ourselves). But contributors can waste their time trying to understand an obscure code when someone raises an issue about it? > We do want to use CM as a > reliable library but if something works, do not touch it! When contributors make changes, it is hopefully to improve in one way or another. > That is for instance the case with the weights in the least squares methods. > Those vectorial weights have been very useful in the present API, do not > touch them. That API does not prevent a tiny subset of users to cope with > correlated observations while it helps a lot of users coping with simple > weights. For the latter, there is even a good reason not to premultiply > the observations and model functions: the 'residuals' would be multiplied > as well otherwise. The weight feature is an example where it seems that the design can be improved towards greater clarity (simplified core algorithm) and efficiency (no multiplications by 1 in cases where the weights are not used). But if the consensus (just a few posts ago that weights have no part in the least-squares minimization algorithms) is reverted, that's fine with me; and I'll remove that task from the issue tracking system... But, if so, why should we remove the new feature that would allow to handle correlated observations, as well as uncorrelated ones (as a sub-case of the former)? Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
