It would be nice if errors like "failed to flood correctly" were accompanied by the source data that the algorithm failed on. Not only does it give something more direct to fix, it also lets you check that you're interpreting the source data in the right way.
I'm assuming that an out-of-cycles error would be reported differently already.
Flash Flood
If you used any no-op space instructions, it could be an extra space added to the beginning/middle of your program code which throws the instruction addresses off by one.gfoot wrote:Hmm, it's now just telling me that my program text is incorrect, even when it's the same program that it previously reported had failed to fill properly. Is it possible that something is wrong with the server? I wouldn't generally expect different results for the same submission.
It also depends on the tests. If the tests are randomly generated, it could be that in some tests, your program fails to fill correctly but doesn't go over the instruction limit. On other tests, your program takes too long and thus is reported as being an 'incorrect program'.
OK. In that case I'm confused about my program not working - it's the same algorithm I used for Deluge and another related challenge, with minor changes to support different sizes, and it worked fine on differently sized grids there - plus all my test cases pass, so perhaps I've got the input format wrong.
Could you please confirm that:
* The board is 18x18, stored in the first 324 memory locations, one row at a time, and we're meant to flood-fill from memory location 0. (Maybe my Deluge algorithm was wrong, but fluked it...)
* We're meant to fill zero locations with ones, as before
* If the program hits the cycle count, the error is explicit
* What does it mean if it just says "'XXX' is incorrect", quoting my program text? It's a different error to when it just failed to fill the space.
Experimenting a little, infinite loops seem to either result in the error I saw, or the page coming back without either an error or a restatement of the problem as usual. It's odd that it's inconsistent, and it would help a great deal if it gave an explicit error message when you exceed the cycle count.
Could you please confirm that:
* The board is 18x18, stored in the first 324 memory locations, one row at a time, and we're meant to flood-fill from memory location 0. (Maybe my Deluge algorithm was wrong, but fluked it...)
* We're meant to fill zero locations with ones, as before
* If the program hits the cycle count, the error is explicit
* What does it mean if it just says "'XXX' is incorrect", quoting my program text? It's a different error to when it just failed to fill the space.
Experimenting a little, infinite loops seem to either result in the error I saw, or the page coming back without either an error or a restatement of the problem as usual. It's odd that it's inconsistent, and it would help a great deal if it gave an explicit error message when you exceed the cycle count.
to get back to your questions, the board is laid out the same as before, in the first 324 memory locations. the thing here is that Flash Flood just always says incorrect no matter what your error is. ie, cycle count being too high is the same as failing to flood, is the same as the program terminating on error.
i just reran my solution, it still works. the problem is good =)
i think the only way to code this is to first verify that your code works offline on your own memory set, where you can see how many cycles it's using and make sure it floods correctly.
i just reran my solution, it still works. the problem is good =)
i think the only way to code this is to first verify that your code works offline on your own memory set, where you can see how many cycles it's using and make sure it floods correctly.
OK - my program solves the new warm-up challenge without modification. I guess it just runs out of cycles on the original challenge. It would sill be nice to know how far over budget it is, somehow. Is the warm-up data comparable in complexity?
I see tails has solved Flash Flood now anyway, so it's obviously possible by mere mortals, even without feedback.
I see tails has solved Flash Flood now anyway, so it's obviously possible by mere mortals, even without feedback.
Hi,
Actually I made my code in July, but I was hesitating about posting it, because it exceeds the cycle limit in some cases in my local test. I was thinking my code needed more improvement.
My code solves the Warmup one in 16004 cycles. I think I can reduce the cycles more, but it will be a pain to do it, because of the size and speed tradeoff. My code has already grown up to 1311 instructions long!
EDIT: "have been" -> "was". Sorry for my poor English.
Actually I made my code in July, but I was hesitating about posting it, because it exceeds the cycle limit in some cases in my local test. I was thinking my code needed more improvement.
My code solves the Warmup one in 16004 cycles. I think I can reduce the cycles more, but it will be a pain to do it, because of the size and speed tradeoff. My code has already grown up to 1311 instructions long!
EDIT: "have been" -> "was". Sorry for my poor English.
Last edited by tails on Wed Dec 03, 2008 7:07 am, edited 1 time in total.
The simple return "... is incorrect" is kind of frustrating. After some tuning, my program needs 19002 cycles to fill the Warmup-map. The solution is also correct (as I could verify with the Warmup-challenge). But still the non-Warmup Flash Flood says that my solution is simply incorrect. Is this due to some different (harder) board? And how many cycles did my program need for that board?