On 7/20/13 8:54 AM, Ajo Fod wrote: > 1. Konstantin just showed with a link that other packages use the change of > variables method. > > 2 The theoretical argument for the change of variables method is documented > on Wikipedia. It is such a standard way that it is on wikipedia. I did > another search on google. Here is another wikipedia link: > http://en.wikipedia.org/wiki/Integration_by_substitution > > 3. I've shown that my method provides correct answers in many cases. If you > suspect it doesn't work for other cases ... show me those cases. Obviously, > there is a pole at infinity in this scheme. Unless you try to evaluate the > original function at infinity, you'll be fine. > > If you are saying that you can't advocate for it because you dont' > understand the method. I guess CM will have to wait for someone who does > understand the concept of change of variables to make the commit
Sorry, this is going nowhere. There is zero real numerical analysis support in the arguments you have provided. Trust me, I know what change of variable is. I also know the basics of quadrature. The Wikipedia article mentions Gauss-Hermite first and I suspect that is for a reason. You need to either do some real research or let this drop. Konstantin started. You need to do the work or let this drop. Phil > > Cheers, > Ajo. > > On Sat, Jul 20, 2013 at 7:25 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
