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

[Dragan Djuric]

On Monday, June 22, 2015 at 2:02:19 AM UTC+2, Mikera wrote:
>
>
> There is nothing fundamentally wrong with BLAS/LAPACK, it just isn't 
> suitable as a general purpose array programming API. See my comments 
> further below.
>

I was discussing it from the *matrix API* perspective. My comments follow:
 

> If you think the core.matrix API is "unintuitive and complicated" then I'd 
> love to hear specific examples. We're still open to changing things before 
> we hit 1.0
>

I will only give a couple basic ones, but I think they draw a bigger 
picture. Let's say I am a Clojure programmer with no huge experience in 
numerical computing. I do have some knowledge about linear algebra and have 
a textbook or a paper with an algorithm that I need, which is based on some 
linear algebra operations. I'd say that this is the most common use case 
for an API such as core.matrix, and I hope you agree. After trying to write 
my own loops and recursion and fail to do it well, I shop around and find 
core.matrix with its cool proposal: a lot of numerical stuff in Clojure, 
with pluggable implementations. Yahooo! My problem is almost solved. Go to 
the main work right away:

1. I add it to my project and try the + example from the github page. It 
works.
2. Now I start implementing my algorithm. How to add-and-multiply a few 
matrices? THERE IS NO API DOC. I have to google and find 
https://github.com/mikera/core.matrix/wiki/Vectors-vs.-matrices so I guess 
it's mmul, but there is a lot of talk of some loosely related 
implementation details. Column matrixes, slices, ndarrays... What? A lot of 
implementation dependent info, almost no info on what I need (API).
3. I read the mailing list and the source code, and, if I manage to filter 
API information from a lot of implementation discussion I manage to draw a 
rough sketch of what I need (API).
4. I implement my algorithm with the default implementation (vectorz) and 
it works. I measure the performance, and as soon as the data size becomes a 
little more serious, it's too slow. No problem - pluggable implementations 
are here. Surely that Clatrix thing must be blazingly fast, it's native. I 
switch the implementations in no time, and get even poorer performance. 
WHAT?
5. I try to find help on the mailing list. I was using the implementation 
in a wrong way. WHY? It was all right with vectorz! Well, we didn't quite 
implemented it fully. A lot of functions are fallback. The implementation 
is not suitable for that particular call... Seriously? It's featured on the 
front page!
6. But, what is the right way to use it? I want to learn. THERE IS NO INFO. 
But, look at this, you can treat a Clojure vector as a quaternion and 
multiply it with a JSON hash-map, which is treated as a matrix of 
characters (OK, I am exaggerating, but not that much :)
etc, etc... 

But it certainly isn't "arbitrarily invented". Please note that we have 
> collectively considered a *lot* of previous work in the development of 
> core.matrix. People involved in the design have had experience with BLAS, 
> Fortran, NumPy, R, APL, numerous Java libraries, GPU acceleration, low 
> level assembly coding etc. We'd welcome your contributions too but I 
> hope you will first take the time to read the mailing list history etc. and 
> gain an appreciation for the design decisions.
>

I read lots of those discussions before. I may or may not agree with the 
written fully or partially, but I see that the result is far from what I 
find recommended in numerical computing literature that I read, and I do 
not see the core.matrix implementations show that literature wrong. 

 
>
>>
>> In my opinion, the best way to create a standard API is to grow it from 
>> successful implementations, instead of writing it first, and then 
>> shoehorning the implementations to fit it.
>>
>
> It is (comparatively) easy to write an API for a specific implementation 
> that supports a few specific operations and/or meets a specific use case. 
> The original Clatrix is an example of one such library.
>

Can you point me to some of the implementations where switching the 
implementation of an algorithm from vectorz to clatrix shows performance 
boost?
And, easy? Surely then the Clatrix implementation would be fully 
implemented and properly supported (and documented) after 2-3 years since 
it was included?
 

> But that soon falls apart when you realise that the API+implementation 
> doesn't meet  broader requirements, so you quickly get fragmentation e.g.
> - someone else creates a pure-JVM API for those who can't use native code 
> (e.g. vectorz-clj)
>

So, what is wrong with that? There are dozens of Clojure libraries for SQL, 
http, visualization, etc, and all have their place.
 

> - someone else produces a similar library with a new API that wins on some 
> benchmarks (e.g. Neanderthal)
>

I get your point, but would just note that Neanderthal wins *ALL* benchmark 
(that fit use cases that I need). Not because it is som

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

[Mikera]

Hi Dragan,

The situation as I see it:
- You've created a matrix library that performs well on one benchmark 
(dense matrix multiplication). 
- Neanderthal meets your own personal use cases. Great job!
- Neanderthal *doesn't* fit the use cases of many others (e.g. some need a 
portable pure JVM implementation, so Neanderthal is immediately out)
- Fortunately, in the Clojure world we have a unique way for such libraries 
to interoperate smoothly with a common API (core.matrix)
- Neanderthal could fit nicely in this ecosystem (possibly it could even 
replace Clatrix, which as you note hasn't really been maintained for a 
while...)
- For some strange reason, it *appears to me* that you don't want to 
collaborate. If I perceive wrongly, then I apologise.

If you want to work together with the rest of the community, that's great. 
I'm personally happy to help you make Neanderthal into a great matrix 
implementation that works well with core.matrix. I'm 100% sure that is an 
relatively simple and achievable goal, having done it already with 
vectorz-clj 

