I did my solutions at midnight last night, but I was surviving on very little sleep at the time, so the resulting code was below standard. I tried again this morning and felt better about it.
For anyone reading this, I'm still using the simple lines function from Day 1 which reads a file into a sequence of strings.
This is embarrassing code. I totally forgot about the frequencies function, which is why I used group-by followed by count. But the 2 filter operations in the final calculation meant that the results of the map get processed twice.
This time I accumulated the 2/3 count values while processing the list, so it only goes through it once.
Part 2
Since each element needs to be compared to every other element, I can't see any way around the O(n2 ) complexity. Of course, each element should only be compared to the ones after it, so as to avoid comparing each one twice (since comparing A/B has the same result as comparing B/A).
When doing list processing, the only ways I know to refer to everything following an element are by using indexes (yuck) or with a loop. Unfortunately, I got fixated on the loop construct, and nested it:
The other way you can tell that I wrote this on very little sleep was the use of ridiculously terse var names.
On reflection this morning, I realized that the inner loop should have been a some operation. This does a predicate test and terminates processing early, which is what I was doing manually with the inner loop.
Also, my close function has several issues. First is the name! I was thinking of "A is close to B", but when I saw it again this morning I realized that it's the same function name for closing a resource. Something else that bothers me is that it processes the entirety of each string before returning, when a false result can usuall terminate early. Finally, a minor issue is that the anonymous function #(when (= %1 %2) %1) would be more idiomatic to use a singleton set on %1 to compare to %2.
The nearly= function now returns a string, rather than the array of characters, but hasn't changed much. I was still unsatisfied with it not terminating the test early, so I rewrote it to be faster. However, the resulting code lacks any kind of elegance, and I'm not convinced that it's worth the effort:
I did my solutions at midnight last night, but I was surviving on very little sleep at the time, so the resulting code was below standard. I tried again this morning and felt better about it.
For anyone reading this, I'm still using the simple
lines
function from Day 1 which reads a file into a sequence of strings.Part 1
This was my solution last night:
This is embarrassing code. I totally forgot about the
frequencies
function, which is why I usedgroup-by
followed bycount
. But the 2filter
operations in the final calculation meant that the results of themap
get processed twice.My morning attempt fixed these:
This time I accumulated the 2/3 count values while processing the list, so it only goes through it once.
Part 2
Since each element needs to be compared to every other element, I can't see any way around the O(n2 ) complexity. Of course, each element should only be compared to the ones after it, so as to avoid comparing each one twice (since comparing A/B has the same result as comparing B/A).
When doing list processing, the only ways I know to refer to everything following an element are by using indexes (yuck) or with a
loop
. Unfortunately, I got fixated on the loop construct, and nested it:The other way you can tell that I wrote this on very little sleep was the use of ridiculously terse var names.
On reflection this morning, I realized that the inner loop should have been a
some
operation. This does a predicate test and terminates processing early, which is what I was doing manually with the innerloop
.Also, my
close
function has several issues. First is the name! I was thinking of "A is close to B", but when I saw it again this morning I realized that it's the same function name for closing a resource. Something else that bothers me is that it processes the entirety of each string before returning, when a false result can usuall terminate early. Finally, a minor issue is that the anonymous function#(when (= %1 %2) %1)
would be more idiomatic to use a singleton set on%1
to compare to%2
.The
nearly=
function now returns a string, rather than the array of characters, but hasn't changed much. I was still unsatisfied with it not terminating the test early, so I rewrote it to be faster. However, the resulting code lacks any kind of elegance, and I'm not convinced that it's worth the effort:Hopefully I'll get some sleep before attempting day 3. 😊