Yeah, I think this is inline with the error I was seeing: attempting to extend
a final class.
On Feb 3, 2011, at 12:45 PM, Dawid Weiss 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.
>>
--------------------------
Grant Ingersoll
http://www.lucidimagination.com
