Without AQ, you have the achilles heel with high frequency functions that Gilles acknowledged in his comments. So, how do you propose to do AQ with Gauss-Hermite?
I guess I don't know what you mean by "numerical analysis". Cheers, Ajo. On Sat, Jul 20, 2013 at 9:38 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > 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 > >