If on the other hand your intention is to go your own way and build 
something that is totally independent and incompatible, that is of course 
your right but I think that's a really bad idea and would be detrimental to 
the community as a whole. Fragmentation is a likely result. At worst, 
you'll be stuck maintaining a library with virtually no users (the Clojure 
community is fairly small anyway... and it is pretty lonely to be a 
minority within a minority)

I can see from your comments below that you still don't understand 
core.matrix. I'd be happy to help clarify if you are seriously interested 
in being part of the ecosystem. Ultimately I think you have some talent, 
you have obviously put in a decent amount of work and Neanderthal could be 
a great library *if and only if* it works well with the rest of the 
ecosystem and you are personally willing to collaborate. 

Your call.

On Monday, 22 June 2015 10:05:15 UTC+1, Dragan Djuric wrote:
>
>
>
> On Monday, June 22, 2015 at 2:02:19 AM UTC+2, Mikera wrote:
>>
>>
>> There is nothing fundamentally wrong with BLAS/LAPACK, it just isn't 
>> suitable as a general purpose array programming API. See my comments 
>> further below.
>>
>
> I was discussing it from the *matrix API* perspective. My comments follow:
>  
>
>> If you think the core.matrix API is "unintuitive and complicated" then 
>> I'd love to hear specific examples. We're still open to changing things 
>> before we hit 1.0
>>
>
> I will only give a couple basic ones, but I think they draw a bigger 
> picture. Let's say I am a Clojure programmer with no huge experience in 
> numerical computing. I do have some knowledge about linear algebra and have 
> a textbook or a paper with an algorithm that I need, which is based on some 
> linear algebra operations. I'd say that this is the most common use case 
> for an API such as core.matrix, and I hope you agree. After trying to write 
> my own loops and recursion and fail to do it well, I shop around and find 
> core.matrix with its cool proposal: a lot of numerical stuff in Clojure, 
> with pluggable implementations. Yahooo! My problem is almost solved. Go to 
> the main work right away:
>
> 1. I add it to my project and try the + example from the github page. It 
> works.
> 2. Now I start implementing my algorithm. How to add-and-multiply a few 
> matrices? THERE IS NO API DOC. I have to google and find 
> https://github.com/mikera/core.matrix/wiki/Vectors-vs.-matrices so I 
> guess it's mmul, but there is a lot of talk of some loosely related 
> implementation details. Column matrixes, slices, ndarrays... What? A lot of 
> implementation dependent info, almost no info on what I need (API).
> 3. I read the mailing list and the source code, and, if I manage to filter 
> API information from a lot of implementation discussion I manage to draw a 
> rough sketch of what I need (API).
> 4. I implement my algorithm with the default implementation (vectorz) and 
> it works. I measure the performance, and as soon as the data size becomes a 
> little more serious, it's too slow. No problem - pluggable implementations 
> are here. Surely that Clatrix thing must be blazingly fast, it's native. I 
> switch the implementations in no time, and get even poorer performance. 
> WHAT?
> 5. I try to find help on the mailing list. I was using the implementation 
> in a wrong way. WHY? It was all right with vectorz! Well, we didn't quite 
> implemented it fully. A lot of functions are fallback. The implementation 
> is not suitable for that particular call... Seriously? It's featured on the 
> front page!
> 6. But, what is the right way to use it? I want to learn. THERE IS NO 
> INFO. But, look at this, you can treat a Clojure vector as a quaternion and 
> multiply it with a JSON hash-map, which is treated as a matrix of 
> characters (OK, I am exaggerating, but not that much :)
> etc, etc... 
>  
>
But it certainly isn't "a

[ANN] ClojuTRE 2015 conference in Tampere, Finland

[Mikko Heikkilä]

Dear fellow Clojurians,

ClojuTRE 2015 will take place Friday, September 11th 2015, in Tampere, 
Finland.

ClojuTRE is a free Clojure conference organised by Metosin. The event has 
single track, late start, short talks and an awesome after party for 
networking, discussions and beer. We welcome both newbies and seasoned 
Clojurists. Current known facts can be found at http://clojutre.org 

Registration via Eventbrite is open at https://clojutre-2015.eventbrite.com/

Call for Speakers is also open and can be found at 
http://goo.gl/forms/hY1PXtUnm4

Last year was a blast, this one will be even moreso! Hope to see you in 
ClojuTRE 2015!

On behalf of the ClojuTRE team & Metosin,

# Mikko

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

[Dragan Djuric]

Hi Mike,

On Monday, June 22, 2015 at 1:56:46 PM UTC+2, Mikera wrote:
>
> Hi Dragan,
>
> The situation as I see it:
> - You've created a matrix library that performs well on one benchmark 
> (dense matrix multiplication).
>
 
It performs well on all benchmarks, even BLAS 1 vector stuff is faster than 
primitive arrays and vectorz for anything but the very small vectors. I 
just didn't publish all that benchmarks that I've been doing continuously 
because dgemm is what is most telling.
 

> - Neanderthal meets your own personal use cases. Great job!
> - Neanderthal *doesn't* fit the use cases of many others (e.g. some need a 
> portable pure JVM implementation, so Neanderthal is immediately out)
> - Fortunately, in the Clojure world we have a unique way for such 
> libraries to interoperate smoothly with a common API (core.matrix)
>

