Re: I have WA#5! is this Input is correct?
Pheeew, finally AC!
After WA #3, which had a test like
print 5
end
, i added 4 lines to fix that, and immediately got WA5. Thanks to Fyodor, i immediately understood what i missed, in case like
a = 1
goto x
b = 2
x: goto x
i initially printed
Program terminated. Variables state:
a: 1
b: 0
So, i fixed that too, and only printed out a: 1, but still was having WA5! Curiously enough, after a fix, which i didn't think would help, i finally got AC. In my program, i had this chunk of code:
writeln('Program terminated. Variables state:');
{
for i:=1 to vsz do
if initialized[i] = 1 then writeln(vnames[i], ': ', vars[i]);
}
for i:=1 to vsz do begin
val(vnames[i], j, xcode);
if xcode <> 0 then begin
if initialized[i] = 1 then writeln(vnames[i], ': ', vars[i]);
end;
end;
The thing is, i threw everything into variable array, both constants and variables, like if i met A = 4 + -3, i throw A, 4, -3 into that array. Then, i go through every variable "name" and use standard val procedure to attempt to convert string into integer. "A" isn't a number, so it remains 0 initially, but "4" and "-3" successfully convert into numbers, so i give them values of 4 and -3 initially. But if i write in my program 4 = 100, then later on something like "A = A + 4" would actually add 100 to A. Soooo...
Using that lower uncommented chunk, i go through variable names again, and convert them into numbers, to see, if they're supposed to be constants. If they are, i ignore them, and if they aren't, i check if they're initialized, and if they are, i print them. That gave me WA5. Test like
4 = 5
x: goto x
would give
Program terminated. Variables state:
Then, i commented that lower chunk, and uncommented the upper chunk, so that no matter if "variable"'s name can be converted to number or not, i print it out anyway if it's initialized. So for test like
4 = 5
x: goto x
it now gives
Program terminated. Variables state:
4: 5
And that fix got me AC! Either stuff like 4 = 5 is present in 5th test, or i'm missing anything else...
Well, that was fun to discover, haha~
I also implemented support for variable names equal to keywords, so things like "not = not not" or "not: not = not or not" or "print: print print" would be parsed adequately, but seems it wasn't really needed.
P. S. In the end, it turned out that the Val function converts not only decimal, but also hexadecimal numbers, which is why i encountered this problem.
Edited by author 22.10.2015 15:12