Colt did a nice job of this. Basically, their idea was to take various general functional patterns and allow the functions to be plugged in.
Common patterns that are reasonable to include in such a framework include: a) dot product as the aggregration of a pairwise function application (normal dot product is this with aggregation = + and pairwise function = *) b) element-wise transformation of all elements of a matrix or vector c) aggregation of an elementwise transformation of a vector or matrix (sum, frobenius norm, euclidean squared distance are examples of this) c) row-wise or column-wise transformation of a matrix resulting in a list of objects d) row-wise or column-wise aggregation of a matrix resulting in a vector (row sum or column sum is a good example here) e) row-wise or column-wise aggregated outer products (normal matrix multiplication is an example where the product is dot and aggregation is +) Combining these operations with various view operators such as transpose, sub-matrix and diagonal allow various other interesting operators to be implemented. Trace, for example, becomes m.diagonal().aggregate(Functions.plus). The result is a very powerful API that has enormous expressivity. It is also, unfortunately, essentially opaque to most users so lots of short-cut and convenience functions are important. On Thu, Oct 1, 2009 at 10:53 AM, Jake Mannix <jake.man...@gmail.com> wrote: > Of course, to do this right in Mahout, we'd probably need to have some way > of > telling the Vector instance what to use for its norm (so it knows whether > to > > cache it's L^2 norm, L^p norm, or some other inner product applied to > itself). > > Which gets me thinking: maybe we should have an InnerProduct interface, > similar to DistanceMeasure, which defined how to compute dot(). As it is, > we basically assume in our API that while you may want norm(int p) for > various p, and you may want different DistanceMeasure impls of various > types, we say that dot() is always the Euclidean dot(). > > Should that be pluggable as well? > -- Ted Dunning, CTO DeepDyve
