Remember Lowest / Highest Value

[Deadly-Bagel]

So as part of a system to keep track of how many robots I have in a network, and to add more when demand rises (less than 5% available bots), I needed a circuit that could remember a demand for robots and if the number fell below that before I could meet the demand it needs to remember the new number instead. As robots are added they are counted off from memory.

Surprisingly I couldn't find anything on the topic. There is a little bit on memory cells, jumping from very basic (decider looped to itself) to really complex stuff I have no hope of understanding at this time of night lol. Guess I'll get to work.

First off I created a reasonably complex setup with a timer that would process once every five ticks, 8 combinators total. I didn't like the way part of it worked so ripped it out, flipped something around and suddenly it's only three combinators and works every tick o_O gotta love unexpected efficiency (EDIT: Circuit Master XKnight pointed out there are fringe cases with every tick that won't be properly remembered)

Remember Lowest Count.jpg (94.51 KiB) Viewed 8188 times

This is actually really simple in premise. Firstly the comparer checks if the new value is lower/higher than the stored value, if it is it is, output. This disables the memory decider, clearing outs its previous value, and [A] is also converted to signal . is looped through memory and straight back to the comparer, as [A] now equals it stops outputting. This re-enables the memory unit to pick up the last tick of signal which it then stores. If the value is getting lower with every tick, the comparer simply keeps outputting [A] and is updated accordingly in the very next tick.

I will be connecting a roboport to some basic logic to take ([total robots] / -20) + [available robots] to provide the input. This gives me a negative number of how many robots below 5% I have available. Then I'll connect an inserter to the input of the memory cell to pulse any items it moves (will change to logistics bots), so as items are added the demand is "forgotten" until a higher demand arises. I guess you'd call this a "Demand Counter" or something? I can't actually think of any circumstance it would be used other than for counting robots in the network but hey, you never know =P

[cid0rz]

Hi, I like the max/min storage, can be useful with liquid levels also, to see if you are cracking enough, levels of storage (charge of acumulators also) or maybe partial results from operations so I keep the scheme in mind. It happened to me many times I had to do reverse engineering on myself because i did something clever and then got lost somewere xD

[Deadly-Bagel]

Well you can't automatically add cracking but it could be useful as an indicator of what your lowest quantity of petroleum in storage has been so you can keep an eye on it without constantly watching it. When it gets too low, add some more supply/production/cracking and reset the memory. Accumulators is one I hadn't considered, could be used to remember how low your accumulators get before your solar power kicks back in.

When (hopefully) they add an alert beacon you could pair it with this to generate an alert until the problem is resolved.

[XKnight]

Maybe this is not critical (for some builds), but I just want to point that this build requires 2 ticks to update its internal state.
This means if you send next values:
tick #100: "100 A"
...nothing...
tick #200: "110 A"
tick #201: "105 A"
...nothing...

Resulting state will be "105 A".

[Deadly-Bagel]

I think I get why. Let's say combinator A (comparer) gets a signal to pass on, it goes to combinator B (converter) and then on in to memory.

The missed tick is because C-A passes on a higher value, then in the next tick (before C-B converts it) it gets a lower value, but one that is still higher than signal . So it also passes that on, which keeps the memory disabled. Then the slightly lower value gets converted to B and is remembered instead.

So an input signal alternating high-low every tick would not be remembered correctly, though each boundary would need to increase by at least one every time it is broadcast.

Guessing it's not a particularly easy fix ^^ but I don't see why that would be a particularly big problem unless you were trying to measure hash rather than inventory or accumulator levels.

[XKnight]

Guessing it's not a particularly easy fix ^^

It is easy to fix, 2.5 combinators and 1 tick solution will be ready.

[reofarp]

It is easy to fix, 2.5 combinators and 1 tick solution will be ready.

Why do you leave us hanging like that?

This is what I came up with for a minimal 1 tick update, 1 tick delay solution:

tmp.png (51.76 KiB) Viewed 7837 times

Input: A (top left), output X (right)
bot left: -1 -> X,
top right: X > A -> X
bot right: @ > X -> X
To reset, rewire the loop for the top combinator

Things to note:

• input mustn't have positive signals other than A
• A >= 0
• Output contains A signal