With this modification, my program passed all the test cases. Of course, I solved the issue by simply putting a statement to reset the variable to 0 before performing the calculations. This is why I got the correct answer when I ran the program after recompiling it. Hence, the static variables are restored to their initial values. Recompiling a program in BlueJ resets the Java Virtual Machine. Hence, I got 7 = 1+ 6 as my answer for the second test case. Thus, when I called the function the second time, the variable still contained its previous value. I just kept on increasing the value of the variable (in another static function - which did the calculations), and returned it when the calculations were over. And I had never explicitly set the variable to 0. I have now learnt that it is a bad practice.) Thus, the variable was conserved across multiple calls of the answer function on the same instance of the Java Virtual Machine. I realized that the value that the answer function was supposed to return, was stored in a static variable. I was almost ready to post this as a question on StackOverflow, when I decided to look at my code again.Īnd here comes the big moment. It was Java that was acting weirdly, or so I tended to believe. Puzzle solved!Īt this moment, I knew that my code was correct. Just to confirm it, I recompiled the code, called the function with the second example case, and found the output to be 6. I remember I got 6 as the output the last time I passed the same parameters to the same code. I just closed the output window of the first example, and called the function again.)īoom! This time, I got 7 as the output. Then, I again called the answer function with the input being the second example test case. I got 1 as the output, which was the correct answer. I tell you, in this world, being a little crazy helps to keep you sane. So I recompiled the same program ( not a very sane idea, I know, but wait) and called the answer function directly from BlueJ’s fantastic UI, with the input being the first example test case ( yes, the one that was already giving me the correct answer on FooBar’s evaluation - not a very sane idea again, but wait). The same mild confusion, now 17% extra for free When the function completes its execution, another dialog box pops up which contains the return value of the function. This opens a dialog box that asks for the parameters to be passed to the function. BlueJ has the option of calling static functions of a class through a popup menu obtained by right clicking the name of the class. I think that fact that I used BlueJ (it’s an awesome Java IDE, BTW) was instrumental in helping me unravel the mystery. At least the first two cases should have passed! Nevertheless, I decided to test the program on the example cases once again. ![]() And I had verified that my solution worked for the two example cases before I submitted the code. I had already discovered that the first two test cases on which my solution was evaluated were the same as the ones given in the examples. ![]() In my opinion, the program should have worked. I went through my solution again to find any logical errors, but couldn’t find any. To my dismay, only the first test case passed. Upon finally completing the code for the solution, I used the verify command to check it. I discovered an important fact about FooBar’s test case evaluations when I was solving the 2nd problem of the 2nd level. Although I did not receive any response from Google for that report, this flaw has now been fixed. Note that I had reported the bug through the feedback command via the FooBar terminal. This post will explain how I managed to extract hidden test cases from Google FooBar. I recommend you to read that post before you continue with this one. Hey there! In my previous post I wrote about my Google FooBar experience.
0 Comments
Leave a Reply. |