Have we tried asking if he wants to be a part of commons? Seems like that library could be a good fit and it might help him out in the long run.
-Rob > On Jun 22, 2019, at 1:37 PM, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le sam. 22 juin 2019 à 19:19, Alex Herbert <alex.d.herb...@gmail.com > <mailto:alex.d.herb...@gmail.com>> a écrit : >> >> >> >>> On 22 Jun 2019, at 15:28, Gilles Sadowski <gillese...@gmail.com> wrote: >>> >>> Hi Gary. >>> >>> Le sam. 22 juin 2019 à 16:04, Gary Gregory <garydgreg...@gmail.com >>> <mailto:garydgreg...@gmail.com>> a écrit : >>>> >>>> My two bits: >>>> - What is the license of the third party artifact under consideration? >>> >>> https://github.com/lessthanoptimal/ejml >>> <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? >> >> I use EJML v0.24. The reason I am still on that version and not the current >> version of 0.38 is due to a change in the API to rename the matrix classes. >> They did provide an upgrade script to update to 0.31 which was when the >> rename occurred [1] (I’ve not tried an upgrade). This occurred without a >> major version change so the policy on version numbers is unclear. Including >> a Maven dependency to something with big API changes in its timeline would >> be a jar problem for someone. > > Perhaps they consider that anything is allowed in versions 0.x (?). > [I've asked the same for new "Commons" components, but IIRC, > there is still no definite answer.] > > In any case, as you point out, if [Statistics] explicitly depends on > EJML, all bets are off: Even if they don't change API, they could > modify implementation details so that applications could have different > behaviours, depending on which version is ultimately loaded by the > JVM (as per "JAR hell"). > > I was pretty sure that it would have been a "no-no" for a "Commons" > release. But now I'm confused. :-} > > Gilles > >> [1] https://github.com/lessthanoptimal/ejml/blob/master/convert_to_ejml31.py >> <https://github.com/lessthanoptimal/ejml/blob/master/convert_to_ejml31.py> >>> >>> 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 >>> <mailto:dev-unsubscr...@commons.apache.org> >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> <mailto:dev-h...@commons.apache.org> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
