91–100 of 129 posts
The UI for this reminds me a lot of Scratch from MIT.
It's not finished yet, but it sure beats MIT's attempt to port Scratch from Squeak Smalltalk to Adobe Flash...
Fun puzzle!
I noticed something interesting and disturbing after reading some of the answers: people are more concerned with the length of the code rather than the optimal solution (no extra turns / backtracking). This reminds me of interviewing at MS about 12 years ago and all they cared about was the ability to write recursive code. IMO, yes, elegant code is fantastic, but don't lose track of why we write code in the first pla…
So, I'm more disturbed that most of the answers people are posting aren't general solutions: they happen to solve this maze, but don't handle corner-cases (hah! I guess that's a pun ;P) of other mazes. You may as well just hardcode the answer to this one. I actually found a similar bug in yours: you will get trapped in a square and be unable to exit, as you will constantly keep hugging the column along the left, with…
General solutions for mazes (graphs really) generally follow a depth, breadth or hybrid approach. I'm actually surprised that all of the general solutions have been depth and none breadth. It's a bit more convoluted in this case as you'd have to traverse backwards, but conceptually, it's no more different than using a FIFO or LIFO.
In any case, with the tools given for this particular "challenge," a general graph search is impossible as you can't record previous states. It's simple to construct a map which causes an infinite loop.
A good analogy of my approach would be using a knowledge based finite state machine over a genetic algorithm or neural net. Is it less elegant? Sure is. However, it's also clearly defining a particular problem / solution pair with certain limitations and expectations.
Earlier quoted context omitted.
Interesting that in the initialization loop it sets A[0 - 1] to true, yet in your blocky code it appears to be iterating from 0 to n. In fact it always seems to be offsetting by one in array access ... 1 based indexing maybe?
Correct, you should see the looks on non-programmers' faces when you tell them that the first element in a Java list is #0, the second is #1, etc. It's approximately the same look as you see on programmers' faces when you tell them that the first element in a Blockly list is #1, the second is #2, etc.
7 blocks has to be the shortest solution, right? http://imgur.com/r50yY
if not wall right then turn right
instead.
i solved a problem featured on the yc company interviewstreet.com codesprint. the problem: Count the number of one-bits from 0 to 2^n - 1, for n from 1 to 20. my solution: http://i.imgur.com/hUxt0.png when you run the solution: Number of one-bits in 1 bit numbers from 0 to 1 = 1 Number of one-bits in 2 bit numbers from 0 to 3 = 4 Number of one-bits in 3 bit numbers from 0 to 7 = 12 Number of one-bits in 4 bit numbers…
Take some of that time to figure out the math and the code becomes trivial: for (n = 1; n A short explanation: http://mathbin.net/98435
(More informally: Each bit is 0 half the time and 1 half the time, because you can pair off x and 2^(n-1) XOR x. Therefore the total number of 1-bits is half the total number of bits, QED.)
Earlier quoted context omitted.
So, I'm more disturbed that most of the answers people are posting aren't general solutions: they happen to solve this maze, but don't handle corner-cases (hah! I guess that's a pun ;P) of other mazes. You may as well just hardcode the answer to this one. I actually found a similar bug in yours: you will get trapped in a square and be unable to exit, as you will constantly keep hugging the column along the left, with…
Keep in mind that I specified that this is an optimal solution for this particular map. General solutions are great, but if you have additional information for leverage, you use it. In fact, as stated in explanation of the solution, the solution solves maps which the following precedence preference: Right > Left > Straight. Just FYI, it's not a bug if you understand the limitations of a solution. General solutions fo…
Alternatively, you can spend a bunch of time proving to yourself that you have a solution that takes advantage of properties of this specific maze that gets you down to 10 blocks. However, as the result now has multiple levels of nesting and is littered with comparisons and jumps, it is going to take more time to execute and get to the end of the maze. I'd even go so far as to claim it is no longer an "optimal solution".
As you said yourself: "yes, elegant code is fantastic, but don't lose track of why we write code in the first place". I can understand spending the time to build something complex if you at least solve the general problem, but to spend more time in development to end up with a slower-to-execute answer that looks like a general solution but isn't seems to fall into your own trap ;P.
Earlier quoted context omitted.
Correct, you should see the looks on non-programmers' faces when you tell them that the first element in a Java list is #0, the second is #1, etc. It's approximately the same look as you see on programmers' faces when you tell them that the first element in a Blockly list is #1, the second is #2, etc.
Still, the blocky code reads "count with i from 0 to (get n)", but the loop generated is accessing A[0-1]..A[n-1]. JavaScript is forgiving here, but A[0..n] is not the same as A[-1..(n-1)] (at least I'm not familiar enough with JavaScript to think otherwise).
As an aside, Lua also uses 1-based indexing.