And I've already made it clear that I am happy about that. Please do 
continue to use what works for your needs.
 

> - Neanderthal could fit nicely in this ecosystem (possibly it could even 
> replace Clatrix, which as you note hasn't really been maintained for a 
> while...)
> - For some strange reason, it *appears to me* that you don't want to 
> collaborate. If I perceive wrongly, then I apologise.
>

I would like to collaborate. I would like to offer help to anyone who needs 
core.matrix integration and wants to build it and maintain it. I do not 
have time, resources, knowledge, and need to do that work myself. 
 

> If you want to work together with the rest of the community, that's great. 
> I'm personally happy to help you make Neanderthal into a great matrix 
> implementation that works well with core.matrix. I'm 100% sure that is an 
> relatively simple and achievable goal, having done it already with 
> vectorz-clj 
>

Thank you for the willingness to help me do that work, and I will 
definitely ask for it if/when I need to do that. I hope someone who might 
need that integration would step in and do the work, and we could both help 
him with that.
 

> If on the other hand your intention is to go your own way and build 
> something that is totally independent and incompatible, that is of course 
> your right but I think that's a really bad idea and would be detrimental to 
> the community as a whole. 
>

Sorry, but I fail to see how something that is open and free and solves the 
problems of some but not all potential users can be detrimental, but I 
respect your opinion.
 

> Fragmentation is a likely result. At worst, you'll be stuck maintaining a 
> library with virtually no users (the Clojure community is fairly small 
> anyway... and it is pretty lonely to be a minority within a minority)
>

What you see as fragmentation I see as open choice. Neanderthal can not 
have virtually no users, when there is *at least one happy user* - myself, 
which is, incidentally, the one most important user for me. It is not like 
I am a salesman hustling for money. I created a library to satisfy my needs 
that were unsatisfied by the existing offerings, and I released that 
library for anyone for free. If anyone feels it's not right for them, they 
can step in and adapt it or use something else. That's how open source 
works. 
 

>
> I can see from your comments below that you still don't understand 
> core.matrix. I'd be happy to help clarify if you are seriously interested 
> in being part of the ecosystem. 
>

Yes, apparently I don't understand it. And this may be a major point in all 
this discussion. If I, a pretty informed and experienced user, am not 
understanding an API that aspires to be THE api for a domain that has not 
been unified in any language on any platform yet, how are casual users 
going to understand it? I would like the clarification, not only for me, 
but for all people that might need it in the future.
 

> Ultimately I think you have some talent, you have obviously put in a 
> decent amount of work and Neanderthal could be a great library *if and only 
> if* it works well with the rest of the ecosystem and you are personally 
> willing to collaborate. 
>
> Your call.
>

I am willing to help, and to contribute, and all that, but how to RTFM when 
THERE IS NO TFM to read? The call should be on core.matrix people to 
explain the idea clearly and to document the whole stuff, so anyone who is 
interested could try to understand it and see whether he/she is able to 
help. Current state of documentation is far from useful, and only people 
who designed it can do something about that.

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

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

[Dragan Djuric]

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.

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

[Mars0i]

It may be that there's agreement on everything that matters.  Dragan, 
you've said that you wouldn't mind others integrating Neanderthal into 
core.matrix, but that you don't want to do that.  That you are willing to 
work with others on this is probably all that's needed.  People may have 
questions, want you to consider pull requests, etc.  I think that 
integrating Neanderthal into core. matrix will be an attractive project for 
one someone.

