> Well, no they wouldn't. > > They would often need to write something like > > dense.times(unknown)
An actual code excerpt would help me understand what you think is or isn't or should be possible with CM. If "dense" and "unknown" are vectors, then in "ArrayRealVector", "dotProduct" uses a "sparseIterator" but "ebeMutliply" does not. Also (and this is the issue reported in the link I was referring to in the previous post), the "sparseIterator" is used for any vector that is not an instance of "ArrayRealVector", which will be less efficient if the vector is actually dense. This is the same kind of problem you referred to with user's implementations, but in reverse (dense implementations are penalized). > They know that their own object is dense, but they don't know what kind of > input they were given. They should still run fast if the input is sparse. Couldn't we still rely on polymorphism by implementing "preTimes": unknown.preTimes(dense) ? Gilles > > > And it really helps for a dense matrix to optimize operations against a > > > sparse operand as in dense.plus(sparse). > > > > Applications that manipulate sparse things would know the limitations of > > polymorphism and would write > > sparse.plus(dense) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
