On Wed, Aug 17, 2011 at 4:44 AM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote:
> > It would be very nice if the implementor of this matrix could extend an > > abstract matrix and over-ride get() to generate a value and set() to > throw > > an unsupported operation exception. > > Do you mean that the matrix is stateless (each call to "get" generates a > new > value)? > Yes. And I would also typically expect it to be immutable although changing p is a reasonable thing to do (I just prefer immutable objects where practical). > > > If p < 0.1, then the matrix should be > > marked as sparse, else as dense. > > > > All operations against other matrices, sparse or dense should work well > > without any special handling by the implementor of this matrix. > > > > This works in Mahout for instance by having the default operations in > > AbstractMatrix test for sparseness of left or right operands and do the > > right thing. Obviously, a type test will not tell you whether this > matrix > > is sparse or not. > > As far as I understand, the sparseness test is an indicator that there is > an > optimized way to iterate over the entries (faster than a loop over all the > indices) or that not all entries are explicitly stored. Is that correct? > Yes. > If so, this is tied to the layout of the matrix, i.e. the type (which > can change depending on an input value, such as "p" above). > Yes. > However, once it is created, its type/implementation is either dense or > sparse. > It depends on whether setP() is supported. If the setter is there, then density can even change after construction. > > > [...] > > I'm wondering whether this leads again to the issue of CM being a framework > for everyone to build on, or if its data structures are mostly intended for > internal use, so that the algorithms it provides are most efficient. Well, it *is* open source (so they say). That kind of indicates that it should be relatively easy for people to provide code. Also, I find that even the idea of this dichotomy is a bit of a mirage. Providing a good extensible design often gives faster code down the way a bit.