EventHorizon

What number is 7 upside-down (looks like an L to me)? What number is 4 upside-down (looks like an h in some fonts)? What number is 3 upside-down (looks like an E)? None of those remain numbers when upside-down. I don't think you got the "magic" part of the puzzle.

It turns out this problem was simpler (as well as more interesting) than I initially made it out to be... I do tend to jump to coding too quick...

Fine.....here's one (simple modification from the one with a sum of 253)

It also turns out that if your answer to question 2 was different.....there would still be a large number of solutions. Here are a few solutions (I have both programs running right now...)

So....it turns out that there are quite a few grids that fit the conditions. I'll post a list (after looking through it to remove duplicates) and my code for anyone that's interested. Here are a couple that my code has spit out as of yet (each with different sums!).

So....what are all the single digit numbers that remain valid when flipped? 0 -> 0 1 -> 1 2 -> 2 (ugly when rotationally flipped...unless using 7 segment numbers (digital clock-like)) 5 -> 5 (In an earlier post they had 2->5...which would just be flipped vertically) 6 -> 9 8 -> 8 9 -> 6 Are 2 and 5 even included in the answer? Just thought I would check...since they are a bit ugly compared to the rest. One more question......does the value the row/columns sum to when not flipped equal the value the rows/columns sum to when flipped? I didn't think it would be, but thought I'd ask anyway since the wording wasn't completely clear. Or would those questions give too much away?

What I meant is that every sufficiently powerful language has a quine. Obviously, you could easily dream up a language that does not have one, but it would be trivial/useless/intentionally handicapped. here's a quote from http://www.madore.org/~david/computers/quine.html. "Any programming language which is Turing complete, and which is able to output any string (by a computable function of the string as program — this is a technical condition that is satisfied in every programming language in existence) has a quine program (and, in fact, infinitely many quine programs, and many similar curiosities) as follows by the fixed-point theorem. Moreover, the fixed-point theorem is constructive, so the construction of the quine is merely a matter of patience, not guesswork (or intelligence as some prefer to call it ;-). This is not to imply, of course, that actually writing a short or interesting quine may not demand a lot of cleverness. Still, it says that there is nothing “magical” behind quines; and also nothing says that they have to be obfuscated, difficult to read, or devoid of comments, as they often are."

Programs that produce exact copies of themselves are called "quines." In theory (due to the fixed-point theorem), every language has at least one. It was quite an interesting concept when we covered it in my computability and complexity theory class. Here's some quines for C++......enjoy 1. #include<iostream.h> main(){char*s="#include<iostream.h>%cmain(){char*s=%c%s%c;cout.form(s,10,34,s,34,10);}%c";cout.form(s,10,34,s,34,10);} 2. #include <iostream.h> #define ENIUQ(TEMPLATE) cout << TEMPLATE << "(" << #TEMPLATE << ");}"; void main() {ENIUQ("#include <iostream.h>\n#define ENIUQ(TEMPLATE) cout << TEMPLATE << \"(\" << #TEMPLATE << \");}\";\n\nvoid main()\n{ENIUQ");}

It seems nobody's posting...so here's one sample replay. It has a score of 2 as n->\infty (this is because the mouse passes through the vertical corridors four times each and their density is 1/2 (half walls and half open squares)). Here's a tip for playing the replay.... after clicking redo once, you can press spacebar to redo again, etc. replay_2_score.zip How would you improve on it?

I updated the simulator slightly. I got rid of the scroll pane weirdness (it updates correctly now), and removed a bug in the undo/redo/history stuff (it allowed you to completely block off the cheese from the mouse). I'll look into getting the smooth movement to be more than just making it look smooth (eg, have time increase with it and include it in the history somehow (I don't really want 10* more information in the history)). I may also add in diagonal movement too (to be more like the flash game...maybe even have a checkbox to mimic the flash game's errors or add in an approximation to the score that would be received). mazestopsim.zip

Here's the beta version of my maze stopper simulator! It is just the java code (feel free to make sure I didn't hide any malicious code in there....though it is just one 1000 line file, so it may be hard to follow), so you'll need to compile it yourself. To watch a replay (I didn't include any, but you can post your strategy as a replay file) you will need to click redo repeatedly. A replay is loaded like you just undid the whole thing, so if you hit start or step it will erase the replay's history. If you have any questions, find a bug, or find something about it irritating....let me know and I'll look into answering your question/fixing the problem. Feel free to post replays with the description of your strategy...or even just of good techniques to slow the mouse down. I'll post the replay of my best strategy sometime soon......just don't go and beat my "Maze Stopper" (the flash game) scores too quickly

