1 / 19
May 2008

A couple of questions..

1) My solution to autoarchive produces a 100% correct output on my computer. I can't understand why it wouldn't on SPOJ.. can one of the judges check just to make sure there isn't a mistake (I see two other people have solved it though.)

2) Are lookahead assertions not valid in C regex? One of the questions seems to require them, but it appears they aren't possible..

  • created

    May '08
  • last reply

    May '08
  • 18

    replies

  • 1.2k

    views

  • 7

    users

  • 10

    links

The program judge works correct. Did you read the note which I add lately? it's much better to submit source file, not text, when submit your solution.

I presume you mean uploading a file versus copying and pasting.. I did see that, but my latest submission (1463713) uploads the file and still works incorrectly. I presume there must be something compiler specific SPOJ does differently, but it's such a simple program I can't see what it could be..

The part of judge:

fgets(s1, NL, spoj_t_out);
fgets(s2, NL, spoj_p_out);
if (strcmp(s1, s2))
{
    return ERROR;
}

Maybe you missed the end of line or smth. Hope this helps.

Alright, I've gotten AC finally. It was actually the opposite of what you suggested - I did print an end of line, but the provided output does not. Slightly unusual, since it really should end in a new line, but the question does say exactly..

I have downloaded the file ZARJ.txt and the code runs perfectly fine on my pc. However , it produces run time error SIGSEGV when I submit it. Surely this error is due to the fact that my code cannot access ZARJ.txt in the judging environment.
How to get hold of the file ZARJ.txt in the judging environment ? Or , is the problem all about devising techniques to access ZARJ.txt during run time ?

You are not able to access this file. Your program should output it without using outside data.

This problem raised many red flags, because my WA code gives me correct code, when I redirect the output to a file, so strcmp gives me 0 (size of code is about 77Kb). I've examined it again and again and now I know what is the error: in the turbo:ZARJ.txt file there are exactly 17 characters (in 16 words) which ascii code isn't in the 0-128 range, this means a lot of problem in programming, because those ascii values aren't the same on different computers. Some of them are really strange. The first of them is at:
"mainframe of Zion, the humansÂ’ last refuge"
the first character after humans

Printing these 17 characters seperately gives me also WA.

So what should I do with these characters?!
My suggestion is: It would be much better to delete these from the text file, and further posted codes tested by the new text file.

If you treat ZARJ.txt and the program you submit as sequences of bytes rather than sequences of characters, this shouldn't cause a problem. GNU C++ string literals seem to allow unescaped any bytes other than 10, 13, 34 and 92.

And how to solve it in c, or is it impossible?! (currently all 6 ac codes are c++).

The same is probably true of GNU C. If not, most C programs will do the same thing when you compile with a C++ compiler.

It's possible to solve this problem in C and Pascal. I don't see any problem here.

Ok, but I'm still really don't know how to print "mainframe of Zion, the humansÂ’ last refuge", with

char w[64]="mainframe of Zion, the humansÂ’ last refuge";
printf("%s",w);

yield:

mainframe of Zion, the humansĺ last refuge

A correct example would really help me.

This problem still has got still the lowest acc rate. I've solved on spoj the similar magic2 problem but this isn't help. On asciivalue.com/index.php
I've tried the above crazy character. It says that Â’ is equal to

Char	Dec	Hex	Oct
&	38	26	46
#	35	23	43
8	56	38	70
2	50	32	62
1	49	31	61
7	55	37	67
;	59	3B	73

But when I try to use it in a string literal using \x2623383231373B trick, I immediately get the

hex escape sequence out of range

Nice.

Somebody knows why I get the correct output if I use

FILE* out;
out=fopen("ki.txt","w");
fprint(out,.........
fclose(out);

And giving the wrong codes for the 17 bytes using screen output:

fprintf(stdout,...........

So why the same text gives different output results when I output to the file and to the screen. Should I missed something in c language?

I've uploaded the output to googlepages, using file output:
http://robert.gerbicz.googlepages.com/fileoutput.txt
As you can see the 17 wild bytes are replaced by ? character. Proving that it isn't as easy as you can think.

And the screen output (width of the screen is 120, there was no line break):
http://robert.gerbicz.googlepages.com/screenoutput.txt
And the 17 bytes are again different from the correct ones.

I wouldn't call this an easy problem. But without the wild bytes, it's a medium difficulty problem. But if the goal was to minimize the number of ac codes, then it was successful from the problemsetter.

Ok, now solved the problem. I've got the only c solution. I wouldn't say that it was a too much help on this forum.

Robert, I am not sure why you expect someone to help you during the contest. Just try to enjoy solving these problems, I know I have smile

Anyway, I use Java and for some reason I get characters with weird codes, too (code 8200+). I kinda doubt other languages support Unicode out of box, so I am not quite sure what's going on here.

I checked the file a couple of days ago on another PC and the codes were all in the "normal" (<256) range. I am not sure what is different with this PC, but I get those 8200+ with Robert's 1st file as well, but not with the second one.

Note that these characters (8200+) are just dashes and quotes. Can someone just check this file on a remote PC or something?

Ok, Darko.
I've solved the problem, as I said, but what is still very confusing for me that my AC code ( submission number=1472591 ) is printing different symbols at those 17 places. I don't call that this problem is broken, because the part of the judge is posted on the first page. But if you don't use the same compiler, flags,... then you have got almost zero chance to reproduce the same text.

The crazy symbols are:
http://www.eki.ee/letter/chardata.cgi?dcode=8217
http://www.eki.ee/letter/chardata.cgi?dcode=8211
http://www.eki.ee/letter/chardata.cgi?dcode=8220
http://www.eki.ee/letter/chardata.cgi?dcode=8221
http://www.eki.ee/letter/chardata.cgi?dcode=8212