Nix wrote:Here are the smallest and fastest known solutions for each level. Their correctness has been verified (up to a limit) and speed (in total execution steps to process a constant test set of inputs) measured with my checker and score keeper program 17 Androids! 12 parts 16098 steps ( 63041 in game) by Nix 42 parts 9051 steps ( 36204 in game) by Nix

I think I found a better solution for Androids! (does it count if it wouldn't work if they tested a sequence that they don't test?)with the enter door on a5, I put BR gates oriented R-right on b3 and b5, and a BR gate R-left on b4. right belts on c3 and c4, down belts on c5, d5, e5, f5, g5, h5. It works only because an even number of blue followed by an even number of red is not tested. This gives me 11 parts, but I'm not sure how many steps

aduubian: Try it in a recent version of the game and you'll see that it also now tests a huge number of inputs to find a fail (though yours will already fail on quite a simple input). To get on my list, in principle the solutions have always had to work on any input, and for that my program has tested them on quite a bunch.

If you do make a record solution, you can and should post the save code from the game (click the disk icon and copy-paste) instead of a description.

Or, better, take that save code you got from Nix's description, and slap it on the end of a link to http://www.xanthir.com/manufactoria, like turingnow most recently did with his solution for Ophanim. (Once you click that link, check out how the part of the url from the ? onward is just the level code that you get from the game.) That way everyone can just click a link to see, and run, your level.

You can also use my emulator to quickly do total-coverage testing of your machine. As Nix said, we don't accept a machine onto the lists unless it passes for all possible inputs (as far as we can tell - for most levels, just testing it on every possible input of length 10 or below is sufficient).

Nix wrote:turingnow: Rejected when should have accepted [BBRGRBRR]. I didn't look so I don't know if you can fix this.

Oops. I see where I went wrong. The in-game testing only does input length 7. All is not lost though.All that time spent optimizing (cheating) for length 7 probably helped me come up with this new Ophanim.

Thanks to Xanthir for his online checker.Thanks to Nix for his database.Thanks also for the c++ checker even though I cant get Ubuntu to install in Virtual PC.

And no, that's not a useful machine. It will obviously fail for a tape with six blue followed by six red, for example. If used in the actual game, it should fail and call you a cheater, as this level specifically tests a super-long string to fail machines like this.

And no, that's not a useful machine. It will obviously fail for a tape with six blue followed by six red, for example. If used in the actual game, it should fail and call you a cheater, as this level specifically tests a super-long string to fail machines like this.

Yes thats what I meant by "its not really satisfying" and after having used this I built a real solution for the level which won't fail for large inputs, I was just amused because this thing actually made the level easier than Androids. (I didn't know there was a newer version before ... )

Seraphim took me a long time because I misunderstood the instructions: I thought you were given a string of reds and blues (as before), and you had to insert a green in the middle if it repeated itself, or trash it otherwise (so like Judiciary, but nondestructive and on a smaller board). I never actually tried to test it until I had something working, though I did see that some of you had very small solutions, which blew my mind.

My solution:

Spoiler:

I do like aspects of my solution, but the engineers part in particular looks like a kludge of conveyors. I don't know if that can be helped, but I do think prettier solutions are possible, so if anyone tries it, I'm curious to see.

Nix wrote:aduubian: Try it in a recent version of the game and you'll see that it also now tests a huge number of inputs to find a fail (though yours will already fail on quite a simple input). To get on my list, in principle the solutions have always had to work on any input, and for that my program has tested them on quite a bunch.

If you do make a record solution, you can and should post the save code from the game (click the disk icon and copy-paste) instead of a description.

That version's malevolence engine is taking 32764 time units to test the first level and 32762 to test the second. Should they really be such large numbers?

If its a level where it tests all sequences that are at least 12 in length, that's about 213=~8k different sequences that need testing. If you take just 4 steps for each string you need to test, that's enough to get 32k. If its a six long level, you need an average of 28=256 steps for every sequence. Its quite easy to get to that sort of number.

Interestingly, IE9 pp4 now runs my emulator correctly. It doesn't animate the SVG yet, so the conveyor belts are static, and it has a somewhat strange limitation on url length right now that makes it refuse to open larger solutions, but otherwise the functioning is perfect.

