BTW, the contest web site has been updated to reflect the current one.
Printable View
BTW, the contest web site has been updated to reflect the current one.
Does the name of the file to be compressed need to be preserved through compression?
I.E. if you compress "this.txt" and then decompress it, does it have to still be named "this.txt" or can the user specify the out file?
I'll join up too. If I do a command line program does it cost me points if I require that the file names are arguments to main? In other words, if the user doesn't supply the file names, do I have to prompt for interactive input or can I just quit with a usage message and an error code?
Is it ok if we prompt for the path from within the program and don't accept command line arguments? That is the method which I prefer if it is acceptable.
Edit: Does Linux use a 1 byte unsigned char, or do I need to figure out a workaround?
The interface is whatever you choose it to be. Just don't make it overly cryptic. You can ask for the filename inside the program, or as a command line argument, or whatever else makes sense.Quote:
Originally posted by blackrat364
Is it ok if we prompt for the path from within the program and don't accept command line arguments? That is the method which I prefer if it is acceptable.
Edit: Does Linux use a 1 byte unsigned char, or do I need to figure out a workaround?
What do you mean for 1 byte unsigned char? In what? AFAIK, 1 byte is an unsigned char on any operating system.
No. The filename can be disregarded. (If you prefer, you can preserve it.)Quote:
Does the name of the file to be compressed need to be preserved through compression?
You answered my question. I just wanted to make sure that my code to read the file would work on Linux. I'll test my final code with GCC on Linux before I submit it... and then if it doesn't work, I'll probably submit it without changing anything and just be angry :)
How is the speed aspect being done? A stopwatch, or something less crude, like profiling? There are problems associated with both - profiling gets screwed up while waiting for user input, a stopwatch is really crude.
For efficiency, we'll be looking at the code and seeing how many inefficiencies we can spot, what code can be made faster.
hmm.. thnx for the compliments :mad: :mad:
Well for a change planin on using VC++.. any way not sure...
And in case if i am not able to finish on time can i submit a text compression algorithm...
Vasanth
Sorry, but that's what I think of your programming style. It is usually messy. I'm not saying anything against you as a programmer.Quote:
hmm.. thnx for the compliments :mad: :mad:
A text compression program will be evaluated like any other compression program. At least one of the files it's tested against will be a text file, but there will be at least one binary file, too.Quote:
Well for a change planin on using VC++.. any way not sure...
And in case if i am not able to finish on time can i submit a text compression algorithm...
In short: yes, if you want to.
I'll try, but it's probably gonna take me forever to learn how to code a compresser.
Just some links for those of you who are clueless:
How compression works
Huffman algorithm
Arithmetic compression
Do you need more judges?
If you want to judge, you can.
I'd like to, but I'll be away from home from July 16th and I won't be home until the end of the month at best. So, it depends on how long you want the contestants to wait.
I'd like to judge antoher time though, judging the Mid() contest was interesting.
It's alright, maybe another time.