Since javascript and standard datatypes in other languages are both mentioned, integer division is a gray area. In C,
means i = 2. This is what is expected if the standard int datatype is used. In javascript, however,int i = 5 / 2;
gives us i = 2.5. Which of these is valid?var i = 5 / 2;
This could be clarified by an enumeration of the data types in the problem definition. I guess that they are "string" and "float" or "string" and "double". If there is no "int" then there is no integer arithmetic either.
The PDF explicitly describes the '/' operator as "Division - Real datatype".
Agreed. But the problem also states "you can map the parser types to standard types such as signed integer, signed double and string".
If signed integer is a type, integer division is a distinct possibility.
Hi,
To simplify the parser problem definition, we haven't defined the "int" division. Note that "int" division is also performed as a "real division". Hope this clarifies.
Thanks
-Rama
I think it would be more difficult, because most of participants write code in C, in which
(5 / 2) = ( (int)5 / (int)2 ) = (int)2, and there is no type conversion. In Russian problem's description it says that there is simplified C/Pascal language.
But now it's all clear.
The input won't try to generate unnecessary errors. The input will be created considering the supported operations.
Of course, the input might try to free undeclared variables. The input might try to use a previously freed variable. Those are the important cases to consider.
Some syntax errors might occur, bet the input won't be trying to force the execution of operations that weren't included in the specs for the problem.
We won't be including things that aren't explained in the problem specs.
Integer division won't be included in the input. Thus, you don't have to worry about this operation.
I thought the same as well. The input includes only thing explained in the problem specs. Otherwise the judges will have problem in determining whether a behavior is correct. In turn, any syntax/behavior we are not able to guess from the specs shall not be included in the input.
Minh-Nhut, Exactly. That's the idea. The input will include only things explained in the problem specs and shown in the samples. The intention won't be to make the parser generate unnecessary failures by cheating. You have to prepare the parser for syntax errors but not for completely unexpected and unexplained situations. Cheers, Gaston