> his code, so I can't comment about it specifically. >> > > There was no outright rejection. >
... only painful fillibustering with objections that were tangential to the CM user experience. > > My strong impression is that the source of the problem is the > misconception that Commons Math is repository of all sorts of > mathematical routines, and that the only requirement is that a > patch submitted by a would-be contributor should be outright > accepted as soon as it solves something for someone. > Improving performance on the specific issue of a UnivariateFunction integrated in the unit interval [-1,1] doesn't fall under "all sorts of mathematical routines". If it did what is The following well known (even to you) words describe the shortfall of "IterativeGaussLegendreIntegrator" that AQ fixes. Any guess who this deep thought was from? "the _limitation_ of "IterativeGaussLegendreIntegrator" is that it does not analyze where the error comes from; it just keeps on dividing the whole range, piling up numerical errors in the region where few points are needed (and where the contribution to the integral is ever more insignificant the larger sigma becomes)." > > Indeed: > 1. The proposal for implementing improper integrals was welcome. > 2. The proposal for implementing additional adaptive algorithms > was welcome. > Only superficially welcome ... when you add up the effort that goes into convincing you guys of the merits of the patch ... after it has passed a test suite. > > If he wanted to contribute to Commons Math (and not just "throw > a patch over the wall", as Phil put it), Ajo could have started > from there, and actually work out the details of how to best > integrate the new features into the existing code. Just as you > did. > Conversely, if you don't want to "just throw a patch back at me", I expect test cases that fail or concrete steps towards accepting the patch. Not something like lets go see if something else works. Cheers, Ajo.
