First of all, nice work :-)
In the docs you keep referring to core.matrix as though it was a particular implementation, saying things like "X times faster than core.matrix". This is misleading; core.matrix is an abstract API, which can have many implementations. Saying something is faster than it doesn't mean anything. In particular, it's misleading to compare "Neanderthal to core.matrix" by comparing it to Vectorz and jBlas, since faster implementations could be written and are underway. Perhaps something a little more verbose like "Neanderthal to the fastest (current?) core.matrix implementations" would be less misleading. On a stylistic note, I like the website design overall, but the graph paper lines on the back ground are a bit distracting in relation to the text. Perhaps a white background behind the text, with the graph lines on the margins would capture the same effect but be less distracting? At the risk of being a nag, I'd also like to reiterate the desire of the community to avoid library fragmentation and see Neanderthal implement the core.matrix protocols. Mike elegantly explicated the reasons for this in his earlier post: if we all build around a common abstract API, we maximize the Clojure dream of composability of anything written towards and for that API. This is important to a lot of Clojurians. Earlier in the thread you expressed concerns about whether it would really be so easy to have Neanderthal's as a core.matrix API. Mike Anderson's response to me suggests he thought you were questioning whether swapping core.matrix implementations was really so easy. Just in case you were doubtful of the former more so than the latter, perhaps I can clarify. Core.matrix is built entirely around abstract protocols which represent the various matrix operations one might care about for a matrix computation library. There are protocols for addition, inner product, outer product, multiply and add, invert, etc. All you would have to do to make Neanderthal functional as a core.matrix implementation is implement these protocols in some namespace within your project (perhaps ` uncomplicate.neanderthal.core-matrix`). As Mike pointed out, you wouldn't even have to implement _all_ the protocols, since core.matrix comes with default implementations of the things you don't define. Once you'd made the implementations, you register an example matrix object with core.matrix at the end of your namespace, and then when a user requires that namespace, the Neanderthal implementation would be registered, and users could start instantiating Neanderthal matrices that are 100% compatible with the core.matrix API. Setting things up this way, you wouldn't even have to abandon your own API. The two could live in harmony along side each other, letting folks require and use whichever they like. It really is just that simple; implement a few protocols, and the API will work. It sounds too good to be true, and I didn't believe it at first either, but it works. I get that you've put a lot of energy into this, and commend you for it. I personally would love to take advantage of that hard work, and am sure others would as well. However, I think you're going to find adoption difficult if Neanderthal risks fragmenting the presently coherent state of numerical computing in Clojure, and imposes inflexibilities upon those who would use it in their own code. I personally am not willing to boost performance at the cost of flexibility. OK; I'll leave it at that. Respectfully, Chris On Wed, Jun 17, 2015 at 8:07 AM, Dragan Djuric <draga...@gmail.com> wrote: > Version 0.2.0 has just been released to Clojars > > New features: > > * implemented BLAS support for floats > * implemented fmap!, freduce, and fold functions for all existing types of > matrices and vectors > > Changes: > > No API changes were required for these features. > > On Tuesday, January 13, 2015 at 2:13:13 AM UTC+1, Dragan Djuric wrote: >> >> I am pleased to announce a first public release of new *very fast *native >> matrix and linear algebra library for Clojure based on ATLAS BLAS. >> Extensive *documentation* is at http://neanderthal.uncomplicate.org >> See the benchmarks at >> http://neanderthal.uncomplicate.org/articles/benchmarks.html. >> >> Neanderthal is a Clojure library that >> >> Main project goals are: >> >> - Be as fast as native ATLAS even for linear operations, with no >> copying overhead. It is roughly 2x faster than jBLAS for large matrices, >> and tens of times faster for small ones. Also faster than core.matrix for >> small and large matrices! >> - Fit well into idiomatic Clojure - Clojure programmers should be >> able to use and understand Neanderthal like any regular Clojure library. >> - Fit well into numerical computing literature - programmers should >> be able to reuse existing widespread BLAS and LAPACK programming know-how >> and easily translate it to Clojure code. >> >> Implemented features >> >> - Data structures: double vector, double general dense matrix (GE); >> - BLAS Level 1, 2, and 3 routines; >> - Various Clojure vector and matrix functions (transpositions, >> submatrices etc.); >> - Fast map, reduce and fold implementations for the provided >> structures. >> >> On the TODO list >> >> - LAPACK routines; >> - Banded, symmetric, triangular, and sparse matrices; >> - Support for complex numbers; >> - Support for single-precision floats. >> >> >> Call for help: >> Everything you need for Linux is in Clojars. If you know your way around >> gcc on OS X, or around gcc and MinGW on Windows, and you are willing to >> help providing the binary builds for those (or other) systems, please >> contact me. There is an automatic build script, but gcc, atlas and other >> build tools need to be properly set up on those systems. >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/dFPOOw8pSGI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
