Sorry - pressed send before refreshing and didn't see your response.
Readability is a very subjective topic. I have an (possibly irrational)
aversion to anonymous fns when core fns solve the same problem, so I'm very
accustomed to reading things like (partial apply xxx). The perf issue would
definitely push me over, however.
On Sat, Aug 17, 2013 at 11:19 AM, David Chelimsky <dchelim...@gmail.com>wrote:
> Hey Steven, here's a variation of my first example that, I think, gets
> closer to what you're proposing (with maybe-add handled in-line):
>
> (defn to-consolidated-map [parts]
> (reduce (fn [h [k v]]
> (assoc h k (+ (get h k 0) v)))
> {}
> parts))
>
> Using assoc instead of update-in allows it to handle nils with a default
> value to get. All core lib fns. WDYT?
>
> Also, this:
>
> (defn to-consolidated-map [parts]
> (apply merge-with + (map (partial apply hash-map) parts)))
>
> or this variant:
>
> (defn to-consolidated-map [parts]
> (->> parts (map (partial apply hash-map)) (apply merge-with +))
>
> each use only core lib fns, which you say you're looking for. I find this
> less accidental-complexity-ish than the implementations that use reduce
> with a custom (anonymous) fn, which each require handling nil in some
> fashion. WDYT?
>
>
>
>
> On Sat, Aug 17, 2013 at 10:42 AM, Steven Degutis <sbdegu...@gmail.com>wrote:
>
>> Wow. Sorry for the awful formatting. Re-pasting it from Google Groups
>> (instead of email) to fix it:
>>
>> (def a [[:a 1] [:b 2] [:a 3]])
>>
>>
>>
>> (defn add-maybe [& nums]
>>
>> (->> nums
>>
>> (remove nil?)
>>
>> (reduce +)))
>>
>>
>>
>> (reduce (fn [m [k v]]
>>
>> (update-in m [k] add-maybe v))
>>
>> {}
>>
>> a)
>>
>>
>>
>> ;; => {:b 2, :a 4}
>>
>>
>> -Steven
>>
>> On Saturday, August 17, 2013 3:40:23 AM UTC-5, Steven Degutis wrote:
>>
>>> At first I came up with the same solution as your second one. But I
>>> couldn't help but feel that it wasn't descriptive enough. It felt too
>>> incidental-complexity-ish.
>>>
>>> To me, (into {} the-map) seems mostly right. But obviously it would just
>>> squash the values you need. So I figured it should just be modified a bit.
>>> Seeing as how it's really short for reduce conj, I figured conj was the
>>> place to swap out.
>>>
>>> Here's what I came up with:
>>>
>>> (def the-map [[:a 1] [:b 2] [:a 3]])
>>>
>>>
>>>
>>>
>>> (defn add-maybe [& nums]
>>>
>>>
>>> (->> nums
>>>
>>> (remove nil?)
>>>
>>>
>>> (reduce +)))
>>>
>>>
>>>
>>> (reduce (fn [m [k v]]
>>>
>>>
>>> (update-in m [k] add-maybe v))
>>>
>>>
>>> {}
>>>
>>> the-map)
>>>
>>>
>>>
>>> ;; => {:b 2, :a 4}
>>>
>>>
>>> But I don't really like the add-maybe function. It seems like I'm
>>> probably missing an opportunity for a core-lib function that I'm forgetting
>>> about. I really just wanted to have access to the original value, so I
>>> could do (or orig-value 0) and then just use + instead of add-maybe.
>>>
>>> -Steven
>>>
>>>
>>> On Fri, Aug 16, 2013 at 11:57 PM, David Chelimsky wrote:
>>>
>>>> I've got a vector of 2-element vectors e.g. [[:a 1] [:b 2]] where the
>>>> first val of any vec might appear in another vec e.g. [[:a 1] [:b 2] [:a
>>>> 3]]. I need a fn that will consolidate this into a hash-map with the vals
>>>> consolidated e.g.
>>>>
>>>> (to-consolidated-map [[:a 1] [:b 2] [:a 3]])
>>>> ; {:a 4 :b 2}
>>>>
>>>> I've got two candidate implementations and I'm curious which you like
>>>> better and why, or if I'm missing a better way:
>>>>
>>>> (defn to-consolidated-map [parts]
>>>> (reduce (fn [h [k v]]
>>>> (if (contains? h k)
>>>> (assoc h k (+ (k h) v))
>>>> (assoc h k v)))
>>>> {} parts))
>>>>
>>>> (defn to-consolidated-map [parts]
>>>> (->> parts
>>>> (group-by first)
>>>> (map (fn [[k v]] [k (->> v (map last) (reduce +))]))))
>>>>
>>>> TIA,
>>>> David
>>>>
>>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> 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 clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
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 clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
