I also think the core.matrix crusade is unnecessary.  Here are my two cents:

1. No one jumps in every time someone writes a new web routing library 
saying "No!  You'll fragment the clojure
    web routing community!  Use compojure!"  I think we should pick and 
choose based on our needs.
2. We should build on well-tested, stable APIs, true.  Dragan has built on 
top of BLAS (basically stable for over
    35 years) and LAPACK (25-35 years depending on how you count).
3. Dragan has no need or desire to implement the core.matrix API, but I'm 
sure someone that wants native speed
    *and* compatibility with core.matrix will do so when the need arises.
4. If you want accessibility to the widest possible community of numerical 
programmers, bear in mind that most
    of them aren't clojure or even java programmers anyway.  BLAS and 
LAPACK are the way to make them feel
    at home.  Pure-java numerical programming is a rather strange 
cul-de-sac community already.
5. Numerical programming is a field where you, unfortunately, have to drop 
layers of abstraction more
    frequently than other fields.  I'd rather drop down into ATLAS than 
<<insert random java backend with its own
    matrix class here>>.

In short, having two libraries that do the same thing is not a problem, and 
if it becomes a problem, I think we as a community can deal with it fairly 
quickly.

--Leif

On Sunday, March 13, 2016 at 8:19:25 PM UTC-4, Dragan Djuric wrote:
>
> On Monday, March 14, 2016 at 12:28:24 AM UTC+1, Mikera wrote:
>
>> It would be great if Neanderthal simply implemented the core.matrix 
>> protocols, then people could use it as a core.matrix implementation for 
>> situations where it makes sense. I really think it is an architectural 
>> dead-end for Neanderthal to develop a separate API. You'll simply get less 
>> users for Neanderthal and fragment the Clojure library ecosystem which 
>> doesn't help anyone.
>>
>
> Mike, I explained that many times in detail what's wrong with core.matrix, 
> and I think it is a bit funny that you jump in every time Neanderthal is 
> mentioned with the same dreams about core.matrix, without even trying 
> Neanderthal, or discussing the issues that I raised. Every time your answer 
> is that core.matrix is fine for *YOUR* use cases. That's fine with me and I 
> support your choice, but core.matrix fell short for *MY* use cases, and 
> after detailed inspection I decided it was unsalvageable. If I thought I 
> could improve it, it would have been easier for me to do that than to spend 
> my time fiddling with JNI and GPU minutes.
>
> I understand your emotions about core.matrix, and I empathize with you. I 
> support your contributions to Clojure open-source space, and am glad if 
> core.matrix is a fine solution for a number of people. Please also 
> understand that it is not a solution to every problem, and that it can also 
> be an obstacle, when it fells short in a challenge.
>  
>
>> In the absence of that, we'll just need to develop separate BLAS 
>> implementations for core.matrix. 
>>
>
> I support you. If you do a good job, I might even learn something now and 
> improve Neanderthal.
>  
>
>> Would be great if you could implement the core.matrix protocols and solve 
>> this issue. It really isn't much work, I'd even be happy to do it myself if 
>> Neanderthal worked on Windows (last time I tried it doesn't).
>>
>
> I am happy that it is not much work, since it will be easy for you or 
> someone else to implement it ;) Contrary to what you said on slack, I am 
> *not against it*. I said that many times. Go for it. The only thing that I 
> said is that *I* do not have time for that nor I have any use of 
> core.matrix.
>
> Regarding Windows - Neanderthal works on Windows. I know this because a 
> student of mine compiled it (he's experimenting with an alternative GPU 
> backend for Neanderthal and prefers to work on Windows). As I explained to 
> you in the issue that you raised on GitHub last year, You have to install 
> ATLAS on your machine, and Neanderthal has nothing un-Windowsy in its code. 
> There is nothing Neanderthal specific there, it is all about comiling 
> ATLAS. Follow any ATLAS or Nympu + ATLAS or R + ATLAS guide for 
> instructions. Many people did that installation, so I doubt it'd be a real 
> obstacle for you.
>
>  
>
>> On Sunday, 13 March 2016 23:34:23 UTC+8, Dragan Djuric wrote:
>>>
>>> I am soon going to release a new version of Neanderthal.
>>>
>>> I reinstalled ATLAS, so I decided to also update benchmarks with 
>>> threaded ATLAS bindings.
>>>
>>> The results are still the same for doubles on one core: 10x faster than 
>>> Vectorz and 2x faster than JBlas.
>>>
>>> The page now covers some more cases: multicore ATLAS (on my 4-core 
>>> i7-4790k) and floats. Neanderthal is 60 times faster with multi-threaded 
>>> ATLAS and floats than Vectorz (core.matrix).
>>>
>>> For the rest of the results, please follow the link. This will work with 
>>> older versions of Neanderthal.
>>>
>>>
>>> https://www.reddit.com/r/Clojure/comments/4a8o9n/new_matrix_multiplication_benchmarks_neanderthal/
>>> http://neanderthal.uncomplicate.org/articles/benchmarks.html
>>>
>>

-- 
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.

Reply via email to