I haven’t done this puzzle in a while but surely a drop from 5 to 2 should be registered as -3, not -4 ?
In the examples there’s a drop from 5 to 1 marked -4.
Yes, my mistake, the drop from 5 to 1 should be -4. Then, why doesn’t that seem to get recognized by the tester?
I actually took my program and eliminated the reading in of input values. I set the values array to { 4 3 5 2 1 6 } and then ran my program. The answer was -4.
So although my program gives the correct answer in this case, the test validator does not match my results.
When you split your line into integers, do you get an erroneous last element ? We might have accidentally slipped in an invisible character at the end of that line. If not, feel free to send your code to coders@codingame.com so I can have a closer look at it.
As reported in main puzzle topic, first validation test input says there are 6 numbers but only 5 are given on the next line. I can confirm this behaviour as I was able to validate first test in PHP by:
outputting -$N + 2
outputting -count($numbers) + 1
So depending on the language and the algorithm, there might be indeed an erroneous last element because it doesn’t exist in input.
I’m still seeing this issue. My code outputs a value of -4 for the first test, yet it’s still marked as incorrect even though clearly the max drop is 5 -> 1 == -4.
What I eventually did was I submitted and the test failed. However, then I press the “Try Again” button and all of the tests pass. This was my solution.
I have a problem with this puzzle in Go.
For ‘example 5’ the input seems to be empty, instead of the long list of big numbers expected.
In example 1 - 4 the input is there.
I don’t think it’s the same problem, since it works for example 1 - 4 with the same code.
The difference is that there’s a lot more data in example 5, so maybe it can’t handle that.
When i do this on example 5, i get 99999, so the input is here.
Sometimes, when your code is to slow, you’ll see no output. Thatjust means that you got to speed up your code to not time out.
var n int
scanner.Scan()
fmt.Sscan(scanner.Text(),&n)
fmt.Fprintf(os.Stderr, "N: %d\n", n)
scanner.Scan()
input := scanner.Text()
fmt.Fprintf(os.Stderr, "Input: %s\n", input)
fmt.Println("answer") // Write answer to stdout
}[/code]
Output for example 1:
N: 6
Input: 3 2 4 2 1 5
Output for example 5:
N: 99999
Input:
So the logic to get the data should be fine, and since I don’t do any calculations or anything, the timeout problem should not be in my code.
For some reason the second line of input is never read properly.
ok so i tried again, and oddly, when i did this code:
func main() {
scanner := bufio.NewScanner(os.Stdin)
var n int
scanner.Scan()
fmt.Sscan(scanner.Text(),&n)
scanner.Scan()
vs := scanner.Text()
fmt.Fprintln(os.Stderr, vs)
scanner.Scan()
mm := scanner.Text()
fmt.Fprintln(os.Stderr, mm)
}
It worked for example 5. I dunno why but maybe it’s because you have to ignore the carriage return:
int main()
{
int n;
cin >> n; cin.ignore();
string vs;
getline(cin, vs);
// Write an action using cout. DON'T FORGET THE "<< endl"
// To debug: cerr << "Debug messages..." << endl;
cout << "answer" << endl;
}
The important part here is cin.ignore();, is there an equivalent in Go?
I thought I tried making two scan calls to scanner, but apparently I made a mistake.
Your example get the text.
Well sort of, if you add fmt.Fprintln(os.Stderr, len(mm)) to your example you see that it only have 65536 characters. So there’s a 16-bit limitation somewhere here?
I’m pretty new to Go, so I can’t answer your question regarding cin.ignore.