Glad to see the addition of new-sparse-array to core.matrix. It looks like it defaults to SparseRowMatrix for the Vectorz implementation? Should the API provide a way to specify which sparse matrix representation (e.g., row- vs column-based, indexed vs hashed) should be used? I'd suggest a 3-arity new-sparse-array which takes a keyword indicating the representation to use as well as a new function which returns a list of available representations for a specific implementation.I think at this point you incorporated (looks like we have some duplication too, doh) all the changes I had made for sparse matrix support in Vectorz, but will verify.
On Dec 28, 2014, at 7:28 PM, Mike Anderson <mike.r.an...@gmail.com> wrote:Interesting idea. The challenge is that I'm not sure how to add representation specification in an implementation independent way. It's a quirk of vectorz that it has both indexed and hashed storage, I probably wouldn't expect any other implementations to have that. Likewise row and column oriented storage are fairly obvious choices but I still wouldn't expect every implementation to support both.Any idea how you would specify the API?I guess we could simply pass an optional map argument of options, but behaviour would be completely implementation specific.
On Monday, 29 December 2014 02:12:05 UTC+8, Matt Revelle wrote:Glad to see the addition of new-sparse-array to core.matrix. It looks like it defaults to SparseRowMatrix for the Vectorz implementation? Should the API provide a way to specify which sparse matrix representation (e.g., row- vs column-based, indexed vs hashed) should be used? I'd suggest a 3-arity new-sparse-array which takes a keyword indicating the representation to use as well as a new function which returns a list of available representations for a specific implementation.I think at this point you incorporated (looks like we have some duplication too, doh) all the changes I had made for sparse matrix support in Vectorz, but will verify.I definitely haven't covered all the potential code paths - in particular a lot of things aren't yet optimised for sparse operations. So any review / patches would be appreciated!
--
You received this message because you are subscribed to a topic in the Google Groups "Numerical Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/numerical-clojure/LLpq4WHx-k8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to numerical-cloj...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and all its topics, send an email to numerical-clojure+unsubscribe@googlegroups.com.
To unsubscribe from this group and all its topics, send an email to numerical-cloj...@googlegroups.com.