https://www.codingame.com/training/medium/cgfunge-interpreter
Send your feedback or ask for help here!
https://www.codingame.com/training/medium/cgfunge-interpreter
Send your feedback or ask for help here!
This one (https://www.codingame.com/training/medium/cgfunge-interpreter) I had given feedback for when it was in the queue, but hadnāt actually implemented it at the time, so hereās the remainder now:
specification bug: the flow control instructions say āif the top of the stack isā. The validation cases behave as āif the top of the stack is (ā¦) and then pop itā.
IDE infelicity: itās a real pain that the input program canāt be an actual rectangle because of whitespace trimming.
and thatās it. Iāve tried to find other actual specification bugs, and though there is some minor undercoverageā¦ the test cases are actually robust against them. Just wow!
Accept my deepest and most sincere congratulations, @player_one! That problem was exceptionally well set, and I donāt say that often! Please become an inspiration for the serial crap problem setters.
My humble thanks. I agree I should have specified that a value is popped for the flow control instructions. Ooops. Oh well. Iām glad you enjoyed the puzzle.
It seems not to be working correctly with Python3, or is it me ? The test cases involving a new line character wont validate, this is the output I get:
Standard Output Stream:
99 bottles of beer on the wall
99 bottles of beer
take one down, pass it aroundFailure
Found: Nothing
Expected: ā9ā
I had the same problem @Shugah, and it seam that in the 5th validator, an āEā (end of program) should be passed with a āSā, I just implemented it in my loop and now it works.
Correct. An āSā character skips. This is in the Goal description:
āSā - Skip the next character and continue with the subsequent character
Test case #3 uses āSā as well, but on further inspection, it turns out that it will work just fine without implementing āSā behavior because the character that it skips is a āGā, which has no functionality. So as long as your program ignores unrecognized characters, test 3 works fine without the āSā.
In hindsight, I should have made test 3 require that āSā behavior works properly. I really wanted to introduce that concept at that point.
Here is an extra test case to help pass validator #3:
Input:
3
vell, vell, vell
>0I Empty lines are special, you know.
Expected output:
0
Thanks finn_troll! I donāt like this behavior as this is nowhere specified! Making empty cells equivalent to spaces is just arbitraryā¦
Actually it is:
Execution always starts on the first character of the first line and proceeds to the right. Spaces are ignored. So, for example, the following are equivalentā¦
The fact that unknown characters other than spaces are to be ignored is not specified, though, as far as I can tell.
Edit: I understood this explanation as meaning that space characters are ignored, including " ", ā\tā and ā\nā. But I donāt think there is a test where the āarrowā has you move to a point where there is no character. If you modify finn_trollās example to include a bunch of whitespace on the empty line, it should work fine.
I suspect that itās exactly those whitespaces that are missing (or automatically stripped) for the third validator - at least that was the only change I had to implement to pass that test. I donāt see any problem with that because - as far as I remember - the specification does not promise that all lines will have an equal length.
Ok my bad, maybe this appears in the validator too. My algorithm passes your test, but I have no idea why trying to access chars in the empty string doesnāt cause a segfault.
Just checked. You are correct. The third validator does go āoff the endā of a string. If I had noticed this, I would have done AT LEAST one of the following:
Darn. I put so much effort into this puzzle too!
My guess is that with certain C compilers, indexing row 1 element 0 gives you row 2 element 0 in case of an empty row 1.
Itās still one of my favourite community puzzle so far. It must have been quite challenging to program the test cases for this imaginary machineā¦
Itās C++, and it is a vector of strings. Plus it does process an empty (or unprintable) char, it doesnāt skip directly to the >
. And it works with this as well (trying to access element 1 of an empty string):
>vell, vell, vell
>>0I Empty lines are special, you know.
I was looking at my code, trying to figure out why this didnāt bite me, and then I realized that itās technically not a problem. There is an āSā character before the short line, so your code is supposed to jump over that point. If you are trying to dereference that line, then you havenāt implemented the āSā behavior correctly.
Even so, I would have done things differently if I had noticed.
CGFrunge ā Framed CGFunge.
I think itās not just the empty lines. For instance what I first did was fill in the empty lines with a bunch of spaces but that didnāt pass Validator 3. What I did afterwards was to equalize the lines to have the same length as the longest line [I added ā ā to any line shorter than the longest] and that did it. Now, maybe I didnāt added enough spaces with the original solution but the latter one fixes inputs with different lengths of lines as well.
>>>>>>>>>>>>>>>>>v
E short line
^ short line no 2
^<<<<<<<<<<<<<<<<<<<<<
So, as I mentioned above, you donāt really NEED to fill in empty or short lines to solve the problem. The fact that the short line is skipped with an āSā character means that this shouldnāt (for some, though not all implementations) be necessary. A better test case that illustrates this would be:
4
v Go down!
Skip next line S
Short line
Finish here --> > "!yaY" CCCCE
Answer:
Yay!
My own solution (and many others) pass this test just fine without adding any spaces to the short line. Just an FYI.
My two quick fixes to this were
Loved the puzzle!