It was in your last and second to last posts. Guess I didn't read those too carefully/thought you mentioned it earlier. As for the simulator, it's coming along. I'm done with the gui (except for some funny behavior with the scroll pane), initialization(preferences,mouse,cheese), pathfinding, and graphics. I just need to get the mouse moving, keep scores, handle replays, and allow undo/redo.

I just found a way to up my score to 3 without using diagonal paths, and 3 1/3 using diagonal paths. It is also starting to look like it may be possible to increase it a couple times further (possibly up to some function of n, as you suggested previously). (edit -- I just read back through the posts, and didn't see a mention of this...maybe I heard it elsewhere....) I haven't yet started working on the simulator, though I thought of another feature to add -- undo/redo.

It could just be coincidence that the differences have been only 2's and 4's so far.

I'll try to put together a little simulator over this weekend, and post the source code. I have a paper I need to work on, so I may not actually get to it all that soon. Feature wish list: 1. arrows showing paths (where the mouse would go if in that square). 2. ability to set things up initially. 3. ability to choose direction preferences. 4. ability to save replays, and play them back. As well as stop the playback at any point to try something different. 5. choose the size of the grid. 6. able to change the speed of replay playback/mouse movement, and have the option of letting the mouse move 1 space when paused. 7. can choose between smooth (mouse walks from square to square) and discrete (mouse jumps 1 square at a time). Can anyone think of any other features it should have....besides ensuring world peace and curing cancer while eliminating poverty, terraforming other planets, and providing cheap renewable energy?

You basically check to see which areas are traversed over how many times. Given a fairly consistent strategy, you can come up with a score rather easily by looking at areas and wall densities, etc. It makes it a lot easier with only caring about the score in the limit.

Yet another oops.....the mouse won't go up, it will go right. But it still works.....two right, two left, etc.

Not bad. So....how will your strategy continue? And what does your score end up as?

If you look at the optimal paths from one square north and west, they will be equal in length. Since the mouse will breaks ties by going in a preferred direction, he goes, lets say, north. After going north one square, the optimal paths of one more square north and one square west are still equal in length. The mouse is required to break ties consistently based on direction, so it will go north again. It will keep going north until it is directly east of the cheese.

The mouse will not alternate N and W. In the OP, I said that the mouse has a preference for directions, and will break ties (equal length paths) consistently. So if he goes W, the paths for N and W will still be equal length paths, so the mouse will move W again. Similarly with N. Obviously, you could overcome this easily. XOOXOOXOO OXOOXOOXO OOXOOXOOX XOOXOOXOO OXOOXOOXO OOXOOXOOX (let x's be walls, and o's be open squares) I think your score would be higher. You make the mouse move along diagonal-like paths. If you look at what the grid would look like, 2/3 of the squares are open, and 1/3 are walls. The mouse travels over the unwalled squares twice, so that makes the score 4/3 as n->\infty (btw, it's nice to see another LaTeX user ). Of course, there are more unused squares at the ends, but those are insignificant as n->\infty. Not a bad first strategy to post. Think about it some more, and I'm sure you can come up with a better one.

The maze is initially empty (no walls), and you get to choose where to place the mouse and cheese. The only requirement about the initial setup of the maze is that it is large and square, has cheese in it, and the mouse. You could have walls initially, but it is equivalent to add them before the mouse moves. Finding the best initial placement of the mouse/cheese is part of the puzzle as well. Did that make it clear? Ask any more questions if you have em.

Here's a simple strategy to get people started.