On 7/20/13 6:45 AM, Ajo Fod wrote: > Phil, > > I feel that you are blocking/delaying the use of improper integration to > commons users with your objection that you don't understand all the > alternatives. > > If you want to pose what I and the community see as a respectable objection > to including a commit, it needs to be in the form of : > 1. alternative code that demonstrates a superior way of doing improper > integration. With unit tests that show how it is faster or more accurate. > 2. OR failures of the the submitted patch in a JUnit test.
Sorry, this is not how it works. It is up to *you* the contributor who wants us to commit something to convince the community that what you are proposing is a good, supportable, standard way to solve whatever problem you are trying to solve. As Gilles and others have pointed out, we can't just commit whatever apparently functional code comes our way. The reasons for this should be obvious when you think about the problems associated with maintaining it and what happens to users when we release functional but numerically unsound code. Lets just say we have been burned a few times in the past and leave it at that. Also, I am not "blocking" anything. I am just asserting that I personally am not going to advocate for or myself commit code that I "don't understand." Phil > > Otherwise, I maintain that the hurdle of convincing you of the > correctness/optimality of a solution is way too high for anyone's good ... > including yours. > > Once the "ability to do improper integration" is in CM, you can always > mend/improve the patch. Its not like you've never integrated a class or > moved it around c.f MATH-827. > > Cheers, > -Ajo > > > > On Fri, Jul 19, 2013 at 2:55 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> On 7/19/13 2:36 PM, Konstantin Berlin wrote: >>> The question is how correctly to do AQ and how to correctly handle >>> >>>> improper integrals. What I would appreciate is some real numerical >>>> analysis or pointers to where we can do the research to support what >>>> Ajo is asking us to commit. Just running tests on one problem >>>> instance demonstrates nothing. I asked politely several times and >>>> got no response. >>>> >>> Page 170 of numerical recipes third edition. >>> >>> "The basic trick for improper integrals is to make a change of variables >> to >>> eliminate the singularity or to map an infinite range of integration to a >>> finite one." >>> >>> See also >>> >> http://www.gnu.org/software/gsl/manual/html_node/QAGI-adaptive-integration-on-infinite-intervals.html#QAGI-adaptive-integration-on-infinite-intervals >>> I hope this can convince people.. >> Thanks! This is not really numerical analysis, but it is a start >> and an indication that there are at least some standard >> implementations that work this way. What would be helpful is some >> general references that provide complexity and error analysis and >> ideally characterize the functions for which the change of variable >> approach is better than Gauss-Hermite, per the first recommendation >> in [1] >> >> [1] http://en.wikipedia.org/wiki/Numerical_integration >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
