Can somebody explain why it’s so common to take the closure out of the function?
I.e., .reduce(into: [String]()) { ... } as opposed to .reduce(into: [String](), { ... })
.reduce(into: [String]()) { ... }
.reduce(into: [String](), { ... })
While that’s helpful in this specific situation, I don’t think that’s a recommended way of using extension.
extension
Love your solution with the identity function, very elegant.
Can someone explain why using enumerate is faster than range(len(arr)) then using array indexing?
enumerate
range(len(arr))
This runs around 10x faster than the set comparison solution. They are also not complete passes.
This is by far the best implementation.
That makes sense, thank you so much! I just started learning C++.
I see that it happens with input: "one hundred" in function two_digit_parse in line auto word = group.front(), because group is empty.
"one hundred"
two_digit_parse
auto word = group.front()
This comment is hidden because it contains spoiler information about the solution
No tests of unmatched brackets like such: "]["
Can somebody explain why it’s so common to take the closure out of the function?
I.e.,
.reduce(into: [String]()) { ... }as opposed to.reduce(into: [String](), { ... })While that’s helpful in this specific situation, I don’t think that’s a recommended way of using
extension.Love your solution with the identity function, very elegant.
Can someone explain why using
enumerateis faster thanrange(len(arr))then using array indexing?This runs around 10x faster than the set comparison solution. They are also not complete passes.
This is by far the best implementation.
That makes sense, thank you so much! I just started learning C++.
I see that it happens with input:
"one hundred"in functiontwo_digit_parsein lineauto word = group.front(), because group is empty.This comment is hidden because it contains spoiler information about the solution
This comment is hidden because it contains spoiler information about the solution
No tests of unmatched brackets like such: "]["