For better or worse, and as has been evidenced by the state of our use (or trial) of several different matrix/collections libs at this point already, I'm kind of liking controlling or own destiny when it comes to something so core to our performance (not that I couldn't be talked out of it, I don't believe in "Not Invented Here" for the most part).
That being said, Dawid, maybe you'd consider reverting your Emeritus status and working here to build out the library that serves both of our needs? Then there is no need for the extra layer of going somewhere else and being dependent on yet another third party w/ diff. release cycles etc. The only change for C2 would then be a dependency on Mahout Math (why does the thought of Elephants counting always come to mind when I say that?) Of course, maybe that isn't ideal for C2. I don't feel strongly about this, though. We have plenty of other deps. as it is and it seems there is a fair need for this between both projects. Food for thought, Grant On Jan 12, 2010, at 9:56 AM, Benson Margulies wrote: > Dawid, > > Like I said, I'm not sure we're disagreeing. My focal goal is > primitive collections, and I'm prepared to take my lumps with > compatibility. Sun has made such a mess of the collections API that we > seem forced to choose. > > --benson > > > On Tue, Jan 12, 2010 at 9:28 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: >> Thanks for the clarification and understanding of my motives, Benson. >> >> I know Trove and I know other libraries of this type -- PCJ has been >> our favorite so far, but it's LGPL and our persistent attempts to ask >> Soren Bak to distribute that code under a different license have >> failed. >> >> Adapters are a way to work around the compatibility problems (they are >> used in PCJ, for example), but they're in many ways defeat the purpose >> of having a collections library based on primitives. Other than lower >> memory consumption in the static case, you gain very little >> (autoboxing will kill performance). >> >> Let me do this. I'll send you a ZIP file with the code as it is right >> now in our repository. Take a look at what we've done and compare it >> to your efforts (especially in terms of templates-code generation I >> think you'll find it interesting). I should be done with the >> implementation of Deque today or tomorrow and then, knowing what other >> people think, we can decide how to move forward. >> >> Dawid >> >> On Tue, Jan 12, 2010 at 1:34 PM, Benson Margulies <bimargul...@gmail.com> >> wrote: >>> Dawid, >>> >>> I find that I didn't quite answer all of your questions, and then >>> again maybe I'm not in a position to. >>> >>> I started this by looking for some way to get the functionality of >>> Trove without the GPL. When I discovered that Mahout had already >>> absorbed Colt, I decided that the shortest path was to start from >>> there. >>> >>> I looked into planting this in commons-collections, but it was not so >>> easy. Colt collections depend on some scalar math code (random >>> numbers, etc). The commons-math people have a very high bar for >>> contributions, and the process of factoring out the math substrate, >>> comparing it to commons math, identifying the delta, contributing it >>> to math, etc, etc, was beyond my personal resources. >>> >>> If you've got a foundation member at hand, collections will make you a >>> sandbox to facilitate the contribution. Much as I'm enjoying myself at >>> this, I certainly won't be offended if Mahout throws it all out in >>> favor of what you've got there. >>> >>> One issue for Mahout is that it is using some above-collections >>> functionality from Colt that will take very careful modification to >>> use your (or any other) alternative. >>> >>> --benson >>> >> -------------------------- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem using Solr/Lucene: http://www.lucidimagination.com/search
