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

[Bobby Bobble]

> - Ability to declare graphs / stacks of operations (somewhat analogous to 
> tensorflow)
>

I'd be interested to know more as I've been working with factor graphs in 
Clojure with core.matrix, and it sounds related -- have you done anything 
like message-passing on graphs ? 

-- 
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: New Matrix Multiplication benchmarks - Neanderthal up to 60 times faster than core.matrix with Vectorz

[Bobby Bobble]

I'm in the same boat as Mars0i in that I've written a load of code with 
core.matrix, which I'm happy with and which I will never have time to 
rewrite for Neanderthal. If I had a new project that was 
performance-critical I might bother to learn Neanderthal but for my 
existing project, speed is secondary to maintainability now. If my boss 
asked me to speed it up by 60x I'd love to be able to just switch to 
implementation :Neanderthal with core.matrix! One keyword and boom.

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

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroup

Re: [ANN] cljs-mathbox, wrapper for the MathBox JS lib

[Bobby Bobble]

very happy this exists thanks!

On Thursday, December 10, 2015 at 12:20:16 AM UTC, Egg Syntax wrote:
>
> I've just released cljs-mathbox, an idiomatic cljs wrapper around the 
> MathBox visualization library.
>
> MathBox  is a powerful 
> library for mathematical (and data) visualization in the browser, 
> specializing in two- and three-dimensional, animated visualizations, built 
> on Three.js. cljs-mathbox is a pretty thin wrapper over it.
>
> Feedback and pull requests welcomed. I'm often on the Clojurians slack; 
> feel free to ask me questions directly or in the recently created #datavis 
> channel.
>
> on clojars 
> on github 
> example repo 
>
>
>

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

[Bobby Bobble]

spooky action at a distance - back to OO again!

On Tuesday, November 24, 2015 at 3:21:45 PM UTC, William la Forge wrote:
>
> As in quantum entanglement? :-)
>

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

[Bobby Bobble]

"Careful - ‘complect’ has a very specific meaning"

OK something to do with braiding, yes. 

But, if someone has to explain the etymology of their word to you for it to 
make sense, then the word has failed. 

If you mean "braided" say "braided",  or better still "tangled"! I mean, 
"braided" or "plaited" imply pattern and forethought, not the messiness the 
word "complect" is supposed to imply.

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

[Bobby Bobble]

On Tuesday, November 24, 2015 at 8:19:41 AM UTC, Colin Yates wrote:
>
> > (Clojure's vocabulary is not to be questioned...why say "conflate" or 
> "confuse" when you can say "complect" to reinforce in-group membership ?) 
> /rant
>
> THANK YOU!  I can't count the number of times I've had to restrain myself 
> from an apoplectic rant about this hideous non-word.  What is wrong with 
> "complicate" FFS?!
>
> Confusion is somewhat orthogonal to complexity as it is more to do with 
> the _understanding_ of the thing.
>
>
indeed. I meant "confuse" as "to make harder to understand" because one aim 
of coding is to make our code readable, and that comes with simplicity. Our 
code reflects our understanding of the problem and if someone's code is 
confusing, it's usually because they didn't understand the problem well 
enough to articulate a good solution.

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

[Bobby Bobble]

let's not forget that Clojure's datastructures are objects. They respond to 
messages like seq, first, rest etc (which requires a bit more complexity 
than what Clojurians hail as "just data", which would be like 
1010101101010100011011...what Clojurians really mean by that 
term is something like "uniform access to objects")

(Clojure's vocabulary is not to be questioned...why say "conflate" or 
"confuse" when you can say "complect" to reinforce in-group membership ?) 
/rant

anyway to the point, it depends what you mean by "objects".

What you propose is to use maps as a kind of namespace for functions. It's 
a good idea. I use this pattern too. Really, namespaces should be 
maps...actually I think there was a project called Kiss to that end.

But real OO, as realized by Smalltalk and Self is about messaging, not 
objects. AFAIA there's no way in Clojure to represent "the invocation of a 
function on a thing" the way you can represent "the sending of a message to 
an object" in Smalltalk.