(You do have to kick it into using IE9 rendering mode to make the SVG display - it's trying to default the page to IE7 rendering right now.)

ignatius wrote:Obviously, I'm somewhat late to the party, so I hope that there are still some non-robotic entities out there to read this! Anyway, for what it's worth, here are three custom levels I made:

Robojournalists!Our robotic investigators bring you today the news of tomorrow - and for all other days, too.Produce as many yellows as told by the binary input (blue=1, red=0)

Not sure what you mean, but as I never could get those links links to work with my setup, either, I styled the url after phlip's Roboparrots! post. If it doesn't work, just paste the "?cmt=.." string into the level-editor load box.

If you referred to the problem, yes, it's simply a binary to unary conversion.

If you referred to the subversive content (you ARE from Texas after all), remember that I'm just a degenerate Eurojerk and that the Robots all come from Asia, anyway (duck) ...

Our tester was involved in a freak robot accident and is now in a coma. For Teresa, we are all hoping for the best outcome. This leaves us in a bind. We need the three designs she was working on to be completed soon.Design 19Design 20Design 31

I'm not much of a tester myself, so I don't know how difficult the task I am asking for is. Good luck.

Thread necro! I don't usually read the coding forum so I missed this thread, but someone linked the game in the comic thread for Friday's comic, and so I wasted most of my weekend. I wish I'd seen it sooner!

jestingrabbit wrote:You're right, its down to 64 now. And yes, the heat death of the universe would arrive before it terminates on some very simple input.

No no, that was exactly what I was doing. The thing is, if you just input 2^n and 1, you'll be cranking for a *long* time, the complexity of the algorithm is something like C*n^2*2^n where C is on the order of about 20, and that will be plenty slow if you let n=120 for instance. Compared to my speed solution, which would solve it in linear time, and even on worst case is O(n^2) (n the length of the input), the slow solution is monumentally slow.

jestingrabbit wrote:the complexity of the algorithm is something like C*n^2*2^n where C is on the order of about 20

That's true. I need to get out of the habit of thinking of running times in terms of f(number represented by input) rather than f(size of input). I was thinking, based on that bad habit and the running times of the sample inputs (which were in the neighborhood of 5-10 minutes) that heat death was a horrible exaggeration, but actually one would only need an input of length ~100 to start approaching it, and legal inputs (under the game's cap of 50) would take longer than the age of the universe.

Just for fun, I decided to try running it on the worst-case input of length 10. I estimate it will take about an hour to run.*

Has anyone tried to do primality testing yet? I'm sure I don't want to try making one that will fit, but then I'm using around five times the number of components as other people here to do relatively simple things like reversing a string.

*Edit: it would have been done by now, but it's been running long enough that the flash app is starting to lag. This could take a while.

skeptical scientist wrote:Has anyone tried to do primality testing yet? I'm sure I don't want to try making one that will fit, but then I'm using around five times the number of components as other people here to do relatively simple things like reversing a string.

Primality testing... would be more than a little tricky. Even using space efficient forms would still leave you with a hell of a task, whether you set it in unary or binary.

Given how cold the thread is, I figure there's not much to lose in presenting some sort of crib notes on how to do stuff, or really just one thing.

Spoiler:

The basic function that you need in just about every level worth thinking about is a "guarded read", where you read a string of red and blue until you hit a green, and write the string without the last red or blue, and store what that last dot was as a spacial variable. Here's a picture of a few ways to do that.

guardedreads.png (12.1 KiB) Viewed 12426 times

The top left configuration was my first attempt, averaging about 3*n steps to get the job done, and rather huge. So it basically sucks. You can see two of them, a little mangled because they're not reading arbitrary strings but binary numbers (this slightly improves performance too), in my -- ++ solution to metatron.

Top right is one that a lot of people favour. Its very compact, but you're looking at about 4*n steps to get the job done. Good for minimal size, bad for speed.

The configuration at the bottom is what I arrived at after a lot of work on making a fast metatron. Whereas the first two take input from the north where you'd expect and spit out the bot in a different place, this configuration needs a lot of surrounding space, preprocessing the string so that you know what the first colour is, introducing the bot into the reader at one particular locale in the case of binary strings, or one of two possible locales otherwise. You also need surrounding gates and paths set up in such a way that they can deal with both input and output passing through them. They are optimal for speed though, coming in at just 2*n. Definitely worth the hassle for the speed up, but real bastards to work with.

It took me a minute to figure out that it was looping (running the machine at 50x speed), and another couple of minutes to figure out why, since figuring out what the machine is doing isn't quite like reading code. Fortunately this bug was easily fixed, once I realized what was happening.

jestingrabbit wrote:The basic function that you need in just about every level worth thinking about is a "guarded read".

That's true. I used basically the top right one (except upside down). When I first did it, I had a few extra conveyors in there, making it 50% slower and 40% bulkier, until I realized they were completely superfluous.

The bottom one is clever. It looks like, in addition to being faster, it could also be used as a much more compact way of getting something that stops reading when it gets either a yellow or a green, which I had to do for my adder. My version was much bulkier.

P.S. 184 subtractions down, 71 to go.

Edit: another couple tips:

Spoiler:

