Dwite Oct 2011 Q1

[jli1]

Hi everyone. In the Oct 2011 Dwite, my solution to problem 1 was judged to be 0/5. Can anyone tell my why this is? Code here: http://pastebin.com/k7MDBqcQ. I ran it with the posted test data and it worked on my machine, so it must be some kind of weird architecture thing I'm missing.

This was my second submission, my first should have gotten 3/5 due to a minor bug.

Thanks

[Tony]

what is your team name?

[jli1]

Tony @ Wed Oct 26, 2011 6:06 pm wrote:

what is your team name?

Pikachu Bread

[Dan]

For your first run of question 1, the judge has the following in it's log for the output:

code:

Area51 isnt actually made of 51 smaller areas 99 bottles of beer on the wall 99 bottles of beer you take 1 down pass it around 98 bottles of beer on the wall 3p1415926536 is pi to 10 decimal places

Note the extra linebreaks and 2 of the lines are missing.


For the second run:

code:

99 bottles of beer on the wall 99 bottles of beer you take 1 down pass it around 98 bottles of beer on the wall 3p1415926536 is pi to 10 decimal places 9876543210

You have the same issue, extra line breaks, 2 soultions missing.



Note that the judge changes the order of the lines. For your first run it gave you:

code:

saera rellams 51 fo edam yllautca tnsi 15aerA llaw eht no reeb fo selttob 98 dnuora ti ssap nwod 1 ekat uoy reeb fo selttob 99 llaw eht no reeb fo selttob 99 secalp lamiced 10 ot ip si 6356295141p3 elpmaxe rof 1212323423409234092340 ekil srebmun gnol ylaer daer ot drah fo dnik steg ti tub egaugnal looc ytterp a si cibarA 0123456789

And for the second:

code:

llaw eht no reeb fo selttob 98 dnuora ti ssap nwod 1 ekat uoy reeb fo selttob 99 llaw eht no reeb fo selttob 99 secalp lamiced 10 ot ip si 6356295141p3 0123456789 saera rellams 51 fo edam yllautca tnsi 15aerA elpmaxe rof 1212323423409234092340 ekil srebmun gnol ylaer daer ot drah fo dnik steg ti tub egaugnal looc ytterp a si cibarA

[jli1]

Strange that on my computer it returns the correct output. Is there supposed to be that newline on the first line of the input?

If I run it with the input

code:

llaw eht no reeb fo selttob 98 dnuora ti ssap nwod 1 ekat uoy reeb fo selttob 99 llaw eht no reeb fo selttob 99 secalp lamiced 10 ot ip si 6356295141p3 0123456789 saera rellams 51 fo edam yllautca tnsi 15aerA elpmaxe rof 1212323423409234092340 ekil srebmun gnol ylaer daer ot drah fo dnik steg ti tub egaugnal looc ytterp a si cibarA

http://pastebin.com/PgaBSxw2

I get the output

code:

99 bottles of beer on the wall 99 bottles of beer you take 1 down pass it around 98 bottles of beer on the wall 3p1415926536 is pi to 10 decimal places 0123456789 Area51 isnt actually made of 51 smaller areas Arabic is a pretty cool language but it gets kind of hard to read realy long numbers like 1212323423409234092340 for example

http://pastebin.com/u3tKKuHs

(Character for character)

Is there any chance you could send me the binary input files? Maybe its a problem with using C++ getline(istream, string). Although, from cplusplus.com: "If the delimiter is found, it is extracted and discarded"

[Dan]

jli1 @ 26th October 2011, 6:27 pm wrote:

Strange that on my computer it returns the correct output. Is there supposed to be that newline on the first line of the input?

Nope, that just an oddity in how the fourms do code tags.


What complier and OS are you using?

[jli1]

Dan @ Wed Oct 26, 2011 6:40 pm wrote:

Nope, that just an oddity in how the fourms do code tags.

What complier and OS are you using?

Windows 7 / MinGW-g++ 4.4.1

Same correct output on my friend's machine which I believe is MinGW-g++ 4.5.0. I'll try on a unix machine.

[jli1]

Just tried it on Debian with g++ 4.4.5, and it worked as well.

[Dan]

I will look in to it more tonight and see if i can find the issue. I should point out that the source code for your second submission is a bit diffrent then what you posted but does still seem to work off the judge.

[Yves]

There appears to be a link between getting 0/5 and using getline; my friends who used getline() failed whereas I got perfect with character-by-character. (After I realised it was DATA1.txt/OUT1.txt instead of DATA11, that is...)

After porting his code to Pascal (and keeping the same algorithm), one of my friends got 5/5 on q1.

[d310]

And that would be me.
I panicked and lost lots of time.

[Tony]

the output suggests that \r\n newlines are not handled properly. If getline grabs just the first separator, the second one will be left in the buffer, which would produce blank lines on the following reads.

[jli1]

Tony @ Wed Oct 26, 2011 7:38 pm wrote:

the output suggests that \r\n newlines are not handled properly. If getline grabs just the first separator, the second one will be left in the buffer, which would produce blank lines on the following reads.

However, when I run it on the machine I specified, it works fine with both LF only and CRLF files (converted using notepad++). So I'm kind of confused at this point.

[Cyril]

Daniel, did you enjoy the test cases for #3? Muahahaha, zero-length segments, and... homeschooling.

Aww, sorry about #1. I was afraid this would happen... it seems to happen whenever we have a string problem that involves reading lines of space-separated words. Dan, is there any way to standardize new lines to '\n'?

[Dan]

I did a test and had the judge make some testcase input files and it is deftaly using CR+LF as intended (it is windows based, blame turing and VB :p).

I also did some testing and it seems when complied with g++ and ran on the judge your code has this issue. However when ran in the visual studio complier it is fine.

The version of g++ being used on the judge is "g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)".

I have attached an example input file that is exctactly like one the judge would give to a program.


If any one has any ideas on how to stop this happenign in futture rounds i would love to hear them.