Looks like Rich just chimed in with:
keys order == vals order == seq order
Matching Socks mailto:phill.w...@gmail.com
January 31, 2014 7:31 PM
Actually, http://dev.clojure.org/jira/browse/CLJ-1302 keys and vals
consistency not mentioned in docstring was declined, with the comment
The
Realistically, how many situations are there where running keys and vals
independently is preferable to running seq once and using the two element
vectors that returns?
Usually this way one can avoid walking the whole thing twice.
(into {} (map (fn [[k v]] [k (inc v)]) {:a 0 :b 1})) is
zipmap could also potentially use transients (which would be a nice
addition).
keys/vals are also lazy, so I would be surprised if there was any
performance
difference with walking the seq twice.
Thanks,
Ambrose
On Sun, Feb 2, 2014 at 11:35 AM, Justin Smith noisesm...@gmail.com wrote:
On 2 February 2014 04:54, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
zipmap could also potentially use transients (which would be a nice
addition).
My patch for this has been waiting in JIRA since end of May 2012:
http://dev.clojure.org/jira/browse/CLJ-1005
Cheers,
Michał
user (class (keys {:a 0 :b 1}))
clojure.lang.APersistentMap$KeySeq
Are you sure PersistentMap$KeySeq is lazy? I don't really get how a lazy
sequence over an associative would work in Clojure (at least as clojure
exists now).
Pardon my ignorance but if this is producing a lazy result, how is it
On 2 February 2014 05:14, Justin Smith noisesm...@gmail.com wrote:
Pardon my ignorance but if this is producing a lazy result, how is it
doing so?
https://github.com/clojure/clojure/blob/dff9600387b962f16fc78e6477e10e34651fd366/src/jvm/clojure/lang/APersistentMap.java#L134
APersistentMap's
Thanks Michał, voted.
Ambrose
On Sun, Feb 2, 2014 at 12:13 PM, Michał Marczyk michal.marc...@gmail.comwrote:
On 2 February 2014 04:54, Ambrose Bonnaire-Sergeant
abonnaireserge...@gmail.com wrote:
zipmap could also potentially use transients (which would be a nice
addition).
My patch
It also might help to notice KeySeq defines first/next, but never
explicitly walks the seq.
That's left to the user of the KeySeq.
Thanks,
Ambrose
On Sun, Feb 2, 2014 at 12:18 PM, Michał Marczyk michal.marc...@gmail.comwrote:
On 2 February 2014 05:14, Justin Smith noisesm...@gmail.com wrote:
There's no substitute for measurement.
(defn maptest [f]
(let [m (apply hash-map (range 40))]
(time (dotimes [_ 10] (f m)))
(f m)))
(maptest #(zipmap (keys %) (map inc (vals %
; Elapsed time: 1405.890766 msecs
;= {0 2, 32 34, 2 4, 34 36, 4 6, 36 38, 6 8, 38 40, 8 10, 10 12, 12
That doesn't mean that we're not walking the seq twice, however. keys and
vals work off of separate calls to seq on the map, which of necessity
produce distinct seq objects (otherwise traversing a seq over a map would
permanently increase its memory consumption).
On 2 February 2014 05:18, Michał
Excellent, thanks for the information.
I just did a benchmark of zipmap over keys and vals vs. into {} over a map,
and despite my intuition, they are actually nearly identical in
performance. So if zipmap were using transients zipmap with keys and vals
would actually be the better performing
I'd expect
(persistent!
(reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
(transient {})
input-map))
to be the fastest solution.
Cheers,
Michał
On 2 February 2014 05:30, Justin Smith noisesm...@gmail.com wrote:
Excellent, thanks for the information.
I just did a benchmark of
Oh, sorry, for some reason Gmail didn't alert me to some of the recent
messages coming in while I was viewing this thread.
On 2 February 2014 05:32, Michał Marczyk michal.marc...@gmail.com wrote:
I'd expect
(persistent!
(reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
(transient {})
In the same repl as the above benchmarks, and yes, this is definitely the
best so far. I'll have to remember reduce-kv for future usage.
user (crit/bench (persistent!
(reduce-kv (fn [acc k v] (assoc! acc k (inc v)))
(transient {})
Actually, http://dev.clojure.org/jira/browse/CLJ-1302 keys and vals
consistency not mentioned in docstring was declined, with the comment The
absence of this property in the docs is correct. You should not rely on
this.
On Wednesday, August 11, 2010 6:03:39 PM UTC-4, Chouser wrote:
On Wed,
On Wed, Aug 11, 2010 at 4:53 PM, Kent squi...@aol.com wrote:
Hi,
Is it safe to assume that the values returned from (keys mp) and (vals
mp) will be in the same order? In other words, will (zipmap (keys mp)
(vals mp)) always return mp?
My experience has been that this does work, and it seems
16 matches
Mail list logo