On Saturday, November 21, 2015 at 2:54:15 AM UTC, William la Forge wrote:
>
> Code as data is the mantra. Functions and closures as data. So why not 
> objects as data? What I propose is nothing new, but perhaps a new style.
>
> Making objects from map structures is simple enough in Clojure. And easy 
> enough to put functions in a map. So why not closures? A closure in a map 
> is a lot like an object method, hmm?
>
> I found clojure components to be inspirational. But as light-weight as 
> they are, components are still too heavy-weight to be objects. But a simple 
> map seems ideal. And with only a map instead of a record or deftype, 
> composition is simplicity itself. But the key idea here comes from clojure 
> components: contents of the map should be configuration parameters or 
> architecture, but not state. Put state in an atom and then (optionally) put 
> the atom in the map. But once an object is formed, the contents of the map 
> should not change. There should be no need to update a reference to this 
> map.
>
> Below is what I am calling a Clojure Object. Like a Java object, the 
> method holds both data and methods (closures). Note that, because we are 
> using closures, local data can be accessed without having to be put in the 
> map. For example, the file-channel variable is not accessed via the map and 
> need not have been added to the map.
>
> Bill
>
> (ns aatree.db-file
>   (:require [clojure.tools.logging :as log])
>   (:import (java.nio.channels FileChannel)
>(java.nio.file OpenOption StandardOpenOption)))
>
> (defn db-file-open
>   ([file opts]
> (db-file-open (assoc opts :db-file file)))
>   ([opts]
> (if (not (:db-file opts))
>   (throw (Exception. "missing :db-file option")))
>(let [file (:db-file opts)
>  ^FileChannel file-channel
>  (FileChannel/open (.toPath file)
>(into-array OpenOption
>[StandardOpenOption/CREATE
> StandardOpenOption/READ
> StandardOpenOption/WRITE]))
>  opts (assoc opts :db-file-channel file-channel)
>  opts (assoc opts
> :db-close
> (fn []
>   (try
> (.close file-channel)
> (catch Exception e
>   (log/warn e "exception on close of db-file")))
>   (dissoc opts :db-file-channel)))
>  opts (assoc opts
> :db-file-empty?
> (fn []
>   (= 0 (.size file-channel
>  opts (assoc opts
> :db-file-read
> (fn [byte-buffer position]
>   (.read file-channel byte-buffer position)))
>  opts (assoc opts
> :db-file-write
> (fn [byte-buffer position]
>   (.write file-channel byte-buffer position)))
>  opts (assoc opts
> :db-file-write-root
> (fn [byte-buffer position]
>   (.force file-channel true)
>   (.write file-channel byte-buffer position)
>   (.force file-channel true)))
>  opts (assoc opts
> :db-file-force
> (fn []
>   (.force file-channel true)))]
>  opts)))
>
>

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

best practice with forked libraries

[Bobby Bobble]

Say there's a dependency that I fork and add some features I need for my 
team's project. I can use my fork locally with lein install no problem, and 
so can others *if* they clone my fork and do the same. It would be more 
convenient if I could publish my fork to Clojars and depend on that, and 
maybe down the line I can return to depending on the original if my PR is 
accepted. What's the best thing to do here ?

-- 
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: Library suggestions requested for clojure-toolbox.com

[Bobby Bobble]

Instar https://github.com/boxed/instar would go under Data Transformation

On Monday, October 5, 2015 at 8:41:11 PM UTC+1, James Reeves wrote:
>
> If you've written or know about a Clojure or ClojureScript library, and 
> it's not already on clojure-toolbox.com , 
> I'd like to hear about it.
>
> Post the name and URL (and an optional category) as reply to this message, 
> and I'll add it to the site.
>
> - 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] ClojureCL - OpenCL 2.0 Clojure library (GPGPU and high performance parallel computing)

[Bobby Bobble]

superb!

are there any plans to include opengl context sharing for visualisation ?

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