API design for matrix library?

Question

Java

I've been developing a small Java library for working on linear algebra problems for quite some time, and I've often had to make decisions about the design of the public API. Up to this point everything was going great. But recently there was one thing that haunts me. I would like to know the opinion of the community on how to proceed in such a situation.
What is the point. There are sparse matrices that mostly store zeros and only a few significant elements. Now I'm on the verge of choosing whether to add the toArray(). On the one hand, the user should be able to (convert a matrix into a two-dimensional array). On the other hand, this operation directly contradicts the whole ideology of sparse matrices - reducing the memory used.
Another side of the coin - I decided to separate the family of dense and sparse matrices at the interface level. And now I cannot think of a single method that would be typical for dense ones but not applicable to sparse ones. The method toArray()is very suitable for this role, while the method cardinality()- the number of non-null elements - is a clear contender for the sparse API.
Summarizing. There is a need to come up with a characteristic method for a dense matrix. There is a candidate - the lowest hanging fruit - toArray(). The perfectionist in me says toArray()everyone should have it. A lazy person and a crutch programmer - only among the dense ones.
I really ask the community for advice on what to do with the ill-fated method.

Answer 1

Immediately: I did not look at the code.
However, by concept, I personally would not take out toArray () in a common interface, because. I can hardly imagine where it would be necessary to convert a sparse matrix into an ordinary one. It's better to look at scenarios where such a conversion seems logical, and put operations in the interface that force you to put toArray() in a generic interface. For sparse operations, this operation is, by definition, expensive, and, IMHO, this does not make much sense in real problems.

Answer 2

It seems to me that the method toArray()should be implemented in both types of matrices. If there is a Matrix interface, then it must have a toArray(). Already in a specific implementation of a sparse matrix, you can add a method that represents the matrix in a more compact form.
The specificity of a sparse matrix should be at the implementation level, for example, the use of more optimal algorithms when multiplying, etc. It's like LinkedList and ArrayList. The methods are the same in them, the user himself decides for what he will use the list and chooses the implementation. Seems like it should be the same in your case.

Answer 3

Something I didn’t see in the la4j API such obvious, in my opinion, things as iterators (or functors). To process the elements of a matrix row by row or by column, for example. If it's needed at all, of course.
Here, the enumeration for sparse matrices could look somewhat different than for dense ones. In order not to go through each element of a sparse matrix, one could have a special iterator that would skip zero elements. And for a sparse matrix, it would be possible to use a simpler iterator - not skipping elements, “dense”. It would be easier to work with him.
Both types of iterators can be implemented for both types of matrices, but it is clear that a "dense" iterator is inefficient when applied to sparse matrices.
The purpose of the API is not only to enable, but also to encourage the choice of the right solutions. And using a “dense” iterator for sparse matrices is a wrong decision, so it could not be added to the sparse matrix interface at all.

Answer 4

There are sparse matrices that mostly store zeros and only a few significant elements. <...> On the other hand, this operation directly contradicts the whole ideology of sparse matrices - reducing the memory used.

toArray() in this case can be understood as serialization, so if you return an array filled with solid values ​​(including 0), nothing unnatural will happen. It is clear that the user will store and perform operations on the optimal structure.
Separating matrices at the interface level, if you can't think of really meaningful differences, might be wrong. Think back to the List interface and the LinkedList and ArrayList implementations. It would be strange to separate them at the interface level.