(For the record I don't think it's fair to criticize core.matrix as not 
being an API because the documentation is limited.  The API is in the 
protocols, etc.  It's all there in the source.  Of course anyone using 
core.matrix occasionally encounters frustration at the lack of 
documentation, but core.matrix is a work in progress.  That's the nature of 
the situation.  I have been able to figure out how to do everything I 
needed to do using only the existing documentation, source code, 
docstrings, asking occasional questions with helpful answers from others.   
If I had more time, maybe I would work on the documentation more than the 
tiny bit I've been able to do so.  Similar remarks apply to what clatrix 
doesn't do well yet.  Being unfinished is not a design flaw.)

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

[Dragan Djuric]

>
>
> (For the record I don't think it's fair to criticize core.matrix as not
> being an API because the documentation is limited.  The API is in the
> protocols, etc.
>

The problem with that view (for me, anyway) is that only a portion of an
API could be captured with protocols, and that is even an easier portion.
But, hey, I argued too much about that already. I'll let the core.matrix
developers think about whether improving these issues are worth their time.

-- 
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] superstring - A string manipulation library

[Robin Heggelund Hansen]

CLJS outputs valid ES3 code, but string.prototype.normalizer is API, and 
can be added with a polyfill. That said, I don't really like code that 
depends on polyfills to function, so another solution would be preferred, 
especially since ES6 isn't that supported yet.

søndag 21. juni 2015 17.23.37 UTC+2 skrev Lars Andersen følgende:
>
> I thought about writing a cljs port, but I don't write much cljs so I 
> thought better of it.  Software quality usually suffers when it isn't used 
> by the author, I think.
>
> I'd love to find a collaborator to work on the cljs port of this library.
>
> ES6 actually adds string.prototype.normalizer but IIRC cljs usually 
> targets ES3.
>
> On Sunday, June 21, 2015 at 4:05:23 PM UTC+2, Karsten Schmidt wrote:
>>
>> That's ++great, Lars! Would you be open to convert this into CLJC so 
>> it can all be used from CLJS as well? I guess the main stumbling block 
>> is the use of java.text.Normalizer in strip-accents, but that could be 
>> replaced with a hardcoded regexp solution for CLJS... 
>>
>> Thanks! 
>>
>> On 21 June 2015 at 13:45, Lars Andersen  wrote: 
>> > I'm happy to announce the first release of superstring, a string 
>> > manipulation library for clojure. 
>> > 
>> > Read more about why I wrote superstring here: 
>> > https://github.com/expez/superstring 
>> > 
>> > Or check out the api docs for a quick overview of what's provided: 
>> > http://expez.github.io/superstring/doc/superstring.core.html 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>
>>
>> -- 
>> Karsten Schmidt 
>> http://postspectacular.com | http://thi.ng | http://toxiclibs.org 
>>
>

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

[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 jus

Re: [ANN] Clojure 1.7.0-RC2

[James Elliott]

After using it all weekend, everything looks good for me. Thanks!

On Wednesday, June 17, 2015 at 12:44:39 PM UTC-5, Alex Miller wrote:
>
> Clojure 1.7.0-RC2 is now available.
>
> Try it via
> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-RC2/
> - Leiningen: [org.clojure/clojure "1.7.0-RC2"]
>
> 1.7.0-RC2 has the following changes since 1.7.0-RC1:
>
> 1) CLJ-1735 - Throwable->map was missing docstring
>
> 2) CLJ-1237 - reduce gives a StackOverflow for seqs that switch back and 
> forth between chunked and unchunked many times
>
> This was an old problem that was amplified in 1.7, but has now been fixed.
>
> 3) CLJ-1738 - Seqs over Java iterators that return the same mutating 
> object on every next() call
>
> Seqs are fundamentally incompatible with Java iterators that return the 
> same mutating object on every call to next().  Some Clojure libraries 
> incorrectly rely on calling seq on such iterators. In 1.7, iterator-seqs 
> are chunked, which will cause many of these incorrect usages to return 
> incorrect results immediately. The `seq` and `iterator-seq` docstrings have 
> been updated to include an explicit warning. Libraries that incorrectly use 
> `seq` and `iterator-seq` will need to be fixed before running against 1.7.
>
> 4) CLJ-1745 - Exceptions thrown from macros wrapped in additional 
> CompilerException
>
> This was a regression from CLJ-1169 and most of that change has been 
> rolled back.
>
> For a full list of changes since 1.6.0, see: 
> https://github.com/clojure/clojure/blob/master/changes.md
>
> Please give it a try and let us know if things are working (or not). The 
> more and quicker feedback we get, the sooner we can release 1.7.0 final!
>
> - Alex
>

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

New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted

recently:



Junior full stack developer at Maestro

http://functionaljobs.com/jobs/8835-junior-full-stack-developer-at-maestro



Clojure Engineer at Funding Circle

http://functionaljobs.com/jobs/8834-clojure-engineer-at-funding-circle



Cheers,

Sean Murphy

FunctionalJobs.com


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

[Dragan Djuric]

>
>
> 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 function calls that 
you want measured. Share your numbers and that project on Github and I will 
contribute comparative code for Neanderthal benchmarks, and results for 
both codes run on my machine. Of course, that would be micro benchmarks, 
but useful anyway for you, one Neanderthal user (me :) and for all 
core.matrix users.

You interested?

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 having you agree to work-with/advise others 
> who would do the actual work is great. I'd personally love to take that on 
> myself, but I already have about a half dozen side projects I'm working on 
> which I barely have time for. Oh, and a four month old baby :scream:! So if 
> there's anyone else who's willing, I may leave it to them :-)
>

I'm also glad we understand each other better now :) 

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

[Christopher Small]

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 function calls that
> you want measured. Share your numbers and that project on Github and I will
> contribute comparative code for Neanderthal benchmarks, and results for
> both codes run on my machine. Of course, that would be micro benchmarks,
> but useful anyway for you, one Neanderthal user (me :) and for all
> core.matrix users.
>
> You interested?
>
> 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 having you agree to work-with/advise others
>> who would do the actual work is great. I'd personally love to take that on
>> myself, but I already have about a half dozen side projects I'm working on
>> which I barely have time for. Oh, and a four month old baby :scream:! So if
>> there's anyone else who's willing, I may leave it to them :-)
>>
>
> I'm also glad we understand each other better now :)
>
> --
> 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.

Re: roundtripping using data.xml?

[Andreas Liljeqvist]

Seems like the "Prefix cannot be null" is still a problem.
Do anyone have a solution to this?

I am trying to roundtrip inkscape-svg to be exact.
It happens to contain a whole lot of namespaces.

Smallest example: (-> "test.svg" slurp clojure.data.xml/parse-str
clojure.data.xml/emit-str)

On Thu, Oct 25, 2012 at 12:55 AM, nchurch  wrote:

