How do I permute channels?

polymer · Post by **polymer** » Sat Nov 09, 2024 5:37 pm

Sorry if this is posted in the wrong place!

I currently have a circuit, that sets the recipe of a grinder based on the astroid chunk either on a belt or in storage.

Currently, I have a couple solutions, the simplest to understand, is just three decider switches in parallel checking whether a specific resource is nonzero, And outputs the recipe that uses it if so.

I'd like to make this a bit more generic if possible. I think the "real problem" is - given I know which recipes I want, how do I determine of them what's possible, given the resources to build with I'm given?

But I'm interested in solutions to both of the above.

: Example of asteroids crushed based on what's on belt; Automate_Recipe.png (3.37 MiB) Viewed 852 times

Tertius · Post by **Tertius** » Sat Nov 09, 2024 10:23 pm

It's not a permutation, it's a lookup. For every given input signal, you want to return a certain output signal.

You have a list of assignments of [a]→[1], (b]→[2], ... [N]→[n] so that if some input is [a], the output is [1], input=(b] output=[2] and so on, with less than [n] combinators. All the [1]..[n] must return some positive number (to make it valid as recipe input).

I failed so far with less than 3 combinators.
I need 1 combinator for selecting 1 signal (whatever it is, for example the largest).
Then I provide a list of possible inputs, each with an identifying value (a numeric index). With a decider combinator, this index value can be picked and assigned to a signal (I].
Then I provide a list of possible outputs, each with the same identifying value (the index). With another decider combinator, I pick the signal from the list with the corresponding index value and return it.

Works, however I need 3 combinators, so it's only useful for mapping more than 3 possible signals. It also requires the possible input values be greater then their corresponding input values, so they need to be bigger than 3 for 3 input signals.

My example (designed for oil → oil recipes, but it's the same as for asteroid recipes)

: 11-09-2024, 23-16-46.png (116.94 KiB) Viewed 808 times

: 11-09-2024, 23-18-14.png (78.7 KiB) Viewed 808 times

: 11-09-2024, 23-18-30.png (110.71 KiB) Viewed 808 times

: 11-09-2024, 23-18-49.png (107.18 KiB) Viewed 808 times

polymer · Post by **polymer** » Sun Nov 10, 2024 1:01 am

Thank you! Forcing it to select one of the ingredients at the beginning is a great idea to simplify the whole problem! I was trying to figure out how to have it operate on all the resources at the same time (and I guess, calling that a permutation wasn't a good way to communicate that goal), but your approach is much simpler.

I did manage to come up with something for the deeper problem that isn't quite as principled, but only uses one chip and constant combinator. I'm using a selector chip to randomly pick a recipe to use, the recipe then gets locked in when the inserter puts the requisite ingredients into the the grinder. It seems to work well enough for small sets of recipes, and is very simple, I'm happy!

I'll keep your solution in mind, if I need to work with a larger number of recipes.

: Small circuit to choose recipes; Simple recipe example.png (411.22 KiB) Viewed 789 times

Barn · Post by **Barn** » Mon Nov 11, 2024 5:56 am

Tertius wrote: ↑
Sat Nov 09, 2024 10:23 pm
It's not a permutation, it's a lookup. For every given input signal, you want to return a certain output signal.

You have a list of assignments of [a]→[1], (b]→[2], ... [N]→[n] so that if some input is [a], the output is [1], input=(b] output=[2] and so on, with less than [n] combinators. All the [1]..[n] must return some positive number (to make it valid as recipe input).

I failed so far with less than 3 combinators.
I need 1 combinator for selecting 1 signal (whatever it is, for example the largest).
Then I provide a list of possible inputs, each with an identifying value (a numeric index). With a decider combinator, this index value can be picked and assigned to a signal (I].
Then I provide a list of possible outputs, each with the same identifying value (the index). With another decider combinator, I pick the signal from the list with the corresponding index value and return it.

Works, however I need 3 combinators, so it's only useful for mapping more than 3 possible signals. It also requires the possible input values be greater then their corresponding input values, so they need to be bigger than 3 for 3 input signals.

My example (designed for oil → oil recipes, but it's the same as for asteroid recipes)

0eNrVV21uozAUvIt/myp8JkHqAXqGqkIOPBJrwWaNnW624gB7jz3ZnmSfTaBNSpTS7la7jVSZFzwzeIb3lCeyqQw0igtN0ifCcylakt4/kZZvBatsTbAaSEqgglwrnnsgQG0PHu4AVbIcSEcJFwV8I6nf0Ymdrdm0mmkuxYtbg+6BEhCaaw49o7s4ZMLUG1CIRSf2U9LIlrsl4iNMuAwpOSBcsOgs+RlIQK/Ln8CMR0xKNqYsQWUt/44w/mL8m2ALRzZ7jJoJ7eWy3nDBtFRTPP7NwBTfxMhVcIUq3R0RtSBaySrbwI7tOSLgtrb/vj1d4+kNDlBS8gof7byqD40VVlaGF2TUWfHtTnuSV1j6aliFT4NVIVXNbAnVN0w59Sm5dQVjg+I7owcnL4HvgO0P7wDvz/aIHl5Cb8AeDpja27J2HkOCDA/4mUpM9Bw7FxmprngYzXRQNqD6MA8UiNovspohpFYGjq9JNuSIpJPxjkexBeS8gGtak5laj6hWRsHH3L28woyVXLU6e37rj3btudLG2TCcp7vDA5bvbB/A9CLO/H0npv768ZPQEwWZAP0o1RenVEFB0pJVLR7oVgGI/nTP2V/v6T04bnEAne1X0ujG6PMGeUX4nVX9FlUXEpnMNHn1H5t898rh23/e3+FZP2DxcsSsoeDY0sZp1WCLmzB5tTiZHBOQq7mzKB4Rl+fB8YNPGUYf6OhvmkfvHHaIh305O15FwTpaJ0v8/5Yh9c4RGE5Thhen1nqu28vPdxsJeAMvXh9Z8cIrDVReqWTt/XH7rxF+Rh6uafg7AcFW9oiGWiPuQ+rTiPoP9D6iIY3dKqYBXdHArUKauFqCtbWrJXj/EleIwjXUyPz8G4GSPRrschInlnYdR9EiCuOk634D6E0fUQ==

11-09-2024, 23-16-46.png
11-09-2024, 23-18-14.png
11-09-2024, 23-18-30.png
11-09-2024, 23-18-49.png

I was using a similar setup for chunk processing and came up with another variation. I wanted it to prioritize keeping ice stocked but also be able to switch to the other recipes when ice chunks are unavailable. This is what I came up with; the main difference is that the IDs are powers of 2, and I do the mapping with an arithmetic combinator ANDing each associated ID value with the result from the decider. This lets you filter on multiple associated criteria.