Decider combinator with "Anything" output

[XKnight]

Actually, this suggestion is very simple.

Now we have possibility to use circuit signal with filter inserter (set filters) and with requester chest (set requests).
The main inconvenience using these objects comes from limited amount of filtered/requested items.
This means if we send 20 different items into the inserter/requester only several of them will be actually used, and we don't have any way to know what signals are actually used inside (to workaround this problem player have to know about signal ID and this looks like very deep implementation detail).

So my proposal is to add possibility to get this information, or to solve this issue in some other way:
- unlimited amount of filtered/requested items (in my opinion this is too overpowered)
- confirmation signal from inserter/requester. This means, inserter/requester will clear all signals execept those used.
- or add additional mode into decider combinator that will use the same logic as inserter/requester.
Like: input "Anything" and output "Anything".
In this mode combinator will return first signal which satisfies given condition, for example:

combinator parameters: Anything > 250
combinator output: Anything, input count

input: 200 "A" 300 "B" 400 "C"
output: 300 "B"

[siggboy]

I like this proposal for another reason: it will finally provide an easy way to narrow down a selection of signals to a single signal ("pick one"), even if you don't care about which signal it is.

So, for example, if you have "Red 5; Green 1; Yellow 3" in a register, or "Iron 1; Coal 1; Stone 1" on a wire, and you simply want to pick one of these, right now you have to go through quite some lengths. Actually you have to put all your candidate signals in a constant array, then loop over that array with a counter and use a filter circuit and a register with a write-lock just to pick one of the signals out of the stream. That's some quite advanced circuitry to solve a simple problem, and it's not even instant (the looping requires an unknown number of ticks to succeed).

With the "anything" output the problem would be solved already.

+1 to this suggestion, please implement.

[DaveMcW]

This is worked halfway in 0.12, you could use "output = input count" to get the value of the Anything signal. But the new behavior broke it.

[siggboy]

This is worked halfway in 0.12

Halfway is a 50% solution; we'd like a 100% solution (and also preferably one that makes complete sense, not something halfway-intuitive like the 0.12 decider output).

You could not get at the original signal color if you used the "halfway" behaviour from 0.12, but that is precisely what XKnight is asking for, and what I have pointed out with my examples. In 0.12 you could check if any signal value matches the condition, and then take the signal value at the output, but the signal color was lost in the process.

I've also thought about the original proposal a bit more, and I think it should be specified as follows:

• If the "Anything" is used in both the input and output specifications of the decider, then the first matching signal should be copied verbatim to the output.
• For a "greater than" (">") condition, the lowest matching input should be output.
• For a "less than" ("<") condition, the highest matching input should be output.
• If more than one value matches the condition, the result would be undefined (any ONE of the matching inputs would be chosen as output). [In practice, it would probably be the signal with the lowest signal ID, or some arbitrary ordering from a symbol table, but it would be a Factorio implementation detail.]

Examples, with the input being "A -100; B -1; C 1; D 1; E 50"

Any < 0 => B
Any > 0 => C or D [undefined; one of these will be the output]
Any > -2^31 => A [finding the minimum]
Any < 2^31-1 => E [finding the maximum]
Any = 1 => C or D
Any = 0 => nothing
Any > 50 => nothing

Defined this way, the operation could be used for all sorts of useful calculations, for example:

• Finding the minimum and maximum value from a set of signals. Very useful, currently quite difficult.
• Easier operations on decoded binary values; this could be taking an arbitrary bit from a fully decoded value (one symbol per bit), or even any specific bit if your decoder puts the exponents into the values; special cases, such as finding the highest/lowest 1-bit, testing if a number is odd or even, etc. could be covered easily.
• Simply narrowing down an arbitrary collection of signals to one of these signals (preserving signal color and value). Right now this is very expensive as pointed out already.
• Monitoring several signals on the same wire, and triggering as soon as one of these goes above/beyond a threshold (preserving the triggering signal type and value).

And probably many more operations that are currently very awkward.

Since this extension would be 100% downward compatible (not break anything), and it's probably rather easy to implement, I'd really love to see this in 0.13. Cheers

[DaveMcW]

Still hoping to see this in 0.15.

[Optera]

So much yes.
One small implementation change and suddenly filtering specific signals, finding min/max with a single combinator are possible.

[IV]

I agree that some kind of filtering of single signals should be possible. I have had cases where this would be useful.
The lowest/highest matches would be nice to have, but are not a necessity. Once one can filter signals, one can build a for-loop that goes over all the signals and finds the maximum.

[siggboy]

The lowest/highest matches would be nice to have, but are not a necessity. Once one can filter signals, one can build a for-loop that goes over all the signals and finds the maximum.

