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 (newest version) as introduced earlier in this thread.

I'm keeping the list up to date, adding anything posted in this thread or PM'd to me.

The in-game step counts are based on Manufactoria v1.30h. If a new version gives mismatching results in some level, let me know. (The next version should at least change Generals.) If the in-game steps go over 1M, the game will tell you that the malevolence engine ran out of patience, and you'll have no way to get the actual number from the game. I'm listing the theoretical result anyway.

If you get a better in-game step count than the record here, it still may not be better with my own input set which is the actual metric. This is especially true in the levels where the in-game step counts are significantly smaller than the regular counts. I may later consider adding a new category for fastest in-game results, and also for solutions that can't handle input classes that the game doesn't use because of slight ambiguities, i.e. empty (part-)strings in binary levels and Seraphim, and odd-length inputs in Judiciary.

"Over limits" means that the solution in question requires a longer tape than the 50 used by the game and/or more steps per input than the 100k normally allowed by my checker, even with the regular inputs that are up to 11 long. The solutions should still work for any input, but tests with longer inputs have most likely been skipped as impractical as they don't affect the step counts anyway. I consider these solutions inefficient enough that I'm always also listing the best solution among those that work within the limits.

The data to generate this list, including the save codes for the solutions, is attached as a separate program readable file you can download. I keep it updated too. If you have a modified scores.txt, you can just stick the contents of the new one in the end and the program will gracefully merge, giving preference to earlier occurrences in the file.

I was originally listing the fastest solution for every size, but decided to focus on just either size or speed, no compromises. Still of course listing the fastest solution among the smallest and vice versa. The intermediate records are included in the attached file. You can also still send me intermediate solutions, and I'll add them, just not on the list above.

I improved my Ophanim speed record from 903k to 815k with some rearranging and finally duplicating large parts, moving from 60 to 115 parts.

Updated scores.txt with the latest solutions. J.P.'s over limits Metatron is still missing because the current program version doesn't handle such well.

2010-07-05

Added the step counts as calculated by the game itself as an informational extra column in the listing. I will later change my own input length limit to match the game's in the levels where the game uses longer inputs than my program. I doubt anyone protests?

2010-07-22

(not in scores.txt) Added turingnow's fast Ophanim from the thread, improving from my 815k to 771k with 101 parts.

1. Start with string followed by yellow, yellow, and green.2. Get last symbol before yellow.3. Write yellow and symbol.4. Loop until next yellow5. Write yellow and symbol.6. At green, break and rewrite green.7. When yellow after green, rewrite string, skipping yellows, and end at green.

Also, this particular design allows making more copies simply by lengthening the yellow "tail".

You ever had one of those coding moments where it just kind of flowed from your hands... and then you looked at what you just wrote and go "... wtf... how does this work? ... i don't care, it gives the right answer."

Yeah. Police just did that to me. (Put a yellow in the middle of an even-length string)

(edit: I looked through it again, and it makes a little more sense, and i de-obfuscated it abit, saving parts in the meantime.)

I dunno what to tell you, dude. Both of those work great for me here on Chrome/Win, passing total-coverage up to length 10. I'll check again when I get to work tomorrow to see if there's anything magical about Linux causing failures.

Xanthir wrote:I dunno what to tell you, dude. Both of those work great for me here on Chrome/Win, passing total-coverage up to length 10. I'll check again when I get to work tomorrow to see if there's anything magical about Linux causing failures.

Xanthir wrote:Done - http://www.xanthir.com/manufactoria.html now just contains a link to the proper folder.[snip]Edit3: Fixed! Now you can just view the board, run total-coverage testing, or test for specific strings.

Thanks, Xanthir! Looking better and better.

Now, do you mind another bug report? Running tests on this Rocket Planes code crashes the JavaScript in Chrome, during the testing of [b], with the following in the JavaScript Console:

