Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Joachim De Beule]

For those interested: here's some work on using deeplearning4j in clojure 
(no abstractions added, simply a port of the nd4j and deeplearning4j API's 
to 'clojuresque' functions and multimethods.)

https://github.com/engagor/dl4clj

If anybody wants to contribute they're welcome of course!

Op vrijdag 7 oktober 2016 06:22:48 UTC+2 schreef Sunil Nandihalli:
>
> I think deeplearning4J is a contender for deeplearning in clojure. I have 
> not used it .. but I repeatedly see the sponsored link on clojure-reddit. 
> Since nobody mentioned it .. I thought of mentioning it
>
> On Fri, Oct 7, 2016 at 7:40 AM, kovas boguta  > wrote:
>
>> On Thu, Oct 6, 2016 at 9:26 PM, Mikera > > wrote:
>>
>>>
>>> I'm hoping to work with Dragan to get core.matrix integration working 
>>> with Neanderthal, now that Windows support is finally arriving. This would 
>>> get you a few big advantages:
>>>
>>
>> Yes, I can see how my problem relates to the core.matrix vision. The only 
>> missing piece is the actual operations I want (nn layers) :)
>>
>>
>> -- 
>> 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.
>>
>
>

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Dragan Djuric]

Hi Kovas,


> One question:
>
> Is it possible to feed Neanderthal's matrix representation (the underlying 
> bytes) into one of these other libraries, to obtain 
> computations Neanderthal doesn't support? 
>

There are two parts to that question, I think: 1) How can you make 
Neanderthal work with any other library that you need to interoperate with? 
2) Does Neanderthal have the operation that you need, and what to do if it 
doesn't?
I'll start with 2:

2) Currently, Neanderthal supports all BLAS 1, 2 and 3 operations for 
vectors and dense matrices on CPU & GPU. The ultimate goal is to support 
all other standard matrix formats (TR, sparse, etc.) AND LAPACK, which has 
extensive support for linear algebra. The good news is that what is there 
works really, really well, because I concentrated my efforts on solving the 
hardest problem first (and succeeded!). Now it is a matter of putting the 
grunt work to repeat what's done for the existing things to cover more of 
CBLAS and LAPACK API, and even to do the integration with CUDA in a similar 
way I did the OpenCL integration. I could have even done it by now, but I 
preferred to work on other things, one of those being a bayesian data 
analysis library Bayadera, that puts what Neanderthal offers to great use 
:) I have also seen that the Yieldbot people forked Neanderthal and 
implemented some part of LAPACK, but did not release anything nor issued a 
PR. So, if the methods you need fall into the scope of matrices and linear 
algebra (BLAS + LAPACK), there is a good chance it will be supported, 
either by you or some other user providing it, or bugging me often enough 
that I realize it is urgent that I add it :)

1) There are at least two parts to the interoperation story - API for 
operations (like mm vs mmult or whatever) and that is the very easy part. 
The hard part is a multitude of matrix formats and those formats' 
representations in memory. This is what makes or breaks your performance, 
and not by a few percents but by a few orders of magnitude. The sad part is 
that almost all focus is always on the easy part, completely ignoring the 
hard part or just thinking that it will magically solve itself. So, suppose 
that you have data laid out in memory in the format A. That format may or 
may not be suitable for operation X, and if it is not, it is often a bad 
idea to shoehorn it in for convenience, instead of thinking harder about 
data flow and transition data to format B to be used appropriately. That 
means that even inside the same library, you often need to do the data 
transformations to best suit what you want to do with the data. Long story 
short, you need to do data transformations anyway, so having Neanderthal 
and ND4J support core.matrix mmult operation won't help you a bit here. 
You'll have to transform data from the one to the other. If you are lucky, 
they use the same underlying format, so the transformation is easy or even 
automatic, or can be, but the point is that someone needs to create 
explicit transformations to ensure the optimal way instead on relying on 
generic interoperability layer (at least for now).
 

