commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Cleaning up the curve fitters
Date Sat, 20 Jul 2013 21:28:17 GMT
On Sat, 20 Jul 2013 06:45:10 -0700, Ajo Fod wrote:
> [...]
> 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.
> 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.

I admire your insistance. :-)
So, I'll try once more to get "my" point through.

A good library must avoid code duplication.
  * change of variables,
  * improper integrals,
  * adaptive algorithms
are all useful features for use in numerical estimation of integrals, I
think that CM must not include a code like your patch, because it 
all of them bundled in a way that
  1. does not reuse the existing code, and
  2. does not allow to be reused (within CM or by CM users).

I stated that much from the outset; and that we could work _together_ 
fulfill this requirement (and others along the way).

> 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.

Who is "you"?
That's the problem.

Had you taken the route which I suggested, most roadblocks would have
disappeared "automagically".[1]


[1] Phil's too, probably, because code reuse places a big part of the
     burden (e.g. of numerical analysis in this instance) on the reused
     building blocks!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message