Martin Cooper wrote:
<snip/>
Not that much duplication exists. What we are *deciding* now is how much and how to pull it in. The options are as I described earlier in the thread:
0) snippets / classes as needed 1) jar dependency 2) full merge
I am -0 on 2) without support from the JAMA developers or other volunteers. The code base is not huge but some of the algorithms are nontrivial.
Wouldn't (0) be just a subset of (2), and thus lead to the same potential maintenance issues, albeit on a smaller scale?
Yes, but potentially significantly smaller. To be specific, what I was intitially planning to bring in was code from one class that does QR decomposition, to be used in a multiple regression implementation (one of the "commonly-used, practical applications" things on the [math] wisth list). I would take the responsibility - gladly accepting help from the other [math] contributors - for fully documenting the incorporated code and including enough test cases so that "we" could effectively maintain and support it. I am balking at committing to do that for the whole code base.
That being the case, it would seem to me that (1) might make the most sense, so that each group ([math] and JAMA) can focus on its own code and not have to worry too much about the other, other than where they come together.
Could be you are right. That's why I included that option. Its downsides are
a) sort of goes against [math]'s "minimal dependencies" goal; and
b) some of what we may want to do may require inline work or changes to the API
Neither of these is a show-stopper and this is certainly the easiest way to go. Thanks for the feedback.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