> My situation: Neanderthal covers some of the algorithms I'd like to 
> implement. It looks easier to get started with and understand than the 
> alternatives. But down the line I'll likely want to do convolution, 
> sigmoid, the typical Neural Network layers. Note, I don't care about 
> 'tensors' exactly; the bookkeeping to simulate a tensor can be automated, 
> but the fundamental operations cannot. So there is a question of whether to 
> just absorb the learning curve and shortcomings of these more general 
> libraries rather than to risk switching horses midstream. 
>

I think it is important to note that the operations you mentioned are not 
in the scope of a matrix library, but in the scope of a neural networks 
library. Neanderthal is simply not a library that should have those 
operations, nor it can have all operations for all ML techniques (that are 
countlesss :)
 
On the other hand, what I created Neanderthal for, is exactly as a building 
block for such libraries. The focus is on: if you need to build a NN 
library, Neanderthal should (ideally) give you a standard matrix methods 
for computations and data shuffling, Clojure should enable you to create a 
great interface layer, and (if needed) ClojureCL should help you write 
custom optimized low-level algorithms for GPU and CPU. 

I imagine I'm not alone in this.. if there was a straightforward story for 
> how to interop Neanderthal when necessary with some more general library 
> that would be powerful. Unfortunately I'm not sufficiently expert to 
> evaluate which of the choices would be most pragmatic and how to pull it 
> off. 
>

Today's state (in Clojure, Java, and probably elsewhere) is, IMO: if you 
need a ready-made solution for NNs/DL, you have to pick one library that 
has the stuff that you need, and go with what they recommend completely

Re: Clojure with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Dragan Djuric]

Hi Mike,

Thanks for the update.


> Opening the source is not entirely my decision, this is a collaboration 
> with the Thinktopic folks (Jeff Rose et al.). I'm personally in favour of 
> being pretty open about this stuff but I do think that it would be a 
> mistake if people build too much stuff on top of the wrong API which is 
> likely to happen if we release prematurely.
>
> I believe that number of users that would try this is small anyway, and 
they will use exclusively for evaluation and hobby at first, so, as Kovas 
said, having people build too much on it is something we can only hope for! 
:) I hope the Thinktopic folks would support opening it...
 

> Things I'm paricularly keen to have nailed down in particular before we go 
> public:
> 1. A tensorflow-like DAG model that allows arbitrary operations to be 
> composed compose into (possibly nested) graphs
> 2. Enough abstraction that different backends work (ClojureScript, 
> Pure-JVM, Native, GPU etc.). core.matrix provides most of this, but there 
> are still some deep-learning specific operations that need tuning and can 
> be quite backend-specific, e.g. cuDNN has some specific ways of dealing 
> with mini-batches which we need to get right. I'd love to try Neanderthal 
> with this too if we can get the core.matrix integration working.
> 3. Decent, stable APIs for the algorithms that you typically want to run 
> for mini-batch training, cross-validation etc.
> 4. Pluggable gradient optimisation methods (we currently have stuff like 
> ADADELTA, SDG, ADAM etc. but would like to make sure this is sufficiently 
> general to support any optimisation method)
>
> I'll have a talk with the Thinktopic folks and see if we can come up with 
> a timeline for a open source release. In the meantime, if anyone is 
> *really* interested then we may be able to arrange collaboration on a 
> private basis.
>

It's not urgent, so any rough estimate would be great! 

-- 
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 with Tensorflow, Torch etc (call for participation, brainstorming etc)

[Dragan Djuric]

>
>
> If people build on the 'wrong' api, thats a good problem to have. The 
> field is so in flux anyway. The problem can also be mitigated through 
> minimalism in what is released in the beginning. 
>
> 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: http-kit for duct

[ngettypogzli]

I simply created a wrapper function, for the new-web-server function in 
Danielsz 
http-kit 

 
component, that will accept a map as the argument and wrote a reference to 
this function in "system.edn" i.e. 

