Computer Science Canada

Dwite Oct 2011 Q1
Author:  jli1 [ Wed Oct 26, 2011 6:01 pm ]
Post subject:  Dwite Oct 2011 Q1
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
Author:  Tony [ Wed Oct 26, 2011 6:06 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
what is your team name?
Author:  jli1 [ Wed Oct 26, 2011 6:08 pm ]
Post subject:  Re: RE:Dwite Oct 2011 Q1
Tony @ Wed Oct 26, 2011 6:06 pm wrote:
what is your team name?


Pikachu Bread
Author:  Dan [ Wed Oct 26, 2011 6:18 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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
Author:  jli1 [ Wed Oct 26, 2011 6:27 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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"
Author:  Dan [ Wed Oct 26, 2011 6:40 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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?
Author:  jli1 [ Wed Oct 26, 2011 6:43 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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.
Author:  jli1 [ Wed Oct 26, 2011 6:58 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
Just tried it on Debian with g++ 4.4.5, and it worked as well.
Author:  Dan [ Wed Oct 26, 2011 7:18 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
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.
Author:  Yves [ Wed Oct 26, 2011 7:19 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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.
Author:  d310 [ Wed Oct 26, 2011 7:30 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
And that would be me.
I panicked and lost lots of time. Sad
Author:  Tony [ Wed Oct 26, 2011 7:38 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
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.
Author:  jli1 [ Wed Oct 26, 2011 7:47 pm ]
Post subject:  Re: RE:Dwite Oct 2011 Q1
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.
Author:  Cyril [ Wed Oct 26, 2011 7:50 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
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'?
Author:  Dan [ Wed Oct 26, 2011 7:50 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
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.
Author:  Dan [ Wed Oct 26, 2011 7:52 pm ]
Post subject:  Re: RE:Dwite Oct 2011 Q1
Cyril @ 26th October 2011, 7:50 pm wrote:

Dan, is there any way to standardize new lines to '\n'?


Yes but that just casues the same issue for a diffrent group of peoleop who are assuming the line break is CR+LF.
Author:  A.J [ Wed Oct 26, 2011 7:55 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
I am sorry about #3. I was feeling in a particularly bad mood when I wrote up the problem set for this round. Though I really enjoyed the story (inspired by Maarij Baig, a friend of mine). I'll be releasing solutions/analyses tomorrow.
Author:  jli1 [ Wed Oct 26, 2011 7:56 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
Yeah, just tested with the posted input file and it seems to work fine with my compiler. I thought the string and stream libraries were pretty standard, its weird that getline behaviour would vary among compilers.
Author:  d310 [ Wed Oct 26, 2011 7:57 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
Well, many people on other online judges have had the same problem.
Perhaps in the future unix newlines for test data?
Author:  Cyril [ Wed Oct 26, 2011 8:00 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
Can we try the gcc compiler suite from MinGW? I've always used g++ from that, and I've never had issues with newlines.
Author:  Dan [ Wed Oct 26, 2011 8:01 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
d310 @ 26th October 2011, 7:57 pm wrote:
Perhaps in the future unix newlines for test data?


I fear that might just cause this issue for a new group of peoleop.

I wonder if it has to do with g++ being complied for cygwin.
Author:  jli1 [ Wed Oct 26, 2011 8:06 pm ]
Post subject:  Re: RE:Dwite Oct 2011 Q1
Cyril @ Wed Oct 26, 2011 8:00 pm wrote:
Can we try the gcc compiler suite from MinGW? I've always used g++ from that, and I've never had issues with newlines.


+1, (obviously) if the judge is on Windows
Author:  Dan [ Wed Oct 26, 2011 8:10 pm ]
Post subject:  RE:Dwite Oct 2011 Q1
Tony came up with a soultion to link in textmode.o which forces g++ to open everything in textmode. It seems to work on the tests i did on the judge but it might be worth while investaging the use of MinGW.
Author:  md [ Wed Oct 26, 2011 8:36 pm ]
Post subject:  Re: Dwite Oct 2011 Q1
Dan @ 2011-10-26, 8:01 pm wrote:
d310 @ 26th October 2011, 7:57 pm wrote:
Perhaps in the future unix newlines for test data?


I fear that might just cause this issue for a new group of peoleop.

I wonder if it has to do with g++ being complied for cygwin.


By default cygwin uses *nix line endings (\n only), there is a way of setting it to use windows line endings though. Alas I don't remember what it is.

:


You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy