Thank you very much for your replies. I will definitely take a look at
core.matrix. I really hate the fact that I had to use Java arrays to make
it fast. I'll take a look at transducers as well.
Kind regards,
Jose.
On Monday, December 22, 2014 7:09:27 PM UTC-5, Christopher Small wrote:
>
> I'
I'll second the use of core.matrix. It's a wonderful, idiomatic, fast
library, and I hope to see folks continue to rally around it.
On Monday, December 22, 2014 3:47:59 AM UTC-7, Mikera wrote:
>
> For most array operations (e.g. dot products on vectors), I strongly
> recommend trying out the re
For most array operations (e.g. dot products on vectors), I strongly
recommend trying out the recent core.matrix implementations. We've put a
lot of effort into fast implementations and a nice clean Clojure API so I'd
love to see them used where it makes sense!
For example vectorz-clj can be ov
Interesting read Jose, thanks!
It might be interesting to try a transducer on
(defn dot-prod
"Returns the dot product of two vectors"
[v1 v2]
(reduce + (map * v1 v2)))
if you can get your hands on the 1.7 alpha and the time and inclination to
do it. Transducers have shown to be faster t
Regarding the speed optimizations, execution time for a given model was
reduced from 2735 seconds to 70 seconds, over several versions by doing
several optimizations.
The same calculation implemented in C# takes 12 seconds using the same
computer and OS. Maybe the Clojure code can still be imp
Hi everyone:
Sorry that it has taken so long. I've just released the software in GitHub
under the EPL. It can be found at:
https://github.com/iosephus/gema
Kind regards,
Jose.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
On Tuesday, June 3, 2014 12:46:55 PM UTC-5, Mars0i wrote:
>
> (def ones (doall (repeat 1000 1)))
> (bench (def _ (doall (map rand ones ; 189 microseconds average time
> (bench (def _ (doall (pmap rand ones ; 948 microseconds average time
>
For the record, I worried later that rand was
Will take a look at the bigml/sampling library...
On Tuesday, June 3, 2014 7:52:06 PM UTC-4, Jose M. Perez Sanchez wrote:
>
>
> Thank you very much. I'm using the Colt random number generator directly.
> I've managed to reduce computing time by orders of magnitude using type
> hints and java ar
Thank you very much. I'm using the Colt random number generator directly.
I've managed to reduce computing time by orders of magnitude using type
hints and java arrays in some critical parts. I haven't had the time to
write a report on this for the list, since have been busy with other
project
Jose,
This is an old thread, and whatever problems you might be dealing with now,
they're probably not the same ones as when the thread was active. However,
I think that if parallel code uses the built-in Clojure random number
functions, there is probably a bottleneck in access to the RNG. Wi
Yes, the step extract function encodes the total number of steps and any
intermediate steps whose values are to be saved.
I did the following changes to the code:
1 - Store results locally in the threads and return them when the thread
function exits, instead of using global vector. This does n
Hi Jose,
I think you should try making the core iteration purely functional,
meaning no agents, atoms, or side effecting functions like the random
generator.
I assume the number of steps you evolve the particle is encoded in
step-extract-fn?
What you probably want is something like
(loop [i 0
Hi Andy, cej38, kovas:
Thanks for the replies. I plan to release the whole code soon (waiting for
institutional authorization).
I do use lazyness both within the move function to select the allowed
random displacements and when iterating the move function to generate the
trajectory. Lazy struc
Sounds like some form of overhead is dominating the computation. How
are the infinite sequences being consumed? Is it 1 thread per
sequence? How compute-intensive is (move particle) ? What kind of
numbers of are talking about in terms of steps, particles?
If move is fast, you probably need to batc
It is hard to say where the root of your problem lies without looking at
the code more. I would look closely at laziness. I find that lazy
evaluation really kills parallelization.
On Friday, November 8, 2013 4:42:11 PM UTC-5, Jose M. Perez Sanchez wrote:
>
> Hello everyone:
>
> This is my f
Hi Andy:
Yes, this breaks embarrassing parallelism indeed. When the calculations are
done for real this isn't a problem though, because these conj operations to
the global list would happen sporadically (in average once every couple of
seconds or so) so the probability of a thread waiting for
Jose:
On re-reading your original post, I noticed one statement you made that may
be of interest: "The resulting vector for each particle is then added
(conj) to a global vector for latter storage."
Do you mean that there is a single global vector that is conj'd onto by all
N threads? Is this ve
Hi Andy:
Thanks a lot for your reply. I'll do more careful testing in the very near
future and there is surely a lot to optimize in my code. I must say I did
expect computing speed reduction coming from an already optimized codebase
with the perfomance critical parts written in C, and there is
Jose:
I am not aware of any conclusive explanation for the issue, and would love
to know one if anyone finds out.
At least in the case of that program mentioned in the other discussion
thread, much better speedup was achieved running N different JVM processes,
each single-threaded, on a machine w
Hello everyone:
This is my first post here. I'm a researcher writing a numerical simulation
software in Clojure. Actually, I'm porting an app a coworker and I wrote in
C/Python (called GEMA) to Clojure: The app has been in use for a while at
our group, but became very difficult to maintain due
(Thanks Konrad; a nice summary.)
On Thursday, March 7, 2013 7:28:57 AM UTC, Konrad Hinsen wrote:
>
> My latest article in "Computing in Science and Engineering", with example
> code in Clojure, in free access for a while:
>
>A Glimpse of the Future of Scientific Programming
>http://bit.
My latest article in "Computing in Science and Engineering", with example
code in Clojure, in free access for a while:
A Glimpse of the Future of Scientific Programming
http://bit.ly/15yeIjw
Konrad.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" gr
On 29.10.2009, at 13:48, John Harrop wrote:
> One issue with using multimethods is the resolution overhead. I
> don't think the JIT can optimize this to the extent it can optimize
> a normal polymorphic Java call.
That's worth exploring - while keeping in mind that the JIT improves
all the
On 29.10.2009, at 14:01, Rock wrote:
>>> Suppose we're dealing with rank n objects. Do you think it
>>> would be an easy task to figure all that out dealing with nested
>>> vectors?
>>
>> If you can assume the array is well-formed, it is rather easy.
>> Otherwise it isn't.
>
> Can you give an exa
> I didn't address such issues because there is no point in discussing
> them before making the fundamental decision whether to use an abstract
> or an exposed data type for array data. That choice dictates the
> priorities for everything that follows.
Yes, I agree.
> > Suppose we're deal
On Thu, Oct 29, 2009 at 4:49 AM, Konrad Hinsen
wrote:
> On 28 Oct 2009, at 22:21, Rock wrote:
> > I honestly prefer your first case scenario. Seems much more efficient,
> > less resource-consuming, and just straightforward. But I really would
> > like to know what your preference is. If you had to
On 28 Oct 2009, at 22:21, Rock wrote:
> Your analysis is crystal clear and very helpful Konrad. But you
> haven't addressed the issue of dealing with useful information
> regarding the data structure itself. What if, for example, a function
> wanted to know the rank and dimensions of a multidimen
maps could also be an option.
you can use vectors of ints as keys. (and you can stick dimensions and
such in there with keywords)
i'm not sure how that compares to nested vectors for perforance. you
have the overhead of the hash function, but you don't have any
nesting.
it's also pretty handy if
Your analysis is crystal clear and very helpful Konrad. But you
haven't addressed the issue of dealing with useful information
regarding the data structure itself. What if, for example, a function
wanted to know the rank and dimensions of a multidimensional array it
was being passed, and that arra
On 27.10.2009, at 18:07, Rock wrote:
> these things. Why? Because they're just that: nested vectors. They're
> not truly multidimensional vectors, and the more I think about them,
> the more they really suck from that point of view. For instance, first
> of all they're not that safe to use (for t
Good question.
Let's see. Now, nested vectors ... I don't like them too much for
these things. Why? Because they're just that: nested vectors. They're
not truly multidimensional vectors, and the more I think about them,
the more they really suck from that point of view. For instance, first
of all
On 27.10.2009, at 17:46, Rock wrote:
> What if we created a structmap (a sort of class), where we have a
> flattened out one-dimensional clojure vector containing all the data
> of our potentially multidimensional (rank n) array, together with its
> dimensions and possibly other info? I believe t
But then again ...
Thinking this over, one idea that comes to mind:
What if we created a structmap (a sort of class), where we have a
flattened out one-dimensional clojure vector containing all the data
of our potentially multidimensional (rank n) array, together with its
dimensions and possibly
I agree, use Clojure vectors whenever it's feasible. Even within
Incanter, which uses Parallel Colt extensively, I try never to convert
Clojure vectors into Colt vectors/matrices unless it's absolutely
necessary.
David
On Oct 26, 2:23 pm, Konrad Hinsen wrote:
> On 26 Oct 2009, at 17:14, Rock
On 26 Oct 2009, at 17:14, Rock wrote:
> Just one more thing. It's still not really clear to me if I am better
> off using Java arrays (make-array ...) or clojure vectors especially
> when dealing with multidimensional arrays. I know that if use Java
> libraries such as Colt, I have no choice. But
ully Clojure's flexibility will soon allow it to become a matrix-
> > oriented language as well, if only to express linear-algebra-type
> > ideas (which are stored under the hood in whatever format or system
> > needed---Colt, CDF, Mathematica arrays even!).
> >
> >
needs.
> Hopefully Clojure's flexibility will soon allow it to become a matrix-
> oriented language as well, if only to express linear-algebra-type
> ideas (which are stored under the hood in whatever format or system
> needed---Colt, CDF, Mathematica arrays even!).
>
> I wanted t
language as well, if only to express linear-algebra-type
ideas (which are stored under the hood in whatever format or system
needed---Colt, CDF, Mathematica arrays even!).
I wanted to let you know that probably for every person who asks about
Clojure scientific computing, there's a number o
Thanks for your replies. You've been very helpful.
On Oct 24, 1:36 pm, Konrad Hinsen wrote:
> On 23 Oct 2009, at 22:00, Konrad Hinsen wrote:
>
> > For matrix computations and linear algebra, your best choice is
> > probably
> > the Colt library developed at CERN, or the somewhat parallelized
On 23 Oct 2009, at 22:00, Konrad Hinsen wrote:
> For matrix computations and linear algebra, your best choice is
> probably
> the Colt library developed at CERN, or the somewhat parallelized
> version called Parallel Colt. Colt has arrays up to three dimensions
> for
> a couple of data types
lojure's awesome features in,
say, concurrency, *plus* array processing.
Garth
On Fri, Oct 23, 2009 at 2:01 PM, Rock wrote:
>
> What if I wanted to use Clojure for scientific computing, and in
> particular for doing linear algebra and matrix computations a la
> MATLAB?
>
&g
Rock a écrit :
> What if I wanted to use Clojure for scientific computing, and in
> particular for doing linear algebra and matrix computations a la
> MATLAB?
>
> What would my options be for representing matrices, not to mention,
> especially, MULTIDIMENSIONAL ARRAYS?
>
&
What if I wanted to use Clojure for scientific computing, and in
particular for doing linear algebra and matrix computations a la
MATLAB?
What would my options be for representing matrices, not to mention,
especially, MULTIDIMENSIONAL ARRAYS?
Would java arrays be the way to go, or nested
43 matches
Mail list logo
