Yeah, I totally agree that using core fns instead of anonymous fns makes
code way more readable and easier to mentally scan. The main reason I
suggested the anonymous function was for performance, which is probably
premature-optimization at this point. But I think I agree with you and Jay,
that short one is probably best.
Also I agree that your solution with (get) is better than the (update-in)
version I had for the reasons you mentioned.
-Steven
On Sat, Aug 17, 2013 at 4:28 AM, David Chelimsky <dchelim...@gmail.com>wrote:
> 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.
>
--
--
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.
