Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 45164 invoked from network); 10 Dec 2009 12:35:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Dec 2009 12:35:40 -0000 Received: (qmail 50963 invoked by uid 500); 10 Dec 2009 12:35:39 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 50837 invoked by uid 500); 10 Dec 2009 12:35:39 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 50827 invoked by uid 99); 10 Dec 2009 12:35:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 12:35:39 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of phil.steitz@gmail.com designates 209.85.221.177 as permitted sender) Received: from [209.85.221.177] (HELO mail-qy0-f177.google.com) (209.85.221.177) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 10 Dec 2009 12:35:29 +0000 Received: by qyk7 with SMTP id 7so3322220qyk.10 for ; Thu, 10 Dec 2009 04:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=ztYTeMWzwO27MqQ5u4pU+ZFhZ13aQYal5W1hOBeWvTM=; b=BjABL4tWYlsXVaNMuFRW4JKg0IN3/2QR5zpH9VBWJAWOgCEvEL4Xn69WV43XUl3NkK wU+Tc1uy2+ys/Sr1r4WeXw0YuKN3oLpEQWgNdG3+QHSJuGMHxk+kOD2KCXqkcn1z/JIB 8qHxiDb7hRkjAERauzx4qQ99OnBeunz8m5qyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=V5xGMesDTRnhe3HzSTu7XsjUjAiEJpkoMlg98LBy5C1CdiTG8ua6DyK8O142S3CHi3 OuDFAyRGIjG/Tu4Gzy+rWcQaDt8dFlcsNqsO6rd7ttndq6WM+61dsoS/wQ+USCb++3tL GFuINfilPmls6fnOwLicBtNpEsO6SvcspfueU= Received: by 10.224.64.162 with SMTP id e34mr6430147qai.150.1260448508679; Thu, 10 Dec 2009 04:35:08 -0800 (PST) Received: from phil-steitzs-macbook-pro.local (c-76-99-90-47.hsd1.de.comcast.net [76.99.90.47]) by mx.google.com with ESMTPS id 22sm660148qyk.14.2009.12.10.04.35.07 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Dec 2009 04:35:07 -0800 (PST) Message-ID: <4B20EAFA.90108@gmail.com> Date: Thu, 10 Dec 2009 07:35:06 -0500 From: Phil Steitz User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Commons Developers List Subject: Re: [math] getting changes included into commons-math (was Re: Home for the colt fork) References: <61b5d9410912080518p68708d9fie8405ca274029947@mail.gmail.com> <61b5d9410912080619k76b70dd1uc04a9fb3492402f2@mail.gmail.com> <4B1FF0F4.1000505@free.fr> <61b5d9410912091109t40ff7b6cu6089c5dd0198990e@mail.gmail.com> <4b124c310912091158r7e4aef26u4fca47a585457df4@mail.gmail.com> <4B200C96.4060003@free.fr> In-Reply-To: <4B200C96.4060003@free.fr> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Luc Maisonobe wrote: > Jake Mannix a �crit : >> On Wed, Dec 9, 2009 at 11:09 AM, Benson Margulies wrote: >> >>> This is interesting. We have a raft of mathematically qualified >>> committers on Mahout, and this message asking for help on >>> commons-math, and a raft of code marooned at mahout that wants to be >>> in commons math. If I were one of those mathematically competant >>> individuals, I'd be off attaching a patch or three to a JIRA or two >>> >> The commons-math linear APIs have been described as effectively locked >> until 3.0, due to back-compat requirements. This means that any code >> contributed >> into c-math would live in a parallel (no pun intended) to the linear >> primitives which >> exist already in there. >> >> Adopting something like MTJ or Colt in Mahout turned out to be easier, >> because >> we are on release 0.2 (heading for 0.3 now), and have less stringent >> back-compat >> requirements, so we are overhauling our linear apis (read: even user-facing >> interface changes) to take advantage of useful parts of Colt, and are >> planning on >> using our Colt fork as the underlying implementation. >> >> Commons-math expressed that changing linear APIs is not something they can >> do, >> given the maturity of their library, so where would Colt *go* in c-math? >> It's own >> submodule, having its own eigendecompositions and svd and so forth, running >> parallel to the current c-math impls? Why? >> >> Who would maintain it and write tests for it, and how do you explain to >> end-users which they should use? >> >> >> >>> On Wed, Dec 9, 2009 at 1:48 PM, Luc Maisonobe >>> wrote: >>>> Ted Dunning a �crit : >>>>> Actually, the reason that we have Colt in Mahout is it has proven >>> impossible >>>>> to get changes into commons math. We really, really wanted to use >>> commons >>>>> math rather than have our own linear algebra package, but it just proved >>>>> impossible and we didn't want to wait forever. >>>> If you really, really wants to use commons math and want changes to be >>>> included, contribute them. >> I have submitted patches for the following tickets: MATH-312 (and acceptance >> of that patch blocks my patch for MATH-314), MATH-316 and MATH-317, none >> of which have appear to have had much progress on. All of my patches come >> with unit tests for new functionality. > > I had these patches in my backlog and considered them accepted. I should > have commited them before, sorry for that. I'll take care of them right now. > >> On the other hand, when I opened the discussion about extending the >> functions >> package to enable composable functions (MATH-313), I got an entirely hostile >> response, which only tempered as far as "+0" on adding it after discussion. > > The discussion was not entirely hostile as we get some intermediate > consensus at some points. I understand your feelings after several > patches that did not get committed fast enough. > > Please accept my apologizes for this. I have to apologize as well here for lack of cycles to help get [math] patches in recently. That should improve shortly. Phil > > Luc > >> In particular, my first step at making commons-math something Mahout could >> standardize on for linear work was MATH-312, which I did submit a patch for, >> and revised it many times after discussion about what is acceptable practice >> in c-math. Not yet applied, months later. It's probably far out of date >> now... >> >> Similarly, when I tried to ask what the status on decisions on whether to >> adopt >> MTJ or Colt, the statement by Phil was basically that commons-math would not >> adopt anything which had any external dependencies or >> not-easily-human-readable java source (which ruled out MTJ because of f2j >> produced code), and which had to be fully tested and maintained prior to >> adoption (which rules out Colt which has no unit tests yet). >> >> Ted and I weren't making "requests" for other people to do work, we were >> wondering whether even offers to do some of the work would be accepted, >> and for many of the questions/suggestions we had, it seems the desires >> and requirements of the Mahout community were incompatible with those >> of commons-math. >> >> -jake >> >> >>> > I think the only change that was proposed and not done because of lack >>>> of consensus was the inclusion of MTJ (and I don't consider the >>>> discussion closed on that topic either, so it may still happen some >>>> day). All the other changes that are desired are simply lacking someone >>>> to do the work. There were proposals to extend the linear algebra API, >>>> proposals to add more support for sparse matrices, proposals to get >>>> partial decomposition ... But sparse contributions (pun intended). >>>> >>>> I try to do what I can, but as you have probably seen have been rather >>>> silent since 2.0 release. For my part, I really, really need help. I >>>> would like to fix the problems in the eigen decomposition and SVD but >>>> need a good kick to get on it, and having only requests and no help is >>>> not really motivating. >>>> >>>> Luc >>>> >>>>> If that problem were solved, then it would be great to depend on commons >>>>> math. If that problem isn't solved, then there is no way to depend on >>>>> commons math. >>>>> >>>>> On Tue, Dec 8, 2009 at 6:19 AM, Benson Margulies >>> wrote: >>>>>> We can't possibly have a dependency on Mahout in the long term. Either >>>>>> we all go shares on code in some other piece of commons, or we end up >>>>>> with two forks, which would be sad. >>>>>> >>>>>> On Tue, Dec 8, 2009 at 8:33 AM, James Carman < >>> james@carmanconsulting.com> >>>>>> wrote: >>>>>>> I wouldn't like to see a dependency on mahout code in a "commons" >>>>>>> library. That seems kind of backwards. If Mahout wants to offload >>>>>>> this stuff, we can move it into a library in commons (which is >>>>>>> typically how stuff used to happen in Jakarta). >>>>>>> >>>>>>> On Tue, Dec 8, 2009 at 8:18 AM, Benson Margulies < >>> bimargulies@gmail.com> >>>>>> wrote: >>>>>>>> Mahout now has a fork of a portion of the 'category A' portion of the >>>>>>>> CERN colt library forked. The Mahout fork is, of course, in the >>> Mahout >>>>>>>> tree under a Mahout Java package and Maven triple. >>>>>>>> >>>>>>>> I want to use the collections classes from Mahout as the core to a >>> new >>>>>>>> set of commons-primitives classes that do the useful things that GNU >>>>>>>> Trove does. >>>>>>>> >>>>>>>> The classes I want to start from depend on the classes that are in >>> the >>>>>>>> Mahout fork. >>>>>>>> >>>>>>>> As a temporary expedient, I can depend on their there. However, I >>>>>>>> submit that it would be more better if the mathematical code were in >>>>>>>> commons-math. Was this option explored? >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>> >>>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>> For additional commands, e-mail: dev-help@commons.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org