Dawid, These are Colt data types. If we expose the internal storage for DenseMatrix (the undeprecated Mahout version), would that suffice for your needs?
The long term plan is to migrate all important functionality to the non-Colt forms. Moving sooner rather than later is to be encouraged. On Thu, Feb 3, 2011 at 9:45 AM, Dawid Weiss <[email protected]>wrote: > I see one problem that is currently a showstopper for us: > DenseDoubleMatrix2D has been flagged as final and its internal field > "elements" is package-private. We have a custom subclass of > DenseDoubleMatrix2D that previously could access elements array to do > some native calculations using BLAS, if possible. As it is right now, > it's not possible to subclass DenseDoubleMatrix2D or access its > internal "dense" data representation. Even more, if you tried to write > a dense implementation from scratch, it is still problematic because > of methods like: > > public DoubleMatrix1D zMult(DoubleMatrix1D y, DoubleMatrix1D z, double > alpha, double beta, boolean transposeA) { > > which, in their "dense" incarnation, access package-private elements > data from DenseDoubleMatrix1D (after casting), so you'd end up copying > a lot of code just to be able to derive something that uses dense > representation and is functional... > > I know this may be a violation of encapsulation principles, but we > would find it very useful if internal representation of dense data > structures could be accessed directly. Much like in HPPC's case, this > very often turns out to be very useful in practice. > > Back at you now :) > Dawid > > On Thu, Feb 3, 2011 at 6:09 PM, Ted Dunning <[email protected]> wrote: > > Definitely possible, but I also think that we all knew that we would > > eventually cut to the bone. > > I don't even think that this means that we should stop cutting. We > should > > figure out a way to let the carrot folk know when it is happening. > > > > On Thu, Feb 3, 2011 at 5:33 AM, Sean Owen <[email protected]> wrote: > >> > >> There's always the chance we all decide that a given bit of > >> functionality is far enough afield from Mahout that it should just live > in > >> Carrot2. > > >
