Originally Posted by BFRD
I was working on a different math based approach (using the sum of the x,y coords). It worked great for the top half, but I had to use a different alg for the bottom half. I ran out of time this morning before I could re-work it. Nice job.
All of the solutions are nice. However from a professional standpoint there has to be a cross between elegance, functionality and readability. The number of lines in a compilied language doesn't matter. Certainly minimizing loops and extra processing is important, but raw size doesn't really matter. Some of the solutions appear to be obfuscated in order to minimize the "size" of the application. In the professional setting you need to focus on readability a little more. Self documenting code via explanatory variable names is often very helpful. Try not to get caught up solely in the length of size of the code. Remember what you write isn't what is processed, it all goes through an interpreter and is compiled down. Same theory for variable names goes with consistant line control and tabbing. Just makes it easier for the rest of your team if you write code that doesn't need to be reformatted to read easier.
Otherwise, kudos for the work.
Heh, I know what you mean. I only squished things a bit to get down to functioning on 14 lines. I'd like to think my actual code is stylistically decent, this was just a poor example because our #1 focus was lines used. I'm actually fairly notorious for spacing everything out nicely, often having longer than normal files. I guess there's a difference between onlince competition for fun and professional level code.
And its interesting to think of it in a coordinate system. I was almost going to break it down into binary to see if I could find a simple solution, until I figured out the math behind it. I'll look forward to seeing what you have if you do get it done!