You can do the "for-loop" filtering right now, but it's too difficult, and it takes an unknown number of ticks (in the general case).

When the output provides "Anything", which always is exactly one of the input signals, then there should be a rule that will eliminate ties in the case of multiple matches.

So while it would already be helpful if it would just output any of the signals, it's a lot better if you know how ties are broken, and that's why I've proposed the "min/max" rule.

That it helps you to actually find min and max is only a side effect.

[IV]

Most for-loops I know run in to trouble when two signals have the same value. Most are either very slow or conceptually complicated. I do think that 'one by one' for-loops over all available signals would get simpler and thus make new things possible.

To me it seems a bit artificial, since the tie breaker can not break all ties. But yes, it would be useful. Also, in your example I would expect Any > -2^31 => E, because 50 is "more" >-2^31 than -100 is, but this is just convention and I don't mind either way.

Since we are discussing places where we can write 'Any', personally, I would find it useful to also have it as a second argument in computations, so one can write Any/Any to get 1 for all available signals, or Every=Any to get true iff there is exactly one non zero signal (assuming all signals are positive). But this as a side note.

[siggboy]

Most for-loops I know run in to trouble when two signals have the same value.

I've had to build a "for loop" to extract one (arbitrary) signal and its value from an unknown set of signals. The fact that the values might reoccur was not a problem.

Here's how I made it happen: the set of candidate signals (input) was from a known alphabet. For example, your alphabet could be "all intermediate products" or "all color signals" or "all the letters". It doesn't even matter, it could even be "all the signals in the game".

The alphabet is stored in a set of constant combinators, and all the signals are numbered. E.g. it could be "Coal=1; Iron=2; Copper=3; ...", the numbers must be unique.

You can then loop over all the signals in the constant combinator(s), and use the loop output to filter the candidate signals one-by-one. As soon as you discover a candidate signal from the input, you store it in a register. I have a "write-once" register that I used for this purpose.

The worst-case runtime of this circuit is the size of your alphabet, because you have to loop through it. The combinator count is 7 (if I remember correctly).

That's the only way I know to extract the signal and the value if your input is completely unknown (only the alphabet is known).

I'm guessing it's way over the head of most players, and it's slow and the circuit is too big. It also requires setup, because you need to specify the alphabet.

To me it seems a bit artificial, since the tie breaker can not break all ties. But yes, it would be useful.

Yes, the interesting tie is if all your inputs have the same value, or if you just don't care about the values and just want to extract exactly one signal from an unknown input set. The game should output the signals in the same order as they appear in the game menu (right now the filter inserter seem to work like that, but I'm not entirely sure).

Also, in your example I would expect Any > -2^31 => E, because 50 is "more" >-2^31 than -100 is, but this is just convention and I don't mind either way.

Don't get confused by the negative numbers. If the ">" operator outputs the lowest matching signal, then it has to be "-100", which is smaller than "-50".

Maybe other tie breakers are more intuitive in this case, but they might be less intuitive in others. You can't have your cake and eat it, too :).

Since we are discussing places where we can write 'Any', personally, I would find it useful to also have it as a second argument in computations, so one can write Any/Any to get 1 for all available signals, or Every=Any to get true iff there is exactly one non zero signal (assuming all signals are positive). But this as a side note.

If you want to get "1 for all available signals" you can simply output "everything" with a value of "1" (instead of input count)...

I don't get the second part. Do you want "true" if there is only one signal present and not more?

[IV]

I've had to build a "for loop" to extract one (arbitrary) signal and its value from an unknown set of signals. The fact that the values might reoccur was not a problem.

Here's how I made it happen: the set of candidate signals (input) was from a known alphabet. For example, your alphabet could be "all intermediate products" or "all color signals" or "all the letters". It doesn't even matter, it could even be "all the signals in the game".

The alphabet is stored in a set of constant combinators, and all the signals are numbered. E.g. it could be "Coal=1; Iron=2; Copper=3; ...", the numbers must be unique.

You can then loop over all the signals in the constant combinator(s), and use the loop output to filter the candidate signals one-by-one. As soon as you discover a candidate signal from the input, you store it in a register. I have a "write-once" register that I used for this purpose.

The worst-case runtime of this circuit is the size of your alphabet, because you have to loop through it. The combinator count is 7 (if I remember correctly).

That's the only way I know to extract the signal and the value if your input is completely unknown (only the alphabet is known).

I'm guessing it's way over the head of most players, and it's slow and the circuit is too big. It also requires setup, because you need to specify the alphabet.

I know this solution, and I don't like it aesthetically.

Maybe other tie breakers are more intuitive in this case, but they might be less intuitive in others. You can't have your cake and eat it, too .

I agree. Also, now I want cake.