> Thanks Ryan!  This stuff is hugely helpful.
>
> One other thing you might consider around design discussions: it would
> be very useful to read XML both into clojure.xml-style structures and
> also Hiccup-style structures (you already do it the other way in sexp-
> as-element).  Hiccup is a lot more compact and readable, and if your
> project uses both XML and HTML (which I imagine most would) it would
> be nice to share the same abstraction.
>
> David Santiago's Hickory project does this for HTML, but isn't
> appropriate for XML.
>
> -Nick.
>
> On Oct 22, 7:07 pm, Ryan Senior  wrote:
> > This is related to the (lack of) support for namespaces.  I removed the
> > prefixes from the attributes below and it roundtripped fine for me.
> >
> > As far as I know, there is no work around for this kind of thing.  The
> fix
> > is for data.xml to support namespaces.  I'll get some more design
> > discussions going around namespaces this week.
> >
> > -Ryan
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Oct 22, 2012 at 8:41 PM, nchurch  wrote:
> > > Am I making a mistake, or is this a bug?
> >
> > > (use 'clojure.data.xml)
> >
> > > (def p (parse (reader "<../../>small.xml")))
> >
> > > where "small.xml" is
> >
> > > 
> > > http://schemas.android.com/apk/res/android";
> > > android:keyWidth="10%p"
> > > android:horizontalGap="0px"
> > > android:verticalGap="0px"
> > > android:keyHeight="@dimen/key_height"
> >
> > > 
> >
> > > And happens to be taken from an Android UI-defining XML file.
> >
> > > But:
> >
> > > (emit-str p)
> > > -->
> > > XMLStreamException Prefix cannot be null
> > > com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.writeAttribute
> > > (XMLStreamWriterImpl.java:564)
> >
> > > If this has to do with the lack of namespace support, are there any
> > > workarounds?
> >
> > > Thanks,
> >
> > > Nick.
> >
> > > --
> > > 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 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 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

[Dragan Djuric]

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 function 
>> calls that you want measured. Share your numbers and that project on Github 
>> and I will contribute comparative code for Neanderthal benchmarks, and 
>> results for both codes run on my machine. Of course, that would be micro 
>> benchmarks, but useful anyway for you, one Neanderthal user (me :) and for 
>> all core.matrix users.
>>
>> You interested?
>>
>> 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 having you agree to work-with/advise others 
>>> who would do the actual work is great. I'd personally love to take that on 
>>> myself, but I already have about a half dozen side projects I'm working on 
>>> which I barely have time for. Oh, and a four month old baby :scream:! So if 
>>> there's anyone else who's willing, I may leave it to them :-)
>>>
>>
>> I'm also glad we understand each other better now :) 
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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

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

[Christopher Small]

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 function
>>> calls that you want measured. Share your numbers and that project on Github
>>> and I will contribute comparative code for Neanderthal benchmarks, and
>>> results for both codes run on my machine. Of course, that would be micro
>>> benchmarks, but useful anyway for you, one Neanderthal user (me :) and for
>>> all core.matrix users.
>>>
>>> You interested?
>>>
>>> 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 having you agree to
 work-with/advise others who would do the actual work is great. I'd
 personally love to take that on myself, but I already have about a half
 dozen side projects I'm working on which I barely have time for. Oh, and a
 four month old baby :scream:! So if there's anyone else who's willing, I
 may leave it to them :-)

>>>
>>> I'm also glad we understand each other better now :)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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
>>> cloju

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

[Dragan Djuric]

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 function 
 calls that you want measured. Share your numbers and that project on 
 Github 
 and I will contribute comparative code for Neanderthal benchmarks, and 
 results for both codes run on my machine. Of course, that would be micro 
 benchmarks, but useful anyway for you, one Neanderthal user (me :) and for 
 all core.matrix users.

 You interested?

 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 having you agree to 
> work-with/advise others who would do the actual work is great.

How to share the large files that can not fit in Github?

[Lawrence Krubner]

This is more of Java eco-system/development question, but I am curious what 
folks in the Clojure community might regard as "best practice". Up till now 
most of the projects that I've worked on we've been able to share resources 
informally via "scp" and email, or via Github, but on the current project 
we are dealing with a lot of massive files, over 100 megs, many over a gig. 
These are things such as Natural Language Processing 
classifiers/dictionaries, many of which are huge. We need to have them 
available on our machines so we can do development work. We're trying to 
figure a way such that when we add new paths or new files we can tell each 
other, or find a way that they can do something similar to "git fetch 
origin" and see what changes have happened. 

How do others handle this? 




-- 
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: How to share the large files that can not fit in Github?

[Mohit Thatte]

AWS S3 is a great place to put large files
. You can
use S3 sync 
to keep things current.

~Mohit

On Mon, Jun 22, 2015 at 9:34 PM, Lawrence Krubner 
wrote:

>
> This is more of Java eco-system/development question, but I am curious
> what folks in the Clojure community might regard as "best practice". Up
> till now most of the projects that I've worked on we've been able to share
> resources informally via "scp" and email, or via Github, but on the current
> project we are dealing with a lot of massive files, over 100 megs, many
> over a gig. These are things such as Natural Language Processing
> classifiers/dictionaries, many of which are huge. We need to have them
> available on our machines so we can do development work. We're trying to
> figure a way such that when we add new paths or new files we can tell each
> other, or find a way that they can do something similar to "git fetch
> origin" and see what changes have happened.
>
> How do others handle this?
>
>
>
>
>  --
> 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.
>



-- 
-Mohit Thatte

-- 
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: Clojure community organisation

[Daniel Compton]

