September 5, 2008 2:39 PM PDT
Suggesting an Alternative Output Format
For all your best interest, both the judges and the programmers, I would like to suggest an alternative output format here.
Why do I think the original dots presentation not so good?
Compare to the number of grids on the whole checkerboard, the number of possible Knights and Queens are relatively VERY SMALL. And the empty grids are implied to be "default" and provide no useful information for the solution at all. Hence the output dots which represent the empty grids somehow seem to be wastes. In addition, I think the judges are going to use some program to examine the output, instead of using their EYES ONLY to watch the graphic-like text file. Thus the dots contribute nothing.
An alternative format:
I suggest another format to list all the positions of Knights and Queens using the number of row and columns as it follows(for one solution only):
The first solution of the given output can be presented as:
Queen: 0 1 1 6 2 2 3 5 4 7
Knight: 5 0 6 0 6 3 6 4 7 3
It does not matter if some of the Queens and Knights interleave on the checkerboard
- in this case we can output all the Queens in a sequential manner and then all the Knights.
This format uses less charactors and reduces the output file size to make the IO more efficient, both write(for solving) and read(for judging). The benifit will become significant when N becomes big, i.e. when N is larger than 20.
Sorry, I am still writing the code, even have not started compiling or debugging.
And, as some released result demostrate, the number of solution explodes, so does the time consumption to explore all the possible solution. I wonder whether the judges will use some N as large as 100 for tests. [actually I think any N>=20 will take some unacceptable time to get a full answer, even with the best optimised parallel algorithm].
It was expected that the I/O would again be a very small fraction of the execution time, so the given output format was formulated to make judging a little easier. Upon further consideration, the output format proposed in the this thread should be easily convertible to the stated output format. Even more compact would be putting each piece on a consecutive lines with a blank between each board, like:
Q: (4 8) (5 6) (6 3) (7 7) (8 2)
N: (1 4) (2 1) (2 4) (2 5) (3 1)
Q: (3 8) (5 2) (6 7) (7 3) (8 6)
N: (1 1) (1 4) (1 5) (2 1) (2 4)
The MD5 hash is getting a bit too condensed. If a code doesn't get the expected hash, we still need to go in and look to see which boards are incorrect. (Of course, you are all excellent coders and won't get the wrong answers, so this point should be moot, right? )
What if the output format were made optional (either the original version or some condensed format)? In order to do this, there would be a requirement to explain how the condensed form maps into the original format (and it might require an additional utility be coded and included in the entry to take your output format and produce the original board output). Would there be any objections to amending the contest problem with something like this?
Unanimous approval by the judges will be required before such a change would be made official. It is early enough in the month that allowing such an alternative output format shouldn't adversely impact anyone's work to this point. (There may be some contestants getting their code done early for a skiing trip to the Alps, so such a change to the problem would need to be made optional. )
This code is serial so the 11 case will be problematic when going parallel. And more if someone another order of magnitude speedup.
madcpbreshe:
There may be some contestants getting their code done early for a skiing trip to the Alps, so such a change to the problem would need to be made optional.
PS: no snow yet in the Alps but good wind, less tourist -> good conditions for windsurfing :-)
please tell me the standard out put format and points format(with bonus points) also.......... and is it possible to resubmit the code???
First of all, welcome to this contest!
I guess the output format is unchanged until the judge allows the alternative format proposed in this thread. Clay would have the final word on this.
As for the points format (you mean scoring criteria, right?), you can find these information in this forum. Judges post the criteria for each month after they announce the winner.
You are free to resubmit the code before the deadline.
It seems to me that it would be pretty easy to add a command line switch that would produce alternate formats, that way people could test using whatever pleases them and the judges could still get the "default" format that is easiest for them to check.
It seems to me that it would be pretty easy to add a command line switch that would produce alternate formats, that way people could test using whatever pleases them and the judges could still get the "default" format that is easiest for them to check.
But someone could use a different execution path when using the command line switch and the judge then would not be able that the solving timing is the same as the one with the "default" output format.
So timing with the custom output format and having an external tool to convert it to "default" is a good alternative.
But once again, I/O (relatively) time is small except for the 11x11 case.
I was suggesting that everyone support the requested format for judging (so everything is judged on the same basis). However, if folks want to use a different format when testing, it would be easy for each of us to support that we prefer with a simple command line switch.
But someone could use a different execution path when using the command line switch and the judge then would not be able that the solving timing is the same as the one with the "default" output format. So timing with the custom output format and having an external tool to convert it to "default" is a good alternative. But once again, I/O (relatively) time is small except for the 11x11 case.
I think that it is worth to require that the program should behave identically with both output formats.
I think it would be useful to have a format of that has each board on a separate line. It could be like the sample without the newlines for each row, or it could be something like FEN: http://en.wikipedia.org/wiki/Board_representation_(chess)
Use of an alternate format is approved. Details should be in a modified version of the problem description. We had also put a copy of the details inthe forum, under a new heading. But I don't see it here. I'll repost that tomorrow.
why do we need the brackets? commas or other single interpunction will separate the pairs well.
madcpbreshe:
It was expected that the I/O would again be a very small fraction of the execution time, so the given output format was formulated to make judging a little easier. Upon further consideration, the output format proposed in the this thread should be easily convertible to the stated output format. Even more compact would be putting each piece on a consecutive lines with a blank between each board, like:
Q: (4 8) (5 6) (6 3) (7 7) (8 2)
N: (1 4) (2 1) (2 4) (2 5) (3 1)
Q: (3 8) (5 2) (6 7) (7 3) (8 6)
N: (1 1) (1 4) (1 5) (2 1) (2 4)
The MD5 hash is getting a bit too condensed. If a code doesn't get the expected hash, we still need to go in and look to see which boards are incorrect. (Of course, you are all excellent coders and won't get the wrong answers, so this point should be moot, right? )
What if the output format were made optional (either the original version or some condensed format)? In order to do this, there would be a requirement to explain how the condensed form maps into the original format (and it might require an additional utility be coded and included in the entry to take your output format and produce the original board output). Would there be any objections to amending the contest problem with something like this?
Unanimous approval by the judges will be required before such a change would be made official. It is early enough in the month that allowing such an alternative output format shouldn't adversely impact anyone's work to this point. (There may be some contestants getting their code done early for a skiing trip to the Alps, so such a change to the problem would need to be made optional. )
why do we need the brackets? commas or other single interpunction will separate the pairs well.
You don't need brackets or commas or any other punctuation. The format and separator character is up to you. I was just giving an example.
In fact, during my shower last night, I had an idea about using something similar to a dictionary-based compression algorithm. For the two boards in my previous post, I would have printed them as:
3N4N2NN3N14Q5Q4Q11Q2Q6
N2NN3N2N11Q9Q12Q3Q10Q2
Place the rows of the board one after the other as a 1-D array. Count the blank squares between pieces and write down the number. Pieces are represented by their single letter. I guess I could have used a '.' after each number to make the number a multiplier.
This compression scheme would be so much easier to grade with a sort and a diff. We might have to write our own utility to convert the board outputs into this format. (I seem to have quite a few good ideas in the shower. Maybe if I took more I'd be smarter, or least seem that way.)
guess what, I used a format similar to this one in my yesterday's submission ... I called it RLE (Run Length Encoding).
Q....
..Q..
.....
.....
.N.N.
which then gives
Q6QDN1N1
For simpler implementation, I use only one hexadecimal number to encode spaces and then sums them up.
The one liner format is also easy to grade with sort and diff.
I have written an out2dat perl script (posted in another thread) to transform/sort a QNboardxx.out file to a one liner file which I use in my test suite.
David.
Forum Statistics
4474 users have contributed to 24001 threads and 69861 posts to date.
In the past 24 hours, we have 42 new thread(s) 152 new posts(s), and 197 new user(s).