{:components { :http #var myduct.component.http-kit/http-kit-server}
 :endpoints {}
 :dependencies {...}
 :config {... :http {:port http-port}}}

myduct is the name of the project and

(defn http-kit-server [argmap]
  (system.components.http-kit/new-web-server (:port argmap)))

or something to this effect

>

-- 
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: Should I switch to Clojure after 3 years of learning another full stack ?

[Nando Breiter]

> I want to learn the language and "frameworks" (or how to create the
> architecture) much quicker than previous attempt.
>

I recently came across an excellent course:
https://www.coursera.org/learn/learning-how-to-learn that I think can be
very helpful for someone trying to learn something efficiently, especially
on their own. Essentially, the course explains how the brain learns things,
and unless you have picked up a knack for this along the way, it's not all
all obvious.

In a nutshell, our brains have only 4 "slots" of working memory. As
programmers, whether learning something new or developing a program in a
language we know, we often have a need to significantly overload our
working memory - 4 slots isn't enough. In the course, that process is
called "chunking" - grouping bits of knowledge together to free up working
memory so that you can continue to learn, or think about something complex.
In the end, learning Clojure efficiently will boil down to how efficiently
you can chunk and store in long term memory how to program in Clojure.

-- 
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] zprint, lein-zprint Pretty print your code and data [ALPHA]

[Kim Kinnear]

> But for that I need zprint to be ported to clojurescript.
>
> Could you do it?
>

A Clojurescript port is certainly something I've been thinking about.  The 
major underlying library on which zprint depends (rewrite-clj) has a 
Clojurescript port, so in theory it should all be straightforward.   The 
configuration environment for Clojurescript is very different.  I've only 
dabbled in Clojurescript, so I would need to come up with a better 
development environment than I have used so far to enable me to make 
substantial progress.  I am interested in which part you think would be 
interesting -- the part of zprint that pretty prints Clojure (or in your 
case, Clojurescript) structures, or the part that parses Clojure (or 
Clojurescript) source and formats that.  Perhaps both.  

For what it is worth (though I know this is not what you are asking), 
zprint and lein-zprint handle the reader conditionals implicit in .cljc 
files.  I would expect that they will do ok on clojurescript files too, 
though I haven't done any testing in that area yet.  I'll be interested to 
hear if someone gives that a try.

Let's talk offline and explore this in more detail.

-- 
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] zprint, lein-zprint Pretty print your code and data [ALPHA]

[Yehonathan Sharvit]

lein-zprint works fine with cljs files.

Taking it offline for further details

On Fri, 7 Oct 2016 at 17:12 Kim Kinnear  wrote:

>
> But for that I need zprint to be ported to clojurescript.
>
> Could you do it?
>
>
> A Clojurescript port is certainly something I've been thinking about.  The
> major underlying library on which zprint depends (rewrite-clj) has a
> Clojurescript port, so in theory it should all be straightforward.   The
> configuration environment for Clojurescript is very different.  I've only
> dabbled in Clojurescript, so I would need to come up with a better
> development environment than I have used so far to enable me to make
> substantial progress.  I am interested in which part you think would be
> interesting -- the part of zprint that pretty prints Clojure (or in your
> case, Clojurescript) structures, or the part that parses Clojure (or
> Clojurescript) source and formats that.  Perhaps both.
>
> For what it is worth (though I know this is not what you are asking),
> zprint and lein-zprint handle the reader conditionals implicit in .cljc
> files.  I would expect that they will do ok on clojurescript files too,
> though I haven't done any testing in that area yet.  I'll be interested to
> hear if someone gives that a try.
>
> Let's talk offline and explore this in more detail.
>
> --
> 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/am29qj7VHZI/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: Clojure + ClojureScript + Electron + Om.Next + Boot and ProtoRepl on Atom to co-exist?

[Ray King]

Thanks for all the direct and public replies so far, we take great 
reassurance from them.

Recapping the constraints:

We have an existing Java library, which is a collection of algorithms 
(Statistical inferencing stuff), architecturally they are stateless. Pass 
in a Map, and it returns a Map.  There is a coordination layer which we 
have moved to Clojure, this just a Map/Reduce & transform router. For 
example, we would run a simulation a few alternative models concurrently. 
The Clojure code distributed work maps to threads and instances in 
different memory spaces and consolidated all the results as pour back in 
asynchronously. It handles failures and continuation etc.  This part works 
fine. The difference of reimplementing this layer in Clojure is night and 
day, forget Java and Scala for this, the rewrite was painless and scaling 
options we have given ourselves are fantastic.