Hah, finally beat Judiciary... after much work, I managed to take my Police solution and my Seraphim solution, neither of which were particularly small (I'm not very good at optimisation in this game...) and, after contortions, cram them together into the grid.

I mean, I figured that was the obvious way to do it from the start, but I had my doubts as to whether it would fit... and it did take some contorting...

I liked this the most among the more complicated custom levels. Just coming up with a working algorithm takes some thought, and the limited area causes trouble but not too much.

I managed to cram my solution into 78 parts, which probably isn't nearly optimal. There's almost the same amount of functional parts as you had: I have 26 conveyors+bridges. Some more functionals could be lost by sacrificing total size.

(I hope the code works, loading saved custom levels doesn't work for me after the game messed them up when I tried to have a lot of levels concurrently)

Algorithm:

Spoiler:

First turn each run into one of the color, rest in reds, yellow, green.While there are extra reds, keep dividing the total amount in half (truncating) and collect the count in binary from the remainders, placing it between the yellow and green (in reds and blues).When extra reds of all runs have been consumed, go through the tape removing the yellow and green delimiters and turning the counts into yellows and greens as specified.

Personally, I'd rather see custom levels implemented first, to some degree. Display at least shouldn't be hard - the size is listed in the end set of three numbers: ";13;3;0;" and I imagine the part codes are the same.

Ok, just spent a few minutes with the level creator. Yeah, that's super easy to parse. Only problem is that he doesn't url-escape & and = in the level names or descriptions, so it won't work on the url unless you do it manually.

The only mysterious part is the second-to-last number. It appears that it's always 3. Anyone know what affects that?

phlip wrote:Hah, finally beat Judiciary... after much work, I managed to take my Police solution and my Seraphim solution, neither of which were particularly small (I'm not very good at optimisation in this game...) and, after contortions, cram them together into the grid.

I mean, I figured that was the obvious way to do it from the start, but I had my doubts as to whether it would fit... and it did take some contorting...

Now, on to Metatron...

Heh, I did the exact same thing; I just started with somewhat smaller Police and Seraphim levels, so the two fit together without me having to do anything more difficult than a rotation.

Here's a 121 part Ophanim that's organized better - the third section is somewhat squeezed into the available area, but the whole thing is still pretty symmetric and easy to understand.

This is quite a bad attempt, though; I just haven't had time to rearrange the tests.

Spoiler:

Right now I first strip the initial reds, testing to see if either number is equal to 0 at the same time. Then I compare the two number's digits pairwise, using a yellow to keep track of where I am in each. I throw away dots that match, because they don't give any information. If I ever get a mismatch, then I move to the next stage.Third test is destructive length testing. If A had a blue while B had a red, then if A is equal or longer in size, it's larger. The reverse if A had a red while B had a blue. To help with size issues, I blue-wash both strings, since their actual value no longer matters, just their length.

This can be compactified *significantly* by swapping the second and third tests. Right now I have to duplicate the length test because the two branches have different accept/reject conditions. If I instead do a non-destructive length test first, and then only go to pairwise dot comparison when I've established that they're equal in length, it would be *way* easier, as I'd only have to write each test once. It would be faster, too, when A and B are different lengths. I've got the machine planned out in my head, I just need to sit down and write it.

Xanthir wrote:Here's a 121 part Ophanim that's organized better - the third section is somewhat squeezed into the available area, but the whole thing is still pretty symmetric and easy to understand.

This is quite a bad attempt, though; I just haven't had time to rearrange the tests.

Spoiler:

Right now I first strip the initial reds, testing to see if either number is equal to 0 at the same time. Then I compare the two number's digits pairwise, using a yellow to keep track of where I am in each. I throw away dots that match, because they don't give any information. If I ever get a mismatch, then I move to the next stage.Third test is destructive length testing. If A had a blue while B had a red, then if A is equal or longer in size, it's larger. The reverse if A had a red while B had a blue. To help with size issues, I blue-wash both strings, since their actual value no longer matters, just their length.

This can be compactified *significantly* by swapping the second and third tests. Right now I have to duplicate the length test because the two branches have different accept/reject conditions. If I instead do a non-destructive length test first, and then only go to pairwise dot comparison when I've established that they're equal in length, it would be *way* easier, as I'd only have to write each test once. It would be faster, too, when A and B are different lengths. I've got the machine planned out in my head, I just need to sit down and write it.

Mine's closer to your second idea. I've gotten it down to 108 parts, and now it's a little better organized too.

Spoiler:

First I add a yellow at the end of each number, in the upper-right corner. Then I move them back until one string ends, which takes most of the right side. Then I truncate the number that was longer - or die() trying! Finally, once they match in length, I compare them with that comparator on the left.

Last time I tried stripping the leading reds, it took a quarter of the space, and the resulting code *never* worked.

Edit: P.S. Any chance of getting a part count in your script?Edit2: I implemented red stripping on the first number only. It gave a surprisingly good speedup!

Last time I tried stripping the leading reds, it took a quarter of the space, and the resulting code *never* worked.

Huh, really? That's weird.

Spoiler:

Red-stripping should be really fast and easy. Check out the first part of my level, crammed up into the upper-left corner. It's very slightly obfuscated so I could cram it up there and gain another full row of space, but still, it's extremely easy to do red-stripping on both numbers.

Ken_g6 wrote:(Ophanim) How anyone could write this in 60 or fewer parts, when it seems like the number you're on has to be remembered by position, is beyond me.

Why does it have to be remembered by position? I'm not sure if I know what you mean, and I definitely don't know what J.P. does in his 40-part solution, but here's the algorithm (missing some details) used in both my 44-part former size record (that I just shrank to 43) and my 63-part speed record (with small tweaks). It was far from easy to squeeze it to 44, but I don't think 60 would be far from a somewhat optimized straightforward implementation.

Spoiler:

Tag the end-of-string/start of A with a yellow (it's easiest to think of the tape always as yellow, A, green, B), and needing to remember the number by position won't cause much duplication.Strip leading reds from each number: erase until blue, copy blue (if any) and the rest, copy end-marker, same for B, not many parts.Destructive bitwise comparison: read one, (separate tracks for red and blue:) copy until green, read one (move to next step if different from first read, adding one marker if necessary), copy until yellow, repeat. The final copying on each track can reuse another copier whose end-yellow can lead to the right place.Turn every blue red, but keep different end-markers (done in 6 parts, keeping in mind we're always at the start of B when entering here).Destructive length comparison: copy until end-marker, (separate tracks for yellow and green:) read one red (on no red, accept or reject depending on previous end-marker), repeat.

Many components can be entered in different places and/or melded together to save parts.

I've made the Total Coverage tests generate tests appropriate for the given level, so you can actually test your police, seraphim, etc.

I've also implemented custom levels. The implementation isn't complete yet, as I'll need to rewrite parts of the level evaluation code to finish it out, but it works for all of the "output" custom levels.

His basic approach is to look at the least significant bits of the numbers. So he's got three guarded reads, and if the bits are the same then he keeps his previous decision about the numbers, if they're different then he updates what he thought about them in an appropriate way. The decision is stored as gy at the end of the numbers for accept, yy for reject.

bocochoco, what you have right now is roughly the best "simple" machine you can design. There are faster ways to do it, but they involve going heavier into slightly odd optimizations, like Jared's solution that jestingrabbit linked.