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.
Although
* 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
provides
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_
to
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]
Regards,
Gilles
[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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
