Clojure Functions added

[koustuvsinha]

Following functions have been added along with tests :

• distinct
• rand-nth
• get-in
• assoc-in

Please review. More functions will be added in this PR as per #10

[vickychijwani]

Looks great, thanks! Will go over the code shortly to give feedback.

[vickychijwani]

I've added some comments on the code for distinct. Let me know if you run into issues.

[koustuvsinha]

Made the required changes!

[koustuvsinha]

Dont merge this PR yet, want to implement a few more functionalities as well ! Need a pointer on how to implement frequencies though. Should I use the map reduce way to count the frequencies of elements or is there any other way to do so?

[vickychijwani]

Here's some info to help you choose the right assertion for collections. Collections can be vectors, lists, seqs, JS arrays, strings, sets, or maps.

• seqable is true for all collections. I should rename this to assertions.collection.
• sequential is true for vectors, lists, seqs, JS arrays, and strings (i.e., all ordered collections). Appropriate for functions which accept any collection that supports nth. I guess I should just rename sequential to ordered to ease the confusion.
• stack is true for vectors and lists. Meant for stack operations (pop, peek, etc).
• associative is true for maps and vectors (vectors associate indices with values).
• associativeOrSet is true for maps, vectors, or sets. Be sure whether you need this or the previous one.
• map is true for maps (duh).

Hope this helps!

[vickychijwani]

Map-reduce should work fine for frequencies. You could also use core.clj_$__$GT_js(core.group_$_by(...)) followed by lodash's mapValues ;)

[koustuvsinha]

Got the solution by two ways eventually :

• core.js_$__$GT_clj (_.countBy core.clj_$__$GT_js(coll), _.identity())
• By your hint - core.js_$__$GT_clj _.mapValues core.clj_$__$GT_js(core.group_$_by(m.identity, coll)), (list) -> m.count list

Both the solutions arrive to same conclusion. However have an issue :

• for (frequencies [1 2 1 1]), clojure returns {1 3, 2 1} while both of my solutions return {"1" 3, "2" 1}, since by converting from clojure to js and vice versa, the keys are converted to strings. Should it be an issue? If so, how to tackle it?

[vickychijwani]

Hmm, you're right, that is a problem. I hadn't thought of that. Also the calls to js->clj and vice versa will surely affect performance. I think we can avoid the issue altogether by working purely using Clojure functions:

core.into(core.hash_$_map(),
  core.map(
    ((kv) -> core.vector(core.key(kv), core.count(core.val(kv)))),
    core.group_$_by(core.identity, coll))

[koustuvsinha]

ok, will try that and post the results soon

[koustuvsinha]

yes, working great! :) now, what are the use cases for frequencies to fail, which I need to add in test cases (apart from arity check)? Since nothing extra as such is mentioned in official docs

[vickychijwani]

Just add any kind of test for correct arity but wrong type of argument. For example, (frequencies 1) should throw because 1 is not a collection. It ensures that we haven't forgotten to add a type assertion to the function.

[koustuvsinha]

Done. Now you can review and merge this PR! :)

[vickychijwani]

Awesome work, @koustuvsinha! Thanks for tackling a bunch of these!

[koustuvsinha]

@vickychijwani awesome work in adding Travis CI :+1: