Hi scala-breeze,
I tried abstracting some of my code to use both sparse and dense matrices. I did it by just using the Matrix class instead of DenseMatrix. I was surprised and dismayed to find out that a lot of the basic functionality is missing for Matrix—slicing along rows and columns, or even multiplying the transpose of a matrix by a vector. In the former case, just wrote a typeclass implementation for Matrix[V], but I had to require V: Zero (understandably) and do runtime type tests (ew). It's a hack. It struck me that maybe the reason this wasn't already part of the Matrix API is that it would then cause DenseMatrix to also require V: Zero for slicing, because it would have to do dynamic dispatch on a method that required V: Zero and a different typeclass instance for DenseMatrix without that requirement might lead to ambiguous implicit resolution. (Not totally sure on that one, but implicit resolution for stuff like that is... well, I try to stay away from thinking too much about True Scala Complexity.)
In hindsight I think my mistake was early on when I chose to use the Matrix class. Abstraction should've been by typeclass, and after looking at VectorSpace.scala I realize that there are behemoths like MutableOptimizationSpace that might suit my purposes. Except logically I'm trying to do things with matrices like slicing individual columns or column ranges. I couldn't find that functionality in typeclasses except for the one-off UFunc style ones. And I'm not so sure if I want to import every single one...but maybe in combination with one of the big guys from breeze.math, it'd be well under control.
So I have a candidate solution, but I'm left wondering: what's the canonical way to do this? If Matrix shouldn't be used, perhaps it should be hidden outside of the package? Should I probably not be using Breeze for sparse matrices anyway? How's my candidate solution? At any rate, I might contribute implementations for CSCMatrix I need that aren't there. (If I end up needing more stuff.)
Thanks!
Julian