I find it helpful to think of the tape as a loop, and the start of the tape as simply being the part of the loop we are currently reading. This is because it is very easy to move the front symbol to the back, and this is a commonly used function in any solution that involves recursion. With this in mind, you generally want to mark a certain spot on the loop, namely the beginning/end (both, since it's a loop) of the initial input, with a yellow or a green.

Now, how can you quickly read to the green marker you made, keeping the symbols in the loop intact? There's a very easy way to do this, using only 6 devices and no conveyors: point a red/blue junction and a green/yellow junction at each other, and point red/blue/yellow writers at the corresponding arrows. The green writer goes next to the green arrow as well, but pointing out instead of back in.

The conveyor belt to i/o device ratio is probably a pretty good way to tell how polished a solution is. My adder is mostly conveyor belts, so it's clearly not very well designed. Of course, few conveyor belts just means that you implemented an algorithm efficiently, not that the algorithm you chose was a good algorithm to use.

P.S. I'm almost done adding 1+255 - only 39 subtractions to go. I should be done in another half hour or so. From this and the above conveyor-belt remark you can tell that I implemented a horrible algorithm poorly. But it worked, and that was good enough to finish the last level in the game.

As fate would have it, I was just thinking about this thread over the weekend because I was putting some time into Tile Factory. It's closer to the spirit of the Zachtronics games than Manufactoria, but I think it might please many of the same fans. (And the interface is infinitely better than, say, KOHCTPYKTOP.)

Like Manufactoria, it also has a wicked steep learning curve toward the end. I was thinking that I'd love to see some user-created levels that could help me see my own way through the last seven levels.

Phlip, I think I used that buffer early on, but it pretty quickly became my top left style. Its just too broad. More than two or three on the field is way too much space on something that needs to be done so frequently.

As for conveyor to i/o ratio, my final metatron is pretty much a master work of cramming more crap onto the screen. Here's a picture.

I've highlighted the four buffers I use. The middle one works out the last bit of the first number, and sends the bot on to one of the readers on the left, which find the last bit of the second number. The one on the right is all about the case where you run out of one number but not the other. It processes through that case as quickly as possible. I remember wanting to do a little more, trying to cram another path from the north to south on the eastern edge, but I don't remember what it was I wanted to do. I'm happy with it as it stands. Very happy with it. I don't need to go back to obsessively trying to shoehorn another few features into it. Not at all.

The most interesting puzzle that nearly made me go back to it all was called "rainbow" I think. You had to accept if there were all the colours in the string, reject otherwise. Really was an assault on my approach to the latter levels.

Don't forget that my Manufactoria emulator is still up and running. I haven't tried it on a really inefficient machine yet, but at the very least it gives you an easy way to link to solutions without waiting for Flash to load.

Edit: As expected, it handles the machine just fine. 1+255 completes in a fraction of a second, processing 69808 steps and finishing with a BRRRRRRRR tape. Printing the intermediate computation steps takes about 10 seconds on my computer, then the browser slows to a crawl attempting to render all that SVG.

You don't really pick up a noticeable computation delay until you starting adding 11-bit numbers, at least on my machine and browser.

I finally found out that the reason I could not bridge convayors was that I was playing in Opera XD.It was a relief to open the game in Firefox and see that bridging worked (I had not seen what they looked like untill I saw a picture in this thread). Now I can hopefully figure out the next levels.Also, very nice game (and challenging). I almost gave up when I was stuck at Androids for some time, and then I was surprised how the solution was not very complex at all, and almost seemed obvious.

gah I got through seraphim before realizing you could make conveyor belts cross each other. not a good time to get nerd-sniped either with finals next week. venting my frustration on a dead forum thread won't help.

TheMeanPenguin wrote:gah I got through seraphim before realizing you could make conveyor belts cross each other. not a good time to get nerd-sniped either with finals next week. venting my frustration on a dead forum thread won't help.

For some reason, the game won't let me cross conveyors, is there something you have to do first? However, it seems to allow me to cross conveyors when I copied and loaded a saved machine.

I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

TheMeanPenguin wrote:gah :x I got through seraphim before realizing you could make conveyor belts cross each other. not a good time to get nerd-sniped either with finals next week. venting my frustration on a dead forum thread won't help.

For some reason, the game won't let me cross conveyors, is there something you have to do first? However, it seems to allow me to cross conveyors when I copied and loaded a saved machine.

TheMeanPenguin wrote:gah I got through seraphim before realizing you could make conveyor belts cross each other. not a good time to get nerd-sniped either with finals next week. venting my frustration on a dead forum thread won't help.

For some reason, the game won't let me cross conveyors, is there something you have to do first? However, it seems to allow me to cross conveyors when I copied and loaded a saved machine.

Hold down shift when you place the belt.

Thank you.

I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.

It relies on the fact bits either propagate the carry, delete the carry, or generate a carry, regardless of the carry in (the +1).So it works out all the propagate bits, and the bit before each propagate section and puts a Y.Then, it loops over the grammar Y1 -> 10, Y0 -> 01.

Mr Mitch: Use my emulator to share machines. In Manufactoria, go to the save/load screen (the disc icon in the level editor). You'll see a long url. Replace the first part (the stuff before the ?) with "http://xanthir.com/manufactoria". It's now a link to my emulator, which can be used to easily see the machine and run tests on it.