Dragan, I still support you doing whatever you want with your time, and I'm grateful that you've produced was I gather is a great library. Wonderful. I don't feel that you have to implement the core.matrix api--but I really, really wish someone would produce a core.matrix interface to Neanderthal. (I don't know how difficult that will be; I just know that I'm not the right person to do it.)
Some of the following has been said before, but some the points below seem to have been lost in the current discussion. I want to try Neanderthal, but I may never do so until someone produces a core.matrix mapping. That needn't be a problem for you, Dragan, but my time is too precious to reimplement my existing code for a new api. Even with new code, I'm always going to prefer core.matrix in the foreseeable future unless I have very special needs, because being able to swap out implementations is just too convenient for me. core.matrix allows me to easily figure out which library is most efficient in my application. I also want there to be a standard api for matrix operations, and at this point, core.matrix is the standard imo. I came to Clojure from Common Lisp, where there are 5-10 matrix libraries with different APIs and different efficiency profiles, several seemingly best for different purposes (the Curse of Lisp mentioned by Mikera, applied to our case). I am just very grateful that, instead of CL's mess of libraries and APIs, in the Clojure world Mikera and others decided to construct a standard API for matrix implementations. What he's promoting is not marketing, nor religion--it's just convenience and coherence. It's part of what Clojure is all about. Again, Dragan, I certainly don't think that you have to support core.matrix, and I am still grateful for Neanderthal even no one ever gives it a core.matrix front end. From my point of view, everyone in the Clojure community can be grateful for Neanderthal--even those of us who might never end up using it. It's a good resource for those who know in advance that it will be best for their application, or for those with time to benchmark their application with variant code. I personally don't want to negotiate different matrix APIs, however. That's what's important to me. I don't have any opinion about the relative benefits of the core.matrix and Neanderthal APIs as such. I just want to write to standard API. If the Neanderthal API became the standard, with multiple back ends, and was overall better than core.matrix in that respect, I'd use it. At this point, going that route seems unlikely to be a good option, because core.matrix already exists, with a lot of work having gone into it by a reasonably large community. For me the API seems just fine, and it's still being enhanced. (If it can be made better through conversation with you or others familiar with Neanderthal, that's even better.) So ... I understand why Mikera keeps mentioning core.matrix whenever Neanderthal is promoted here. I support him doing that, because I want the matrix libraries for Clojure to stay away from the curse of Common Lisp. I also understand why core.matrix isn't important for you, personally. But core.matrix is important for others besides Mikera. It's not just a pet project; it's a Good Thing, because well thought out common APIs for libraries with similar functionality is a Good Thing. I think you probably agree, at least *in the abstract,* even if in this particular context you don't think that core.matrix is the best API for all matrix applications. (Maybe it's not. Still ... a common API, that's gotta be a good thing. And if someone ever does produce a core.matrix interface to Neanderthal, the regular Neanderthal interface will still be available, presumably. Great! Best of both worlds.) I don't think this discussion has to get as heated as it does. Perhaps I'll get some of the heat, now, but it's not necessary, imo. -- 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.