Ok let's approach this one step at a time starting with improper integration because tests for AQ depend on it.
What are the modifications to the class Infinite in Math-995 that are: 1: necessary 2: desirable for acceptance to commons? what bits of code can be reused from existing ones in commons? Mind you all the code does is map an arbitrary function in the range [-Inf, Inf] to [-1,1] Cheers, Ajo On Sat, Jul 20, 2013 at 2:28 PM, Gilles <gil...@harfang.homelinux.org>wrote: > 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-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
