Skip to content

Conversation

@mugenen
Copy link

@mugenen mugenen commented Mar 13, 2014

Python raised ValueError while reading a sample input because int() cannot parse long integers with 'L' like '1L'.

Values are printed as-is in PythonLanguage#renderParamValue(). However, Java is selected first in topcoder arena. Therefore, long integers are printed with 'L' in JavaLanguage#renderParamValue(). Though I changed language to Python in arena, *.sample file was not updated.

To fix this issue, the default value of testcase.overwrite should be 'force'.

@wookayin
Copy link
Collaborator

I think the sample itself is improperly rendered. Sample input should be in a canonical form (e.g. no 'L' suffixes for long types).

@mugenen
Copy link
Author

mugenen commented Mar 13, 2014

I don't know why Greed renders samples's long integers with the 'L' suffix for Java and C#, and the 'LL' suffix for C++. If the suffixes are not needed, I agree with your opinion that sample input should be in a canonical form.

@zen0wu
Copy link
Owner

zen0wu commented Mar 14, 2014

Sorry I'm no expert in python. But I do think changing the default behaviour of testcase overwrite will not solve this. If the int() function cannot parse a string of integer suffixed with L, it's the fault of the L. We should remove the L since python doesn't differ long and int, am I right?

@mugenen
Copy link
Author

mugenen commented Mar 14, 2014

We should remove the L since python doesn't differ long and int, am I right?

I'm afraid I don't understand what you meant.
I think L suffix is alreadly removed from PythonLanguage#renderParamValue(). Thus, long integers are NOT suffixed with L for Python. However, long integers for the other languages are suffixed L or LL.
Even though long integers are NOT suffixed for Python, int() cannot parse long integers because a string of long integers suffixed with L are generated for the other languages and not overwritten by the default behavior when I change language to Python.
Though we can remove suffixes when reading input, the bahavior for some languages should not be affected by the behavior for the other languages..

@zen0wu
Copy link
Owner

zen0wu commented Mar 14, 2014

Ohhh, I see what you meant. Sorry for the misunderstanding.

The point of the skip was that you may want to add your custom testcase, and setting it to force will overwrite your change, which may cause trouble.
Another way is to adjust the int() parser to a more advanced one which can handle this situation, like using regex to extract the prefix of the string. What do you guys think?

@mugenen
Copy link
Author

mugenen commented Mar 14, 2014

I see the benefit of the skip.

wookayin proposed above that "Sample input should be in a canonical form (e.g. no 'L' suffixes for long types)."
If it is possible, the testcases for all languages are in the same format.
Therefore, force or ad hoc parsing is not needed.
What do you think of wookayin's proposal?

@zen0wu
Copy link
Owner

zen0wu commented Mar 18, 2014

Yeah, that may be a good idea, but it means that the testcase template is specially treated when rendering, and greed may be lack of methods to do that (treat some template specially), I may take some time to look at this.

@wookayin
Copy link
Collaborator

An example of 'LL' suffixes in the test case: TCO2012 R1A EllysFractions (the test is not working properly)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants