On Thursday, April 11, 2013 10:03:51 AM UTC-3, Gary Verhaegen wrote:
>
> The way the f function is written, there is no way to run it in
> parallel, since it needs the previous answer. The best you can hope
> for is to use two cores, one for a and one for b.
>
That was my goal at first, but your comment made me think that there _is_ a
way to compute the sequence in parallel: Substituting the expression in
itself I can compute x_{n+2} from x_n; this way I can compute the even and
odd terms in parallel for each sequence. This can be extended to compute
x_{n+4} from x_n, allowing to compute 4 terms in parallel for each
sequence, thus occupying 8 cores. The calculation complexity will rise for
each term, though, so some performance analysis is needed to find the best
approach.
> What you can do if you want to make it parallel is use the closed
> form, and create a lazy list of that closed form for each iteration.
> Something along the lines of (doall (pmap #(- (f a %) (f b %))
> (range))), where (f a n) yields the value for the nth iteration with a
> starting value of a, using the closed form. If you know in advance how
> many steps you want, you could have even more parallelism with a
> reducer-based map on a vector of n's.
>
> Unfortunately, I personally do not know of an arbitrary-precision
> implementation of sin, asin and sqrt (though I suppose they would not
> be *that* hard to implement).
>
It's impossible to implement such functions using rational arithmetic, it
would be necessary some serious symbolic packages à la Mathematica.
> On 11 April 2013 09:27, Michael Gardner <[email protected] <javascript:>>
> wrote:
> > On Apr 10, 2013, at 21:46 , Ulises <[email protected] <javascript:>>
> wrote:
> >
> >> Have you tried replacing all your calls to map for pmap yet?
> >
> > That will not work. He'll need to rearrange his algorithm to something
> like this before pmap will help:
> >
> > (defn iterated-difference [f a b]
> > "Yields a lazy seq of the differences between (iterate f a) and
> (iterate f b)."
> > (cons (doto (double (- b a)) println)
> > (lazy-seq (apply iterated-difference f (pmap f [a b])))))
> >
> > Might need to wrap this in a (doall …) or such to see progressive output
> from the println.
>
Both suggestions seems to kind-of have worked, but for the most part just
one core is used. The problem is that the calculation for a is much faster
than the calculation for b, and the iteration hangs on that. Also, the time
complexity seems to be exponential!
(defn test-f [n x] (double (last (take n (iterate f x)))))
(doall (for [n (range 10 18)] [n (time (test-f n a)]))
;"Elapsed time: 1.550121 msecs"
;"Elapsed time: 1.081994 msecs"
;"Elapsed time: 3.278447 msecs"
;"Elapsed time: 11.228025 msecs"
;"Elapsed time: 22.27068 msecs"
;"Elapsed time: 90.175714 msecs"
;"Elapsed time: 305.631558 msecs"
;"Elapsed time: 1196.748514 msecs"
;(...)
(doall (for [n (range 10 18)] [n (time (test-f n b))]))
;"Elapsed time: 197.777474 msecs"
;"Elapsed time: 769.693374 msecs"
;"Elapsed time: 3038.191752 msecs"
;"Elapsed time: 12228.269874 msecs"
;"Elapsed time: 49325.26163 msecs"
;"Elapsed time: 197819.804965 msecs"
;^C (life is too short)
This is just to be expected as the denominator doubles every step, although
the exponent seems close to 4... I guess I'll need plenty of time to reach
100 steps.
Thanks for your suggestions, if I ever get some results I'll post it here.
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
