ye thank you for clarification, i was reading it the "wrong way". I've compared the 2 newly filtered and sorted strings against each other and then returned the longest of the 2.
"func Add(int)" is invalid Go/Golang code - notice how every solution modifies the starting code.
The problem description uses the variable name "n", so the starting code should match the description:
func Add(n int) func(int)int {
// your code here
}
I can sympathize - I spent more time debugging the "msg" instruction than anything else. My first attempt using Python's "re" module didn't go well. I wound up writing custom code to deal with it.
As to finishing without an "end", yes that should cause -1 to be returned.
Any error or problem results in a -1 return value.
My goal was fast execution of the code, so I moved as much effort as possible into the parsing step. That was probably influenced by the prior kata in the series where some lines get executed hundreds of thousands of times. In situations like that, parsing pays a great dividend.
There isn't really a good phrase that covers both a switch statement and dictionary - delegating? Maybe the "delegating instructions" step, where an advantage of the dictionary to function approach is the speed of execution.
I didn't encounter debugging hell with the OOP approach, but maybe asserts in the right places and having an intuition for what could go wrong helped.
In case @qmstuart is curious about situations not covered in the tests:
The code after the label 'function' would run twice, and hitting ret a second time would be an error.
When the program stops without hitting an "end", it should return integer -1
fixed
Fixed
Wonders
ye thank you for clarification, i was reading it the "wrong way". I've compared the 2 newly filtered and sorted strings against each other and then returned the longest of the 2.
damn... Thank you.
Thank you for the clarification :)
Or replace 'previous' with 'preliminary'.
Too many solutions have passed for SPECS to be changed now.
No symbols.
Note the "Solution setup" contains invalid Go code - look at how every solution modifies it.
"func Add(int)" is invalid Go/Golang code - notice how every solution modifies the starting code.
The problem description uses the variable name "n", so the starting code should match the description:
func Add(n int) func(int)int {
// your code here
}
This comment is hidden because it contains spoiler information about the solution
I can sympathize - I spent more time debugging the "msg" instruction than anything else. My first attempt using Python's "re" module didn't go well. I wound up writing custom code to deal with it.
As to finishing without an "end", yes that should cause -1 to be returned.
Any error or problem results in a -1 return value.
My goal was fast execution of the code, so I moved as much effort as possible into the parsing step. That was probably influenced by the prior kata in the series where some lines get executed hundreds of thousands of times. In situations like that, parsing pays a great dividend.
There isn't really a good phrase that covers both a switch statement and dictionary - delegating? Maybe the "delegating instructions" step, where an advantage of the dictionary to function approach is the speed of execution.
I didn't encounter debugging hell with the OOP approach, but maybe asserts in the right places and having an intuition for what could go wrong helped.
The meaning of \n is undefined in this langauge - you're assuming it must become a newline.
In case @qmstuart is curious about situations not covered in the tests:
The code after the label 'function' would run twice, and hitting ret a second time would be an error.
When the program stops without hitting an "end", it should return integer -1
Loading more items...