Hi Alex

Has Cognitect had any further discussion on this/do you have anything to 
share?

Thanks, Daniel.

On Monday, May 4, 2015 at 3:04:17 PM UTC+12, Alex Miller wrote:
>
> Re gsoc, last year Cognitect was a receiving organization for the funds 
> and distributed them to students for travel to Clojure conferences. This 
> incurs some cost on Cognitect for the accounting effort but overall seemed 
> worth it. We also offer free tickets to all gsoc students for any Clojure 
> conf we run. We are happy to keep doing this but would be happier to be 
> more out of the loop on money issues if there was some org that could act 
> in this capacity. 
>
> Re the Cognitect position on this stuff, I forwarded it to the appropriate 
> people - I don't yet have anything to share. 
>
> Alex

-- 
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: Using core.match in tests?

[whodidthis]

Thanks, exactly what i needed

On Monday, June 22, 2015 at 1:01:30 AM UTC+3, Sean Corfield wrote:
>
> How about this:
>
> (defmacro matches [value pattern]
>   `(is (match ~value ~pattern true :else false)
>(str "(match " ~value " " '~pattern ")")))
>
> (let [a {:x 2}]
>   (matches a {:y _}))
>
>
> ; => FAIL
> ; => (match {:x 2} {:y _})
> ; => expected: (clojure.core.match/match a {:y _} true :else false)
> ; =>  actual: false
>
>

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

Basic question: what's the difference between "require as" and "use as"?

[Ritchie Cai]

For example:
(:require [clojure.java.io :as io]) 
vs
(:use [clojure.java.io :as io])

In both cases, we can end up using it with "(io/ ... )". Is 
there a difference at all?

Thanks
Ritchie


-- 
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: Clojure community organisation

[Alex Miller]

Thanks for the ping - I don't think I ever heard anything back but I will 
ping again.

Alex

On Monday, June 22, 2015 at 3:26:57 PM UTC-5, Daniel Compton wrote:
>
> Hi Alex
>
> Has Cognitect had any further discussion on this/do you have anything to 
> share?
>
> Thanks, Daniel.
>
> On Monday, May 4, 2015 at 3:04:17 PM UTC+12, Alex Miller wrote:
>>
>> Re gsoc, last year Cognitect was a receiving organization for the funds 
>> and distributed them to students for travel to Clojure conferences. This 
>> incurs some cost on Cognitect for the accounting effort but overall seemed 
>> worth it. We also offer free tickets to all gsoc students for any Clojure 
>> conf we run. We are happy to keep doing this but would be happier to be 
>> more out of the loop on money issues if there was some org that could act 
>> in this capacity. 
>>
>> Re the Cognitect position on this stuff, I forwarded it to the 
>> appropriate people - I don't yet have anything to share. 
>>
>> Alex
>
>

-- 
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: Basic question: what's the difference between "require as" and "use as"?

[Sean Corfield]

On Jun 22, 2015, at 1:50 PM, Ritchie Cai  wrote:
> For example:
> (:require [clojure.java.io :as io]) 
> vs
> (:use [clojure.java.io :as io])
> 
> In both cases, we can end up using it with "(io/ ... )". Is 
> there a difference at all?

Yes, (:use [clojure.java.io :as io]) is equivalent to (:require 
[clojure.java.io :as io :refer :all]) so it refers in all of the symbols from 
that namespace directly into your namespace (i.e., they can be referenced even 
without the io/ prefix).

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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: Basic question: what's the difference between "require as" and "use as"?

[Ritchie Cai]

You mean (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io 
:as io :refer :all])?

Ritchie

> On Jun 22, 2015, at 4:15 PM, Sean Corfield  wrote:
> 
> On Jun 22, 2015, at 1:50 PM, Ritchie Cai  wrote:
>> For example:
>> (:require [clojure.java.io :as io]) 
>> vs
>> (:use [clojure.java.io :as io])
>> 
>> In both cases, we can end up using it with "(io/ ... )". Is 
>> there a difference at all?
> 
> Yes, (:use [clojure.java.io :as io]) is equivalent to (:require 
> [clojure.java.io :as io :refer :all]) so it refers in all of the symbols from 
> that namespace directly into your namespace (i.e., they can be referenced 
> even without the io/ prefix).
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> 
> 
> -- 
> 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/ned76MpB-W0/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.

Re: Basic question: what's the difference between "require as" and "use as"?

[Sean Corfield]

On Jun 22, 2015, at 2:22 PM, Ritchie Cai  wrote:
> You mean (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io 
> :as io :refer :all])?

Not quite, (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io 
:refer :all])

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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: How to share the large files that can not fit in Github?

[Daniel Jomphe]

Since you mentioned GitHub, have you looked at Git Large File Storage?

https://github.com/blog/1986-announcing-git-large-file-storage-lfs

On Monday, June 22, 2015 at 4:09:31 PM UTC-4, Mohit Thatte wrote:
>
> AWS S3 is a great place to put large files 
> . You can 
> use S3 sync   
> to keep things current.
>
> ~Mohit
>
> On Mon, Jun 22, 2015 at 9:34 PM, Lawrence Krubner  > wrote:
>
>>
>> This is more of Java eco-system/development question, but I am curious 
>> what folks in the Clojure community might regard as "best practice". Up 
>> till now most of the projects that I've worked on we've been able to share 
>> resources informally via "scp" and email, or via Github, but on the current 
>> project we are dealing with a lot of massive files, over 100 megs, many 
>> over a gig. These are things such as Natural Language Processing 
>> classifiers/dictionaries, many of which are huge. We need to have them 
>> available on our machines so we can do development work. We're trying to 
>> figure a way such that when we add new paths or new files we can tell each 
>> other, or find a way that they can do something similar to "git fetch 
>> origin" and see what changes have happened. 
>>
>> How do others handle this? 
>>
>>
>>
>>
>>  -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> -Mohit Thatte
>  

-- 
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: Basic question: what's the difference between "require as" and "use as"?

[Ritchie Cai]

Ok, so require without :refer will default to :refer :all?

> On Jun 22, 2015, at 4:32 PM, Sean Corfield  wrote:
> 
> On Jun 22, 2015, at 2:22 PM, Ritchie Cai  wrote:
>> You mean (:use [clojure.java.io]) is equivalent to (:require 
>> [clojure.java.io :as io :refer :all])?
> 
> Not quite, (:use [clojure.java.io]) is equivalent to (:require 
> [clojure.java.io :refer :all])
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> 
> 
> -- 
> 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/ned76MpB-W0/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.

Re: Basic question: what's the difference between "require as" and "use as"?

[Sean Corfield]

On Jun 22, 2015, at 2:39 PM, Ritchie Cai  wrote:
> Ok, so require without :refer will default to :refer :all?

No.

>> (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io :refer 
>> :all])

There’s no :as here. :use is like :require :refer :all.

>> (:use [clojure.java.io :as io]) is equivalent to (:require [clojure.java.io 
>> :as io :refer :all]) 

There’s an :as in both here. :use :as is like :require :as :refer :all

Both :use and :refer :all (in :require) are discouraged because they pollute 
your namespace with every symbol from the used/required namespace.

There’s not much point in specifying an alias (with :as) for :use or :require 
:refer :all since those bring in every symbol directly anyway.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



-- 
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: Basic question: what's the difference between "require as" and "use as"?

[Ritchie Cai]

Ah, I see. I thought “use :as” will not intern all the symbols into current 
namespace, apparently that’s not the case.
Thanks for clearing this up.

Ritchie

> On Jun 22, 2015, at 4:52 PM, Sean Corfield  wrote:
> 
> On Jun 22, 2015, at 2:39 PM, Ritchie Cai  wrote:
>> Ok, so require without :refer will default to :refer :all?
> 
> No.
> 
>>> (:use [clojure.java.io]) is equivalent to (:require [clojure.java.io :refer 
>>> :all])
> 
> There’s no :as here. :use is like :require :refer :all.
> 
>>> (:use [clojure.java.io :as io]) is equivalent to (:require [clojure.java.io 
>>> :as io :refer :all]) 
> 
> There’s an :as in both here. :use :as is like :require :as :refer :all
> 
> Both :use and :refer :all (in :require) are discouraged because they pollute 
> your namespace with every symbol from the used/required namespace.
> 
> There’s not much point in specifying an alias (with :as) for :use or :require 
> :refer :all since those bring in every symbol directly anyway.
> 
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
> 
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
> 
> 
> 
> -- 
> 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/ned76MpB-W0/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.

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

[A]

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 function 
> calls that you want measured. Share your numbers and that project on 
> Github 
> and I will contribute comparative code for Neanderthal benchmarks, and 
> results for both codes run on my machine. Of course, that would be micro 
> benchmarks, but useful anyway for you, one Neanderthal user (me :) and 
> for 
> all core.matrix users.
>
> You interested?
>
> 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 
>> 

[ANN] Introducing Yo-yo, a protocol-less, function composition-based alternative to Component

[James Henderson]

Hi all,

I've just released an early version of 'Yo-yo', a protocol-less, function 
composition-based alternative to Component. It's still in its early stages, 
so feedback would be very much appreciated!

https://github.com/james-henderson/yoyo

Yo-yo was also an experiment to see what could be de-coupled from the 
concept of 'reloadable systems', so you won't find any configuration, 
dependency injection, etc - just a way to write a system that can be easily 
started, stopped, and reloaded.

Fundamentally, we start by assuming there's a function available that only 
returns 'when the system stops' - a 'latch', say. If we had such a 
function, we could start our system, call that function, then stop the 
system (closing any necessary resources). A database pool, for example, 
might look like this:

(defn with-db-pool [db-config f]
  (let [db-pool (start-pool! db-config)]
(try
  (f db-pool)

  (finally
(stop-pool! db-pool)

Here, we're assuming that we'll be passed 'f', the 'latch' function. A web 
server would be similar, and, because they're both functions, they're very 
simple to compose:

(with-db-pool {...}
  (fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool})
  :port ...}
  (fn [web-server]
;; TODO: Ah. We've run out of turtles. :(


This is where Yo-yo comes in - there’s a function called run-system!, which 
takes a function that accepts a latch:

(:require [yoyo])

(yoyo/run-system!
  (fn [latch]
(with-db-pool {...}
  (fn [db-pool]
(with-web-server {:handler (make-handler {:db-pool db-pool}) ; n.b. we 
have access to the db-pool here - no need for global state!
  :port ...}
  (fn [web-server]
(latch))) ; Aha!

run-system! then returns a promise - deliver any value to it, and it'll 
stop the system.

And that's pretty much it! There are a few more functions - mostly to do 
with easily starting/stopping/reloading a system through the REPL, and a 
macro to simplify the 'function staircase' - these are covered in more 
detail in the README. There are some also common components - a database 
pool, a web server, and a simple integration for existing Component systems.

It'd be great to hear your thoughts/ideas, whatever they may be - either 
through here, e-mail, Github, or Twitter - thanks!

James

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

[Dragan Djuric]

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 function
>> calls that you want measured. Share your numbers and that project on 
>> Github
>> and I will contribute comparative code for Neanderthal benchmarks, and
>> results for both codes run on my machine. Of course, that would be micro
>> benchmarks, but useful anyway for you, one Neanderthal user (me :) and 
>> for
>> all core.matrix users.
>>
>> You interested?
>>
>> With all that out of the way... I'm g

Re: roundtripping using data.xml?

[Matching Socks]

The usual XML-processing options that are open in Java, are still open in 
Clojure.  You may use JAXP or StAX for applications that outwit clojure.xml.

By the way, there is a feature enhancement page about this at
http://dev.clojure.org/display/DXML/Namespaced+XML
How do you feel about the proposals?

-- 
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: Using core.match in tests?

[Surgo]

This might be a bit of a strange or off-topic segue but it got me thinking. 
Is there an idiomatic way to handle optional dependencies in Clojure?

Ideally, this macro would be a part of core.match itself (submit a pull 
request, get it merged, and whatnot). Of course, you don't want core.match 
to minimize its dependencies so it probably shouldn't depend on any test 
infrastructure (in theory; this test infra is in core so who cares). I've 
had to do something like this for another project, and my solution was:

(try
  (require 'the.library.of.interest)
  (do-whatever defmacro or whatnot)
  (catch java.io.FileNotFoundException _ nil))  ; Makes this entire 
try-catch block do nothing if the require failed.

That works pretty well, but I'm wondering why I don't see optional 
dependencies more often with stuff like that.

Cheers,
-- Morgon

On Monday, June 22, 2015 at 4:27:55 PM UTC-4, whodidthis wrote:
>
> Thanks, exactly what i needed
>
> On Monday, June 22, 2015 at 1:01:30 AM UTC+3, Sean Corfield wrote:
>>
>> How about this:
>>
>> (defmacro matches [value pattern]
>>   `(is (match ~value ~pattern true :else false)
>>(str "(match " ~value " " '~pattern ")")))
>>
>> (let [a {:x 2}]
>>   (matches a {:y _}))
>>
>>
>> ; => FAIL
>> ; => (match {:x 2} {:y _})
>> ; => expected: (clojure.core.match/match a {:y _} true :else false)
>> ; =>  actual: false
>>
>>

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

I'm trying to decode some source code to understand how it works

[Gregg Williams]

Hi--

The code in question is a solution to http://www.4clojure.com/problem/58 
(write a function that does function composition, without using 'comp'). 
The solution I'm trying to understand is by amalloy:

(defn mycomp [& fs]
  (reduce (fn [f g]
#(f (apply g %&)))
  fs))

For example ((mycomp inc first reverse) [1 2 3 4]) would return the value 5.

Here are the notes I've written so far, my attempt to explain how this code 
is evaluated, using ((mycomp inc first reverse) [1 2 3 4]) as the code to 
be evaluated:

- begin

; name the function used by reduce 'f1'
(defn f1 [f g]
  #(f (apply g %&)))

; the collection used by reduce is:
[inc first reverse]

; first iteration of `reduce`; f = inc, g = first
; (f1 inc first) returns #(inc (apply first %&))

; the collection is now:
[first reverse]

; next iteration of reduce; f = #(inc (apply first %&)), g = reverse

 ; (f1 f g) returns:
 #( #(inc (apply first %&)) (apply reverse %&) )
 <-- function > <-- arg, sorta -->
; -- BTW, this is invalid as Clojure code


; now, apply this function to the data:
( #( #(inc (apply first %&)) (apply reverse %&) ) [1 2 3 4])   ; #1
   ( #(inc (apply first %&)) (apply reverse  ([1 2 3 4]) )); #2
  (inc (apply first ((apply reverse  ([1 2 3 4])   ; #3
  (inc (apply first ((  reverse   [1 2 3 4]) )))   ; #4
  (inc (apply first (( 4 3 2 1 ; #5
  (inc (  first (  4 3 2 1)))  ; #6
  (inc 4)  ; #7
  RESULT = 5
- end

(FYI, I know that you can't nest anonymous functions. Consider the above to 
be a thought experiment.)

Is this a good way to think of how the code is evaluated?

I have to admit, I'm not sure I'm thinking about the code correctly. The 
code recurses until it gets to the rightmost function, then it is finally 
able to execute (apply reverse ([1 2 3 4])) (see #3 above) and begin moving 
"up and out of" the nested recursion.

When you look at the function given as the first argument to 'recurse', (fn 
[f g]   #(f (apply g %&))), how do you think about when '%&' is replaced by [1 
2 3 4]? Does this happen only when 'recurse' has "consumed" all the items 
in the collection it's been given (as the second argument)?

I'd appreciate any elaborations, observations, corrections, or alternate 
explanations you would care to add.

Many thanks!


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