I do not believe this is the right approach to the problem, but I do appreciate the problem you're trying to solve here. However, in my opinion - Clojure libraries shouldn't be trying to reinvent the wheel. If your goal is to expose a better interface for vector arithmetic in Clojure - write a library that does that really well.<p>But if your primary concern is performance, please don't roll your own vector or matrix "native" interface. You will certainly never come close in speed to what has come before (BLAS implementations galore, et al). Also it's just a lot of work that is basically keeping you from working on the higher order problems out there that we desperately need to tackle.<p>If your goal is more "Clojurey" syntax then just spend a day or two wrapping the functions you want over a tried and tested numerics implementation. Additionally, there is likely a pre-existing Java wrapper which does just that for whatever you need considering that Java is still beloved by university professors, a key demographic for fast math libraries.<p>On the other hand, I think Vertigo ( github: <a href="https://github.com/ztellman/vertigo" rel="nofollow">https://github.com/ztellman/vertigo</a> ) is taking a very interesting approach to the Clojure->Native problem, which I believe might be of use to any library wanting to bring performant numerics to Clojure. Unfortunately, ztellman has deprecated his OpenGL and OpenCL libraries, but I think that Vertigo in combination with OpenCL and the kernels courtesy of clMAGMA would be fantastic.
<p><pre><code> All arithmetic operations on these boxed objects are
significantly slower than on their primitive counterparts.
This implementation also creates an unnecessary intermediate sequence
(the result of the map), rather than just summing
the numbers directly.
</code></pre>
Clojure's Reducers framework might address the described issues in a future when, in Rich's words, "those IFn.LLL, DDD etc primitive-taking function interfaces spring to life". For now, they only solve the intermediate-collections part of the problem.
Looks awesome! One data issue I've seen go relatively unaddressed in the Clojure community is the serialization of big matrices and arrays.<p>There's a start on a clojure hdf5 (hdf5 is a container format common in scientific circles) implementation, but it's a long ways from done. <a href="https://github.com/clojure-numerics/clj-hdf5" rel="nofollow">https://github.com/clojure-numerics/clj-hdf5</a> I'm not the author, but I am the negligent steward.<p>I'd love it if someone smarter / better at Clojure than me was interested in helping to think about useful, idiomatic high-level abstractions on top this high-performance data store.<p>PyTables does a great job of making gobs of hdf5 data easy to work with for analysts--I'm just too novice at Clojure/FP to know what is a reasonable analogue for Clojure.
Love the project et. all, this would be very helpful!<p>I have to comment on the name as well... brilliant. Kudos for something creative that has already stuck firmly in my mind.
Cool library, can imagine how moving away from boxing / unboxing can be a huge boost for them.<p>I've been looking for something that gave SIMD intrinsics to Java programmers - does anyone know if such a thing exists? Could be a nice addition to this lib.
What brought you to develop this library rather than relying on Incanter/Colt?
The scope of HipHip seems different, of course, but there is enough of an overlap to warrant the question.
Did you guys look at the core.matrix API?<p><a href="https://github.com/mikera/matrix-api" rel="nofollow">https://github.com/mikera/matrix-api</a>
One thing I've found is that with macros, it can actually be easier to write performant primitive-reliant code. Still not up to Common Lisp standards, but much better than, eg, having to use a scripting language to generate all the primitive specializations of your data structure, like Trove and Fastutil do.
Having written my own naive Clojure dot product, I can definitely appreciate what you guys have done!<p>Any plans to attack sparse vectors? Performance on the sparse vector operations I wrote was poor, but being new to Clojure it wasn't a great implementation.