commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ajo Fod <ajo....@gmail.com>
Subject Re: [Math] Cleaning up the curve fitters
Date Sat, 20 Jul 2013 17:57:45 GMT
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.steitz@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.steitz@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.steitz@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message