subject:"\[ANN\] Neanderthal, a fast, native matrix and linear algebra library for Clojure released \+ call for help"

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-10-25 Thread Dragan Djuric

WRT their documentation, I do not think it means much for me now, since I do 
not need that library and its functionality. So I guess the integration depends 
on whether
1) it is technically viable
2) someone needs it

I will support whomever wants to take on that task, but have no time and need 
to do it myself.

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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-10-23 Thread Dragan Djuric

Neanderthal 0.4.0 has just been released with OpenCL-based GPU support and 
pluggable engines.

http://neanderthal.uncomplicate.org

On Tuesday, June 23, 2015 at 12:39:40 AM UTC+2, Dragan Djuric wrote:
>
> As it is a *sparse matrix*, C++ library unavailable on JVM, I don't 
> consider it relevant for comparison as these are really apples and 
> pineapples. For now, at least.
>
> On Tue, Jun 23, 2015 at 12:13 AM, A <> wrote:
>
>>
>> Here's another benchmark for comparison: 
>> https://code.google.com/p/redsvd/wiki/English
>>
>> -A
>>
>>
>>
>> On Monday, June 22, 2015 at 12:27:57 PM UTC-7, Dragan Djuric wrote:
>>>
>>> core.matrix claims that it is fast on its project page (with which I 
>>> agree in some cases). I expected from that, and from the last couple of 
>>> your posts in this discussion, that there are some concrete numbers to 
>>> show, which I can't find.
>>>
>>> My claim to win "ALL benchmarks" (excluding maybe tiny objects) came 
>>> only as a response to mike's remarks that I have only proven that 
>>> neanderthal is faster for dgemm etc.
>>>
>>> OK, maybe the point is that other libraries do not care that much about 
>>> speed, or that current speed is enough, or whatever, and I am ok with that. 
>>> I would just like it to be explicitly said, so I do not lose time arguing 
>>> about what is not important. Or it would be nice to see some numbers shown 
>>> to draw at least rough picture of what can be expected. I am glad if my 
>>> raising this issue would improve the situation, but I do not insist...
>>>
>>> On Monday, June 22, 2015 at 9:16:15 PM UTC+2, Christopher Small wrote:

 Well, we also weren't claiming to win "ALL benchmarks" compared to 
 anything :-)

 But your point is well taken, better benchmarking should be pretty 
 valuable to the community moving forward.

 Chris


 On Mon, Jun 22, 2015 at 12:10 PM, Dragan Djuric  
 wrote:

> So, there are exactly two measurements there: matrix multiplication 
> and vector addition for dimension 100 (which is quite small and should 
> favor vectorz). Here are the results on my machine:
>
> Matrix multiplications are given at the neanderthal web site at 
> http://neanderthal.uncomplicate.org/articles/benchmarks.html in much 
> more details than that, so I won't repeat that here.
>
> Vector addition according to criterium: 124ns vectorz vs 78ns 
> neanderthal on my i7 4790k
>
> Mind you that the project you pointed uses rather old library 
> versions. I updated them to the latest versions. Also, the code does not 
> run for both old and new versions properly (it complains about :clatrix) 
> so 
> I had to evaluate it manually in the repl.
>
> I wonder why you complained that I didn't show more benchmark data 
> about my claims when I had shown much more (and relevant) data than it is 
> available for core.matrix, but I would use the opportunity to appeal to 
> core.matrix community to improve that.
>
> On Monday, June 22, 2015 at 8:13:29 PM UTC+2, Christopher Small wrote:
>>
>> For benchmarking, there's this: 
>> https://github.com/mikera/core.matrix.benchmark. It's pretty simple 
>> though. It would be nice to see something more robust and composable, 
>> and 
>> with nicer output options. I'll put a little bit of time into that now, 
>> but 
>> again, a bit busy to do as much as I'd like here :-)
>>
>> Chris
>>
>>
>> On Mon, Jun 22, 2015 at 9:14 AM, Dragan Djuric  
>> wrote:
>>
>>>
 As for performance benchmarks, I have to echo Mike that it seemed 
 strange to me that you were claiming you were faster on ALL benchmarks 
 when 
 I'd only seen data on one. Would you mind sharing your full 
 benchmarking 
 analyses?

>>>
>>> I think this might be a very important issue, and I am glad that you 
>>> raised it. Has anyone shared any core.matrix (or, to be precise, 
>>> core.matrix) benchmark data? I know about Java benchmark code project 
>>> that 
>>> include vectorz, but I think it would help core.matrix users to see the 
>>> actual numbers. One main thing vectorz (and core.matrix) is claiming is 
>>> that it is *fast*. Mike seemed a bit (pleasantly) surprised when I 
>>> shared 
>>> my results for vectorz mmul... 
>>>
>>> So, my proposal would be that you (or anyone else able and willing) 
>>> create a simple Clojure project that simply lists typical core.matrix 
>>> use 
>>> cases, or just the core procedures in core.matrix code that you want to 
>>> measure and that you are interested to see Neanderthal doing. Ready 
>>> criterium infrastructure is cool, but I'm not even ask for that if you 
>>> do 
>>> not have time. Just a setup with matrix objects and core.matrix

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-10-23 Thread Gregg Reynolds

