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.
>
