Hi Gary. Le sam. 22 juin 2019 à 16:04, Gary Gregory <garydgreg...@gmail.com> a écrit : > > My two bits: > - What is the license of the third party artifact under consideration?
https://github.com/lessthanoptimal/ejml states (bottom of page) ASL v2.0 > - Shading introduces more problems than it is worth and forces bloating. I've no experience with shading but my assumption was that only the code being actually used was copied (?). > Use a normal Maven dependency I'm quite surprised by this suggestion of yours since it would mean that users of "Commons Statistics" could be thrown into JAR hell. Do you agree that it could happen, but don't care (anymore!), or do I miss something? Regards, Gilles > > Gary > > On Sat, Jun 22, 2019 at 9:56 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Hello. > > > > [I've changed the subject line to reflect that we are discussing > > something at the the project's policy level (not just [Statistics]).] > > > > Le sam. 22 juin 2019 à 05:16, Ben Nguyen <bennguye...@gmail.com> a écrit : > > > > > > Hi, > > > The CM regression module uses LU & QR decomposition and basic matrix > > operations like multiply, add/subtract, transpose, inverse, as well as > > functionalities like getting a submatrix, getting dimensions etc…. All of > > which EJML provides as far as I’ve looked. > > > > That's fine that EJML is a suitable candidate; however it would be nice > > to record somewhere why it is currently the best choice. [It could just be > > a recommendation from people who've used been using it rather than the > > contenders, but it should be formally agreed on for *some* reason.] > > > > However, the main issue is whether we add explicit runtime dependency > > to EJML's artefact. IIUC, the consequences are: > > * Requirement to support it for as long as we don't change major version. > > * Risk of JAR hell. > > > > Alternative is: > > * Create custom interface(s) for linear algebra (to be currently > > implemented > > by an *internal* wrapper around the EJML functionalities). > > * Use the shade plugin so that the dependency is compile-time only. > > > > Comments, preferences, other suggestions? > > > > Thanks, > > Gilles > > > > > But I also expect there to be perhaps large differences in the port due > > to Streams…. > > > > > > Cheers, > > > -Ben > > > > > > From: Gilles Sadowski > > > Sent: Friday, June 21, 2019 8:18 PM > > > To: Commons Developers List > > > Subject: Re: [GSoC][Commons][STATISTICS][Regression][Matrix] Separate > > modulefor StatisticsMatrix (simple extension of EJML's SimpleBase) in > > commonsstatistics? > > > > > > Hi. > > > > > > Le ven. 21 juin 2019 à 14:38, Ben Nguyen <bennguye...@gmail.com> a > > écrit : > > > > > > > > Hello, > > > > > > > > Mr. Gilles Sadowski suggested to me on Slack that StatisticsMatrix and > > future extensions of EJML’s code should go into it’s own component. > > > > > > Not exactly; I suggested that > > > 1. there be an interface defined in [Statistics] for matrix that would > > > shield its API > > > from a future change of its implementation. [Now it can be a subclass of > > EJML, > > > but what if we want to change later? Do we want to support an external > > API > > > even when it's not used to perform the computations?] > > > 2. utilities (like the matrix interface) that can be used by several > > modules > > > of [Statistics] are best defined in a separate (maven) module. > > > > > > > So based on my understanding; should there be a general matrix module > > to use inside of commons statistics which uses the EJML? > > > > > > Which matrix functionalities are needed for the "regression" module? > > > > > > > Does anyone think another statistics component (besides regression) > > will need matrices and it’s operations? > > > > > > You could get the answer by looking at the [Math] codes. > > > > > > Regards, > > > Gilles > > > > > > > > > > > Thank you for your input, > > > > Cheers, > > > > -Ben Nguyen > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