I'm glad to see that you and Mike are making a productive dialog out of
what could have gone the other way.  It's a credit to you both.

Simple question wrt documentation.  The Great White Whale of open source
software.  Suppose core.matrix had insanely great documentation.   What
difference would that make regarding your decision to support it or not?
(IOW, if the community were to manage to make good docs, would you change
your mind? )
On Jun 22, 2015 8:34 AM, "Dragan Djuric"  wrote:

> Just a quick addition, if it is still not clear what I mean regarding the
> documentation. Look at this fairly recent question on stack overflow:
>
> http://stackoverflow.com/questions/19982466/matrix-multiplication-in-core-matrix
>
> 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 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.
>

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

Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help

2015-06-22 Thread Christopher Small

Just a couple of comments:

As I was typing, Mars0i's message came in, with much of much what I wanted
to say about documentation, but I'll reiterate a couple of key points: You
can have an intuitive API that's poorly documented, just as it's possible
to have a terrible API with great documentation (though certainly it's
_easier_ to document a nice, clean API...). Those two things are relatively
orthogonal. Your comments about documentation came in response to a line of
thought about shortcomings of the core.matrix API, but bad documentation is
not actually a shortcoming of the API proper. And not building around
core.matrix because the API is bad is different than not building around it
because the API is poorly documented (though both understandable),
particularly when the latter is relatively easy to fix (even after the
fact).

However, I have to personally disagree about the state of the
documentation. I think it's actually pretty decent. For example, on the
GitHub page (README) there is a link to a wiki page for implementers that I
think is fairly straight forward. If you go to the protocols namespace (as
suggested in the implementers wiki page), the protocols which _must_ be
implemented are well demarcated, and most of the protocols have pretty good
documentation. There is certainly room for improvement though. The example
of * vs mmul mentioned could have been avoided had
https://github.com/mikera/core.matrix/blob/master/src/main/clojure/clojure/core/matrix/examples.clj
(linked to from the README) more clearly denoted what * does, and added
mmul as well (since I think that's what folks would use more frequently
anyway...). There's probably also room for more thorough/robust high-level
descriptions of key concepts. But I think overall the documentation is far
from _bad_. That's just my opinion though; if other people are having
trouble with the docs, there may be more room for improvement than I
realize.

Dragan, you point out that in the Clojure community there are dozens of
Clojure libraries for SQL, http, visualization, etc, and all have their
place. That's certainly true, but you're comparing kittens to koalas here.
Matrices/arrays are *data types*, while the things you mention are
libraries that do things with already standardized data types. Something
common to every single Clojure SQL library out there is that it's likely
going to return a seq of vectors or maps; in either case, these are the
data types around which vast swaths of the Clojure code out there has
already been built. So there's less need for standardization here. The
situation around matrix/array programming is very different; here you have
tightly coupled abstract data types and functionality/operations, and there
is a lot that could be built up around them and which benefits from a
standardization. I've talked with folks at some of the big(gish) Clojure
companies doing ML, and they love core.matrix for this very reason.

A perfect example of something similar is graphs; graphs are data types
which are tightly coupled with a number of operations, and loom is a
project which has been around for a while to try and unify an API around
these data types and operations. When Mark Engelberg realized that loom
didn't fit all his needs (which had to do with more robust/general graph
types and operations; much more extensive than just beefing up performance
on a subset of the functionality...), he didn't go and create his own
thing. Well... he did... but he did it in such a way that his constructions
also implemented the loom protocols, so what you wrote would still be
relatively interoperable with loom code. This is a great example because
even though his approach is much more general and I think should/could be
*THE* graph api, he still was able to make things as compatible as he
possibly could. This is the beauty of Clojure at it's greatest.

As for complex matrices, there's already a project underway for this, with
a rather elegant approach that would allow for any underlying
implementation to be used: https://github.com/mikera/core.matrix.complex.
Of course, a native implementation that supported complex types would be
lovely, and could potentially be a lot faster than doing things this way,
but it's not true that there's no complex story.

As for performance benchmarks, I have to echo Mike that it seemed strange
to me that you were claiming you were faster on ALL benchmarks when I'd
only seen data on one. Would you mind sharing your full benchmarking
analyses?

With all that out of the way... I'm glad that you're willing to play ball
here with the core.matrix community, and thank you for what I think has
been a very productive discussion. I think we all went from talking _past_
each other, to understanding what the issues are and can now hopefully
start moving forward and making things happen. While I think we'd all love
to have you (Dragan) personally working on the core.matrix implementations,
I agree with Mars0i that just

40 matches

Mail list logo