On Sat, Jun 15, 2013 at 4:37 AM, Mikera <mike.r.anderson...@gmail.com> wrote: > On Friday, 14 June 2013 18:15:34 UTC+1, Jason Wolfe wrote: >> >> Hey Mikera, >> >> I did look at core.matrix awhile ago, but I'll take another look. >> >> Right now, flop is just trying to make it easy to write *arbitrary* >> array operations compactly, while minimizing the chance of getting >> worse-than-Java performance. This used to be very tricky to get right >> when flop was developed (against Clojure 1.2); the situation has >> clearly improved since then, but there still seem to be some >> subtleties in going fast with arrays in 1.5.1 that we are trying to >> understand and then automate. >> >> As I understand it, core.matrix has a much more ambitious goal of >> abstracting over all matrix types. This is a great goal, but I'm not >> sure if the protocol-based implementation can give users any help >> writing new core operations efficiently (say, making a new array with >> c[i] = a[i] + b[i]^2 / 2) -- unless there's some clever way of >> combining protocols with macros (hmmm). > > > A longer term objective for core.matrix could be to allow compiling such > expressions. Our GSoC student Maik Schünemann is exploring how to represent > and optimised mathematical expressions in Clojure, and in theory these could > be used to compile down to efficient low-level operations. API could look > something like this: > > ;; define an expression > (def my-expression (expression [a b] (+ a (/ (* b b) 2)))) > > ;; compile the expression for the specified matrix implementation A > (def func (compile-expression A my-expression)). > > ;; now computation can be run using the pre-compiled, optimised function > (func A B) > > In the case that A is a Java double array, then perhaps the flop macros > could be the engine behind generating the compiled function? >
Awesome, that sounds like a very interesting and promising approach. >> >> I just benchmarked core.matrix/esum, and on my machine in Clojure >> 1.5.1 it's 2.69x slower than the Java version above, and 1.62x slower >> than our current best Clojure version. > > > Great - happy to steal your implementation :-) > > Other core.matrix implementations are probably faster BTW: vectorz-clj is > pure Java and has esum for the general-purpose Vector type implemented in > exactly the same way as your fast Java example. Clatrix executes a lot of > operations via native code using BLAS. Yes, that part of core.matrix is great, and we'll definitely look into using it. >> >> A collaboration sounds interesting -- although right now it seems like >> our goals are somewhat orthogonal. What do you think? > > > Seems like the goals are relatively complementary. I think the areas of > potential collaboration are of three kinds: > 1) Leveraging flop to get the fastest possible implementations for > core.matrix > 2) Using core.matrix to provide higher-level abstractions / operations on > top of basic arrays > 3) Sharing tools / standards / approaches where it makes sense > > Clearly a significant area of overlap is that we both want the fastest > possible operations on double arrays. I'd be delighted if we could leverage > flop to get the best possible implementations for core.matrix. > > Another potential area of collaboration is the planned NDArray > implementation. This will be a pure Clojure, NumPy-style, efficient > N-dimensional array implementation. Under the hood, this will need to run on > Java arrays. Dmitry Groshev is our GSoC student who will be working on this. These all sound like great directions to pursue. We'll be fleshing out our API for double arrays in the next week or so, and I'll invite you to check out what we've got once things are a bit more concrete -- we'd love comments at that point, and we can figure out next steps for collaboration then as well. Cheers, Jason > > > -- > -- > 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/LTtxhPxH_ws/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/groups/opt_out. > > -- -- 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/groups/opt_out.