We still have Java dependencies, there in is the rub.

We want to move as much as this stuff client side as possible, 
Clojurescript and only leave the bounds of the customer's machine for 
certain operations where we need to offload these work maps to cloud bound 
processors.

In the perfect world, we would have an electron app with render processes 
handling the GUI elements and the primary process doing some light 
processing and distribution and coordination of the work maps. In fact, we 
have prototyped this, and it appears viable.

In the short term, we have running a JVM based server on the client machine 
as that is what host the algorithm library.

(By the way, this library will eventually be reimplemented in Clojure 
script, but as there is a need to for precision & correctness we currently 
have a test suit that 3x larger than the code base and we still trying to 
get our heads around the float points in JS)

The above is what motivated the question.

1. Cljs and Electron, Tick no problems.

2. Packaging up a web socket server in electron for deployment and later 
version updating? Has it been done, Clues thoughts, etc.?

3. Developer workflow, (Productivity). 

a. Currently, we have the library, Java code, and Clojure layer in one code 
base and repository. Using Lein, and Cursive to hack on it. Which by itself 
is fine.

b. Bring 'Cljs' & electron into play, using ATOM with 'Dirac' and 
'Cljs-oops' with 'Boot' starting becoming a lot more ergonomic and lighter 
then Intellij, Cursive and Lein.

We would like to unite these two worlds into one repository and one tool 
chain. From that one environment, we should be able to work on the GUI 
layer, live reload, inspect and tango on. (ATOM, Dirac and Boot). Then move 
without friction and context changes to hacking some Clojure, running some 
unit test and now specs with 1.9.0-alpha. Then back again, to the front.

The fact is all the above (Clj, Cljs, Electron and Java can work together, 
and deliver good results). But we have yet to find a unified tooling chain. 
Being an IDE/Editor, 'repl', build and dependency management. That handles 
the architectural options that 'Clj' and 'Cljs' is enabling.

Yes, 'lein' abstracts us from mistakes of past 'Maven' but it is not the 
promised landed. I want to write code executable testable code to manage my 
project, to extract what I need from the code base, compile and package 
into immutable file sets. 

Darken by two decades of Java, Maven and dependence management yet not 
brave enough to ride the grunt while gulping down bower packages which are 
made by copy and paste mystery meats. I am thankful for the Google Closure 
Complier that tree shakes out some of the JS crap that always seems to find 
its way into JS apps. I am hoping that 'boot; will become the tool that 
bridges 'Clj' and 'Cljs'.

Please share your thoughts and wash apart any ignorance I have in this 
area.  Indeed, if you have a directory structure and tooling around a 
unifying a 'Clj', 'Java', 'Cljs' and 'JS' project, please share.

Thanks again for the suggestions, I hope this post elaborate more upon what 
I mean when I say developer workflow, productivity and ergonomics.


On Friday, October 7, 2016 at 6:13:30 AM UTC+11, Daniel Compton wrote:
>
> Hi Ray
>
> We have a ClojureScript + Electron + Re-Frame application that we run. 
> Those three work together quite nicely. I’m not totally clear what it would 
> look like for Clojure + Boot + ProtoRepl to co-exist with the first three? 
> Can you explain what you’re envisioning some more?
>
> On Wed, Oct 5, 2016 at 11:41 PM Mathias De Wachter  > wrote:
>
>> Hi Ray,
>>
>> I'm in a pretty much identical situation, except that I'm using re-frame 
>> for the gui that connects to the websocket the local clojure app provides. 
>> I haven't gotten as far as you yet, since I haven't yet started the "port" 
>> of the gui from browser to electron. I also have two code bases, but am 
>> wondering if the merge makes sense. So, I would be very interested to see 
>> read about your experience!
>>
>> --
>> You rece