3 ms·

Does the K solution handle non-unity values in the beginning of each sublist? e.g. ((1 "one")(2 "one")) should result in ((3 "one"))

maximus-decimus 3y ago
Bizarrely enough, that didn't seem to be a requirement. But no, it doesn't. It completely ignores the digit, just groups by the string and counts that. The problem is very weird and stupid though. The input is clearly logically a list of dictionaries with a string as a key and a count as the value. This is K, not Bash, you should be using a list of dictionaries, not a string. If you have that list (let's call is myList), in K you just need to sum the dictionaries together and it will automatically adds all the counts together. So the code would literally just be "+/myList".
maximus-decimus 3y ago
Bizarrely enough, that didn't seem to be a requirement. But no, it doesn't. It completely ignores the digit, just groups by the string and counts that. The problem is very weird and stupid though. The input is clearly logically a list of dictionaries with a string as a key and a count as the value. If you have that list (let's call is myList), in K you just need to sum the dictionaries together and it will automatically adds all the counts together. So the code would literally just be "+/myList". I would just convert the list of lists to a list of dictionaries and do that.
- aidenn0 3y ago
  I agree that the problem is weird and stupid. It does highlight a lack of dynamic grouping[1] in lisp iteration tools though; as TFA suggests, arbitrary grouping is done idiomatically in lisp using an explicit associative type (usually a hash-table). Even my contribution (using the SERIES library) keeps the hash-table explicit. I don't know how much of this is habit, how much is lisp programmers being control freaks, and how much of it is "If I need to do grouping, having the hash-table explicitly available will probably be needed at some point anyways" 1: Static grouping (i.e. where all group keys are known in advance) is trivial.

maximus-decimus 3y ago

Bizarrely enough, that didn't seem to be a requirement. But no, it doesn't. It completely ignores the digit, just groups by the string and counts that. The problem is very weird and stupid though. The input is clearly logically a list of dictionaries with a string as a key and a count as the value. This is K, not Bash, you should be using a list of dictionaries, not a string. If you have that list (let's call is myList), in K you just need to sum the dictionaries together and it will automatically adds all the counts together. So the code would literally just be "+/myList".

maximus-decimus 3y ago

Bizarrely enough, that didn't seem to be a requirement. But no, it doesn't. It completely ignores the digit, just groups by the string and counts that. The problem is very weird and stupid though. The input is clearly logically a list of dictionaries with a string as a key and a count as the value. If you have that list (let's call is myList), in K you just need to sum the dictionaries together and it will automatically adds all the counts together. So the code would literally just be "+/myList". I would just convert the list of lists to a list of dictionaries and do that.

aidenn0 3y ago
I agree that the problem is weird and stupid. It does highlight a lack of dynamic grouping[1] in lisp iteration tools though; as TFA suggests, arbitrary grouping is done idiomatically in lisp using an explicit associative type (usually a hash-table). Even my contribution (using the SERIES library) keeps the hash-table explicit. I don't know how much of this is habit, how much is lisp programmers being control freaks, and how much of it is "If I need to do grouping, having the hash-table explicitly available will probably be needed at some point anyways" 1: Static grouping (i.e. where all group keys are known in advance) is trivial.