Here are some potentially interesting observations. First, as similar
lazy and eager versions as I could come up with:
(defn flatten-maps-lazy [coll]
(lazy-seq
(when-let [s (seq coll)]
(let [m (first s)]
(cons (dissoc m :c)
(flatten-maps-lazy
(con
2011/4/14 Meikel Brandmeyer :
> Hi,
>
> On 14 Apr., 11:35, Laurent PETIT wrote:
>
>> I don't understand either.
>> Anyway, if there is no flaw in the tests, this could end as a good
>> example of where premature optimization (of CPU at least) via recur
>> does not get the expected result !
>
> Alw
Hi,
On 14 Apr., 11:35, Laurent PETIT wrote:
> I don't understand either.
> Anyway, if there is no flaw in the tests, this could end as a good
> example of where premature optimization (of CPU at least) via recur
> does not get the expected result !
Always prove your assumptions. But I'm still s
2011/4/14 Meikel Brandmeyer :
> Hi again,
>
> On 14 Apr., 09:42, Laurent PETIT wrote:
>
>> What could explain the result of your tests ? (I'm really curious !)
>
> On the other hand the lazy version really just creates a simple linked
> list with some fast boilerplate concerning the laziness. The
Hi again,
On 14 Apr., 09:42, Laurent PETIT wrote:
> What could explain the result of your tests ? (I'm really curious !)
On the other hand the lazy version really just creates a simple linked
list with some fast boilerplate concerning the laziness. The vectors
however *are* more involved to con
Hi Laurent,
On 14 Apr., 09:42, Laurent PETIT wrote:
> Doesn't it seem counter intuitive to you that the lazy version is the
> fastest ?
>
> What could explain the result of your tests ? (I'm really curious !)
This is exactly the question I had earlier in this thread. :) I was
also surprised by
And more numbers. d-small does not contain vectors with more than 50
elements, so the unrolled version should always hit a special case in
this run. However it's still twice as slow as the eager versions. The
lazy version is still the fastest.
user=> (bench (doall (flatten-maps d-small)))
Evaluati
Hi,
On 14 Apr., 01:18, Kevin Downey wrote:
> I beg your pardon, if you don't understand then it must have been sent
> to you in error, please accept my apologies.
I'm sorry. I was confused. Here a new set of measurements with
different input and different machine. Including your unrolled
versio
I beg your pardon, if you don't understand then it must have been sent
to you in error, please accept my apologies.
On a side note: what does "this asian trait" have to do with anything?
On Wed, Apr 13, 2011 at 3:00 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 13.04.2011 um 23:44 schrieb Kevin Down
Hi,
Am 13.04.2011 um 23:44 schrieb Kevin Downey:
> https://gist.github.com/918487
I never understood this asian trait of pointing to something and then leaving
the other without clue. Do you care to enlighten me, what I'm missing?
Sincerely
Meikel
--
You received this message because you are
https://gist.github.com/918487
On Wed, Apr 13, 2011 at 11:56 AM, Meikel Brandmeyer wrote:
> Hmm…
>
> I did the following timings with criterium. d is a random data structure
> generated by virtue of the following function:
>
> user=> (defn data
> [size]
> (let [l (rand-int size)
Hmm…
I did the following timings with criterium. d is a random data structure
generated by virtue of the following function:
user=> (defn data
[size]
(let [l (rand-int size)
l2 (/ l 2)]
(repeatedly l #(array-map :a 1 :b 2 :c (vec (data l2))
The t
On 13 abr, 20:14, Alex Robbins wrote:
> That has tricked me before. The lazy one is fastest because all you
> are timing is the creation of the lazy seq, not its realization. Wrap
> the lazy seq in a doall inside the time macro.
Didn't know. Thanks !!
Now the timing of the lazy one is clearly
That has tricked me before. The lazy one is fastest because all you
are timing is the creation of the lazy seq, not its realization. Wrap
the lazy seq in a doall inside the time macro.
On Wed, Apr 13, 2011 at 12:59 PM, babui wrote:
> I was asking because my timings show that the lazy version is t
I was asking because my timings show that the lazy version is the
fastest one.
My (very simple & stupid) test is:
(defn flatten-maps
"The original one"
)
(defn flatten-maps-lazy
"The lazy one"
)
(defn flatten-maps-eager
"The eager one"
)
(defn flatten-maps-r
(time (...)) I guess.
http://clojuredocs.org/clojure_core/clojure.core/time
On Wed, Apr 13, 2011 at 6:38 PM, babui wrote:
> A solution using recur:
>
> (defn flatten-maps-recur
> ([ms] (flatten-maps-recur ms ()))
> ([ms fl] (if-let [[f & r] (seq ms)]
> (recur (concat
A solution using recur:
(defn flatten-maps-recur
([ms] (flatten-maps-recur ms ()))
([ms fl] (if-let [[f & r] (seq ms)]
(recur (concat (get f :c) r) (cons (dissoc f :c)
fl))
fl)))
Please, can you publish how are you doing your timings?
Thanks,
JM
On Wed, Apr 13, 2011 at 8:19 PM, Meikel Brandmeyer wrote:
> Did you also check the eager one?
Yes, I did. That one was much faster but still took double the time than mine.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the
Hi,
On 13 Apr., 16:13, Baishampayan Ghose wrote:
> Sorry, I checked it with incorrect data. Your solution works just
> fine, only that it's slower than mine (don't know why).
Did you also check the eager one?
Sincerely
Meikel
--
You received this message because you are subscribed to the Goo
On Wed, Apr 13, 2011 at 6:04 PM, Meikel Brandmeyer wrote:
> Both work for me, although in the flatten-maps-lazy there is a typo in
> the recursive call. It should be named flatten-maps-lazy there, too.
Sorry, I checked it with incorrect data. Your solution works just
fine, only that it's slower t
Hi,
On 13 Apr., 14:25, Baishampayan Ghose wrote:
> By the way, both of your functions raised ClassCastException.
Both work for me, although in the flatten-maps-lazy there is a typo in
the recursive call. It should be named flatten-maps-lazy there, too.
user=> (defn flatten-maps-lazy
[coll]
On Wed, Apr 13, 2011 at 4:42 PM, Meikel Brandmeyer wrote:
> However your specification was not very clear how the ordering of the
> flatten should be. The above reflects the intent as far as I
> understood it. Your implementation was also not clear because you mix
> conj with vectors and sequences
Hi,
haha! Golf! I haven't tested the speed, but this should be straight-
forward:
(defn flatten-maps-lazy
[coll]
(lazy-seq
(when-let [s (seq coll)]
(let [m (first s)]
(cons (dissoc m :c) (flatten-maps (concat (get m :c) (rest
s
However your specification was not ver
Hi,
I have a peculiar sequence of nested maps which have the following structure -
{:a 1 :b 1 :c []}
The keys :a & :b always have scalar values but the :c key can have
either an empty vector or a vector of maps of the same kind. For
example -
{:a 1 :b 1 :c [{:a 1 :b 1 :c [{:a 1 :b 1 :c []}]} {:
24 matches
Mail list logo