If you want to get "1 for all available signals" you can simply output "everything" with a value of "1" (instead of input count)...

I don't get the second part. Do you want "true" if there is only one signal present and not more?

Yes, the first example was chosen poorly. A better one would be 1000 - any, (output: any) or 1000 / any, (output: any). This I can not do, and I fail to see why "any - 1000" is ok and "1000 - any" is not.
For the second one: Yes, I want it to be true when i have exactly one signal. I could put a lamp connected to a box and set every=any as it's condition. It would burn if and only if I have one single kind of item in the box. Not for an empty box and not for an box containing different kinds of stuff.
There are of course ways to do this at the moment. It's the first one that bothers me more, but that's probably only me when I try to do stuff with as few as possible combinators.

[siggboy]

I know this solution, and I don't like it aesthetically.

I don't either, but it's the only solution available and I needed it for my system.

Yes, the first example was chosen poorly. A better one would be 1000 - any, (output: any) or 1000 / any, (output: any). This I can not do, and I fail to see why "any - 1000" is ok and "1000 - any" is not.

Yes, same here. Many times I wanted to use a virtual signal as the second operand, but it's not possible. It should be possible, but that's a different suggestion I guess.

For the second one: Yes, I want it to be true when i have exactly one signal. I could put a lamp connected to a box and set every=any as it's condition. It would burn if and only if I have one single kind of item in the box. Not for an empty box and not for an box containing different kinds of stuff.

OK, I understand it now. If there's only 1 input, then the set of "everything" would be identical to the set of "any" (which always is a 1-member set).

By the way, I think currently that wouldn't work because if there's no input at all, then the "everything=x" condition always matches. I'm not entirely sure about that but I think it's how the game currently works and it's not intuitive. I'd have to check.

There are of course ways to do this at the moment. It's the first one that bothers me more, but that's probably only me when I try to do stuff with as few as possible combinators.

Fewer combinators are always better, I'm completely with you. In some cases it's OK when the setup gets complex, but it's not OK for simple things such as "pick one of the signals, please". Those must be possible more easily.

[IV]

Yes, same here. Many times I wanted to use a virtual signal as the second operand, but it's not possible. It should be possible, but that's a different suggestion I guess.

For the second one: Yes, I want it to be true when i have exactly one signal. I could put a lamp connected to a box and set every=any as it's condition. It would burn if and only if I have one single kind of item in the box. Not for an empty box and not for an box containing different kinds of stuff.

OK, I understand it now. If there's only 1 input, then the set of "everything" would be identical to the set of "any" (which always is a 1-member set).

By the way, I think currently that wouldn't work because if there's no input at all, then the "everything=x" condition always matches. I'm not entirely sure about that but I think it's how the game currently works and it's not intuitive. I'd have to check.

Come to think of it, I'm probably wrong on what every=any should do... also, it is almost philosophical question on what it should for an empty input. As you say: back to the topic:
We need an easy way to filter out a single signal.

[Claudius1729]

I'm necroing this topic because we need a way to iterate through a signal for more complex programs. Currently, if you want to iterate through an input with no particular properties, the only possibility would be a giant mess with at least N+n combinators with N the number of different items and n the number of different signals. Probably 2*(N+n) but there might be a better solution. Anyway, N+n is obviously unwieldy.

Using the output "Anything" would be a solution to this problem, and from what I am reading, an easy one.

[dragontamer5788]

I really like this idea. I think this was a good necro.

[DaveMcW]

I really hope this makes it into 0.16.

[Sneaker2]

+1

I do like this idea as well and I have also wanted it for a long time.

Sometimes I think the decider c should also be able to output a constant (like the selection option of the second decider condition select window). Like this other values could be put out instead of just 1 and the input value. There were some times when this could have been useful.

Sometimes I would also like to see if a simple comparison between the signals of the red and green wires could be made (even if the those 2 wires had the same signal type (compare: iron count (red wire) to iron count (green wire))

This would be some great additions to the network, because they make the combinators so much more flexible, versatile and save space, thus they can be used more often in cramped spaces. (I admit I already like the recent change in 0.15, but I guess I need more )

[DaveMcW]

Please include this in 0.17!

[McDuff]

+1 to this one, trying to solve an issue this would easily solve.

[waduk]

+1 for this.

I'm a newb to combinator, trying to came up a simple way to pick any signal ; Output one random signal from multiple input, retain it's value.
But i really can't get around my head how to setup combi to do that.

Imagine my surprise, a simple thing like this is actually one of the most sought after feature by the combinator wizard in this forum.

Note :
I end up doing it like DaveMcW suggested in much older thread. It's easy to understand the logic behind it, and it's very fast.
viewtopic.php?p=250107#p250107