You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During a programing contest (my username is "maxime"), I was trying to solve the problem in Javascript my solution kept being rejected at the test case b07. So I asked the organizer after the contest the input of testcase b07 and up.
In fact, my program returned NaN for cases b07 and up but it should not.
I have made exactly the same script on a web page and Firefox (64.0.2) has no problem evaluating the script with the correct value (function Main) for the b07 input ("randomInput"). However, when I run the same script on the same input with node (v10.15.0) I get NaN.
I have attached script.js which has the b07 input ("randomInput") script.txt
Then the weird part starts because if I remove the last \n from the input, everything works perfectly fine. I know that the parseInt line 100014 is returning NaN for the last split because it's an empty line but none of the loop are going up to this point. All the loop are stopping before because I know the number of not NaN items and the sort should leave NaN where it is. I know this is pretty ugly and bad programing (but it's just that at this time I did not know that there was an empty line at the end)
I have checked a bit more in detail my script, and the loop line 100030:100038 fails at the i = 55653 because it falls in the NaN,NaN,NaN line. I guess that the problem is that the NaN line is moved here but the question is why is it moved in the middle, whereas all my test in the console seem to say that the sort(function) leave the NaN at the same index and sort() pushes the NaN at the end but this is not consistent with what is observed in my issue.
It only seems to occur when the table to be sorted is "big enough" because the cases 01-06 were solved (even if they had a last empty line). You can find all the TC here under 2019nikkei_qal
The text was updated successfully, but these errors were encountered:
Comparing NaN to any value gives false and your sort function returns 0.
According to the specification, the result in such case is implementation-dependent.
Node v10.15.0
Windows 8 64bits
During a programing contest (my username is "maxime"), I was trying to solve the problem in Javascript my solution kept being rejected at the test case b07. So I asked the organizer after the contest the input of testcase b07 and up.
In fact, my program returned NaN for cases b07 and up but it should not.
I have made exactly the same script on a web page and Firefox (64.0.2) has no problem evaluating the script with the correct value (function Main) for the b07 input ("randomInput"). However, when I run the same script on the same input with node (v10.15.0) I get NaN.
I have attached script.js which has the b07 input ("randomInput")
script.txt
Then the weird part starts because if I remove the last \n from the input, everything works perfectly fine. I know that the parseInt line 100014 is returning NaN for the last split because it's an empty line but none of the loop are going up to this point. All the loop are stopping before because I know the number of not NaN items and the sort should leave NaN where it is. I know this is pretty ugly and bad programing (but it's just that at this time I did not know that there was an empty line at the end)
I have checked a bit more in detail my script, and the loop line 100030:100038 fails at the i = 55653 because it falls in the NaN,NaN,NaN line. I guess that the problem is that the NaN line is moved here but the question is why is it moved in the middle, whereas all my test in the console seem to say that the sort(function) leave the NaN at the same index and sort() pushes the NaN at the end but this is not consistent with what is observed in my issue.
It only seems to occur when the table to be sorted is "big enough" because the cases 01-06 were solved (even if they had a last empty line). You can find all the TC here under 2019nikkei_qal
The text was updated successfully, but these errors were encountered: