On 07/18/2013 10:48 PM, Ajo Fod wrote: > Hello folks, > > There is a lot of work in API design. However, Konstantin's point is that > it takes a lot of effort to convince Gilles of any alternatives. API design > issues should really be second to functionality. This idea seems to be lost > in conversations. > > I agree with Gilles that providing tests and benchmarks that exhibit the > advantages of a particular method are probably the best way to show other > contributors the value of an alternative approach. > > It is quite depressing to the contributor to see one's contribution be > rejected when efficiency/accuracy improvements are demonstrated. In a > better world, rejecting a patch that passes the hurdle of demonstrating an > efficiency improvement over existing code should come with a responsibility > of showing alternate tests that the patch fails and the original code > passes. Otherwise, the patch should be accepted by default. The person who > commits or designed the API is free to make changes to fit API design. > > Just like API designers are not experts at the underlying math, > contributors are not necessarily experts at the underlying API design. To > unlock the efficiency of open source, contributor morale needs to be > considered and classes that pass tests should really be accepted. > > For example, Performance AND accuracy improvements to existing algorithm > were demonstrated for AdaptiveQuadrature in my patches to MATH-995 > The only joy I got out of that was Gilles putting a comment in the docs for > the existing class: > "The Javadoc now draws attention that the [existing] algorithm is not 100% > fool-proof."! > Also, I was asked to open a new issue about Adaptive Quadratures to figure > out what is the best quadratue method ... all while a patch that is a clear > improvement over existing code wastes away. Why not accept the patch and > make improvements as necessary? > > My impression since that patch was rejected, is that it just seems like a > huge hurdle to get any patch past the API design requirements that are > frankly not as clear to me as it is to the designer. I can see how others > feel the same way. > > Cheers, > Ajo. > > Gilles: if you don't want to end up spending time developing Gauss-Hermite > quadrature or something else you don't really need, perhaps you should > consider accepting/modifying code that was shown to work by someone who > needed that functionality. It is reasonable to develop alternatives to fix > flaws/gaps, but otherwise its your effort wasted. If someone's > contribution doesn't fit your view of the API, then by all means edit the > patch, but if you go about rejecting things that work, there won't be as > many contributors to CM.
Hi, I am certainly not happy with the current API of the optimization package but am looking forward to the suggested improvements from Luc and how they can be applied to this package. Otoh, I do not think it is fair to blame Gilles for doing a good job on analyzing the root cause of reported problems and suggesting / implementing changes that are generally applicable instead of doing problem-specific fixes, which would just lead to an unmaintainable mess (and I have some experience with that ...). Following the discussions on this topic for a while, the bottom line is mainly: you (= Commons Math) are doing it wrong. I have not seen a proposal or draft on doing it better in a clean, maintainable way, and this is the goal of this library afaik. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
