Average troughput for the last second using memory

This board is to show, discuss and archive useful combinator- and logic-creations.
Smart triggering, counters and sensors, useful circuitry, switching as an art :), computers.
Please provide if possible always a blueprint of your creation.
Post Reply
Copy link
SpookyMask
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Mar 17, 2024 3:27 pm
Contact:
Contact SpookyMask

Average troughput for the last second using memory

Post by SpookyMask »

Hello, first of all I want to thank @Qon and @mmmPi for the warm welcome. You really make me feel included.

I got encouraged by your insight and got inspired so here is my second blueprint.

It gives the exact number of pulses in the last second after the first second it started listening.

The problem the model solves is remembering the state before a whole second so that it can be discarded from the result. If we counted 17 pulses and before 60 ticks there was a pulse, we have to subract it from 17 as we are not interested what happend more than a second ago.

Solution is with bits, bits in integers. Two integers to be precise. But that is enough only for the one lane of a belt - when the pulse can be only 0 or 1. For the case when there is a pulse with value of 2, we have to double the logic. But it's simple copy and paste so that is not a problem. The model is easily scalable horizontaly (length of period measured in 30 ticks per block -- that fits in an integer --), and vertically (maximum pulse value --1+7 stack inserter needs 8 vertical blocks--)

Image

One integer (30 ticks) is not enough for precise measurement. For example, 1 item per second needs to be registered once every 60 ticks. So we need two consecutive integers to store double the data.

Image

When two lanes are used in a belt, it is possible that you recieve an impulse with value 2. With inserters the value can be even larger. So we add the cases when P >= 2, P >= 3, etc.

Image

Enjoy an example with some flashy lights:



EDIT: Updated version considering combinator delay


By the way, how can I type the BBcode for the collapsable panel with a Plus? I searched, but never found an option.
Last edited by SpookyMask on Fri Mar 22, 2024 11:51 am, edited 1 time in total.
Top
Qon
Smart Inserter
Smart Inserter
Posts: 2164
Joined: Thu Mar 17, 2016 6:27 am
Contact:
Contact Qon

Re: Average troughput for the last second using memory

Post by Qon »

SpookyMask wrote: ↑
Mon Mar 18, 2024 10:13 pm
 Hello, first of all I want to thank @Qon and @mmmPi for the warm welcome. You really make me feel included.

By the way, how can I type the BBcode for the collapsable panel with a Plus? I searched, but never found an option.
Np, pleasure is mine :)

Thanks for using [ bp] tags for blueprints now ;)
Quickly skimming through your explanations for now, but it looks like you made a pretty awesome blueprint. I like that you used the bits and shift operations to properly drop old data, and combined ints together when they overflow.
You can just quote me
My mods: Capsule Ammo | HandyHands - Automatic handcrafting | ChunkyChunks - Configurable Gridlines
Some other creations: Combinassembly Language GitHub w instructions and link to run it in your browser | 0~drain Laser
Top
mmmPI
Smart Inserter
Smart Inserter
Posts: 3575
Joined: Mon Jun 20, 2016 6:10 pm
Contact:
Contact mmmPI

Re: Average troughput for the last second using memory

Post by mmmPI »

Is this an average throughput or rather an exact throughput ? if i understood the description it's not an average, it's a perfect count, even more it's a picture of the previous 1 second of belt worth of pulses in the precise order in which they arrived.

It seem to me that you use number as area where you write 1 or 0 if there was a pulse, and then you shift to write again 1 or 0 and again so you need enough number to write 60 ticks, which means 2 numbers of 30 digits each (at least) to store enough 1 or 0 to physically represent the pulses that occured during the previous second not as a sum, but similar to the idealized computer where a a piece of memory is a tape read by a single head.

Hence the lamps, those represent those numbers there are 60 no 120 what oh right because there could be 2 pulses in a tick due to the 2 side of the belt, and you wouldn't store "2" instead you store "1" and "1" in 2 different numbers, so really there are 4 numbers used. But for inserters that could insert on the belt being read, you say it would be possible to keep track of the exact count, by extending the lamps array to also store the potential 3rd or 4rth pulse that one may need to register if they occur during the same tick.

I'm not sure i got everything right, when i see AND or >> operation, i automatically doubt what it does, it's only when I have built the number that i understand what it means ^^ If i understood what it does it's from your description, and pausing and counting things in the model, not trying to follow the signals and guess what they mean.

What 'annoyed' me with the wording "average throughput" is that it could be something that is not as precise as your contraption, for example measuring the number of pulses in the last 10 seconds, and dividing by 10, to give "average throughput". Such contraptions are efficient for throughput calculations in that they are very small and can be used to sample over long period of time without additionnal combinators, i made this one inspired by a train counter i saw on this forum already :



Now this kind of design cannot be used with fancy lamps, it doesn't work the same way, the memory is not well organized, it's just a sum, not a picture of each thing that happen in the order in which they happen. It's not as cool as an algorithm but it also fit the description you used for yours, which produce something of additionnal value. it's different yet same name. I don't know other name though, and i like the machine :)

(sometimes i notice you can create error if you empty the belt with the character, there are some excess bits that may get stuck in the numbers ? the lamps count when pausing game was 16, but the combinator signal was saying 18. So i suppose, it's in the additionnal bits that are not visible that this occur, and it stays in the machine somehow ? ) characters are not supposed to empty the belts being used for counting purposes, i know it's my fault, and i couldn't understand exactly how it happened but it also happened on the other version without lamps when i tried the same thing again several time. :twisted:
Top
SpookyMask
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Mar 17, 2024 3:27 pm
Contact:
Contact SpookyMask

Re: Average troughput for the last second using memory

Post by SpookyMask »

Thank you @Qon. mmmPi, all your understanding is correct. It's an exact troughput, my bad. The blueprint is really any good for 1 second, as you would need 60 * 2 blocks to display items per minute :) But it would be precise though.

I'll check the bug. Curious!
Top
Nidan
Filter Inserter
Filter Inserter
Posts: 263
Joined: Sat Nov 21, 2015 1:40 am
Contact:
Contact Nidan

Re: Average troughput for the last second using memory

Post by Nidan »

mmmPI wrote: ↑
Tue Mar 19, 2024 1:32 am
 Is this an average throughput or rather an exact throughput ? if i understood the description it's not an average, it's a perfect count,
I'd call it a running or moving average, but since the measured duration and the displayed duration are the same, it ends up being the same as a sum and exact.
even more it's a picture of the previous 1 second of belt worth of pulses in the precise order in which they arrived.
Yes, due to the method used for adding delay.
It seem to me that you use number as area where you write 1 or 0 if there was a pulse, and then you shift to write again 1 or 0 and again so you need enough number to write 60 ticks, which means 2 numbers of 30 digits each (at least) to store enough 1 or 0 to physically represent the pulses that occured during the previous second [...]
Correct. Elsewhere this might be called a "shift register".
(sometimes i notice you can create error if you empty the belt with the character, there are some excess bits that may get stuck in the numbers ?
That looks (in part) like a factorio bug. After slowing down the game enough to be able to read the signal from the belt, I can sometimes see 2 or 3 being reported when starting to pick up items. This increased value will go into the accumulator/memory (the OR combinator) as is, but the shifting logic is only prepared to handle at most 1 and will thus fail to negate the extras.

SpookyMask wrote: ↑
Mon Mar 18, 2024 10:13 pm
The duration measured seems to be slightly too long, I see a consistent output of 8, with 9 appearing for single ticks, in the half belt case (which is 7.5 items/s); so probably 65 ticks instead of 60. (You need to account for the time taken by the non-shifting combinators.)

The extension for inputs larger than one isn't wrong, but it's going to be a pain the larger the numbers get. Once you hit 10 just building delay combinators will result in the smaller circuit. Instead of checking ≥2, ≥3, …, I suggest isolating the individual bits (&2, &4, …), but I need to spend two additional combinators per row to do so.


Top half is a slight rearrangement of your bp, I combined all those 1<<30 combinators into one and removed some unneeded green wire.
Bottom half is my take on the problem: In addition to my suggestion above it's also vectorized. It uses more combinators right now, but that should break even once you need to handle inputs ≥3 or delays ≥67.
Top
mmmPI
Smart Inserter
Smart Inserter
Posts: 3575
Joined: Mon Jun 20, 2016 6:10 pm
Contact:
Contact mmmPI

Re: Average troughput for the last second using memory

Post by mmmPI »

SpookyMask wrote: ↑
Tue Mar 19, 2024 8:37 am
 all your understanding is correct. It's an exact troughput, my bad.
Thanks you, but MY bad you were correct, i think Nidan's wordings made me realize, it's an average of 1 second of time, it's also an exact count but it doesn't make it less of an average throughput, the average of every tick over 1 second . It's not one or the other. It is both ! My question was poorly asked by mistake sorry.
SpookyMask wrote: ↑
Tue Mar 19, 2024 8:37 am
 The blueprint is really any good for 1 second, as you would need 60 * 2 blocks to display items per minute :) But it would be precise though.
I'll check the bug. Curious!
It's also good for shorter period ! like 30 ticks or 15 ticks , maybe with adapation, again i'm not exactly sure how it works precisely i think i understand the idea, maybe i'm mostly talking about the lamps part, the way they show the history, but also the way some time frame are stored into 1 number, this is inspiring.

Instead of storing every single frame individally it give inspiration for storing , maybe 15 consecutive ticks in "1 time" and then compress into a single number.
This way it will be in binary from 0000 up to 1111, and since numbers in factorio are 32 bits it is possible to write 8 of those 4 bit number inside a single one.

So the machine would listen during 15 ticks, and output "4" in decimal, or ( 0100 ) then it could output "7" ( 0111 ) or "14"( 1110 ) and "3" (0011) , that makes 4 decimal numbers for 60 ticks, and only 16 bits for that full second. So the machine could speak only 4 time per second and stay silent the rest of time, and still describe the sum of pulses that occured during this quarter of a second during which it was silent. Less precise. Lossy compression :)

On the other hand other machines could speak at the same time. Using numbers between 16 and 240 in decimal, as those in binary are 0001 0000 up to 1111 0000. and then from 256 to 3840 and so on so as to avoid overwitting the other bits of the little numbers fit inside the bigger number.
Nidan wrote: ↑
Tue Mar 19, 2024 2:03 pm
 Correct. Elsewhere this might be called a "shift register".
I've heard that term before, maybe from you :ugeek: :lol: i think i even made one such for lamp display with scrolling text but i don't know when it applies and when not, or like which part. Is it still a shift register if you do as described just before with groups of digits into a single digit ? or is the "shift register" wording refering to the lamp area and the method used to do the fancy effect ?

Because for the scrolling text display it was more obvious to me that it would be called a shift register, but it didn't require re-arranging the bits inside of a number or give them a meaning based on their position relative to time and not to quantity as i thought is usually the case for binary number. Instead i could send into the circuit different signal to activate each lamp of the display. first lamp active if signal [A.] is 1 , second lamp if signal [B. ] is 1 , third lamp if signal [C] is 1 for a 3 pixel high screen. And it was the scrolling effect that was achieved with the "shift register". So if you sent A then B then C then B it would draw a horizontal beat. I think it applied in there, but the discussed blueprint to me is doing also other things than that. I don't know the name. Maybe bit stuffing ?

Compressing time into less time is what i see in the blueprint, because it stays precise, when broadcasting the result under the form of a number of "item per second", it is doing lossless compression, it display exact throughput.

My description with sampling every 15 ticks is less precise when doing the rendering, but it compresses more time into less time. Instead of a shift of 1 occuring every tick, it would be a shift of 4 occuring every 15 ticks. It's still "bit stuffing" and "shift register"? i think ,but it's still different than the blueprint because it's lossy it's doing sums when the original blueprint is doing perfect count. I suppose there must be words to describe those differences, i don't know them. That makes me think of music boxes :)
Nidan wrote: ↑
Tue Mar 19, 2024 2:03 pm
 Bottom half is my take on the problem: In addition to my suggestion above it's also vectorized. It uses more combinators right now, but that should break even once you need to handle inputs ≥3 or delays ≥67.
I investigated and kept a save game, where the count of both version were biaised, they showed 18 and 20 respectively and now 34 and 42. The second jump in inacurracies was caused by me mistakenly disconnecting part of the upper version from power. And doing the same again on the bottom version to see if it could have been what caused the initial divergence from 15 to 18 and 20.
I understand from this accident that the blueprint could prevent errors occuring from character picking up on belts, but that it is not self correcting. Somehow though, it doesn't have an internal state, because when the version where the misscount occured are copy pasted, they do not show a bad count, they get reset and show correct amount again, and are immune to character grabbing. That may not be the best method of investigation.

I used another one too that features this binary vizualier from Tertius connected to the bottom version, fancy lamps ! :

Top
mmmPI
Smart Inserter
Smart Inserter
Posts: 3575
Joined: Mon Jun 20, 2016 6:10 pm
Contact:
Contact mmmPI

Re: Average troughput for the last second using memory

Post by mmmPI »

mmmPI wrote: ↑
Tue Mar 19, 2024 11:42 pm
 it's an average of 1 second of time, it's also an exact count but it doesn't make it less of an average throughput, the average of every tick over 1 second
I gave it second or third thought, and for it to be an average i'd expect a division, 15/second is not average over 1 second of every tick, that would be instead 0.25 item per tick on average over 1 second, but it is "7.5 item exactly" if counting in 1 second there is no "averaging" to me , more like "aggregating" but i'm not sure of the wordings. It's an interesting machine for sure.
Top
SpookyMask
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Mar 17, 2024 3:27 pm
Contact:
Contact SpookyMask

Re: Average troughput for the last second using memory

Post by SpookyMask »

Nidan wrote: ↑
Tue Mar 19, 2024 2:03 pm
 The duration measured seems to be slightly too long, I see a consistent output of 8, with 9 appearing for single ticks, in the half belt case (which is 7.5 items/s); so probably 65 ticks instead of 60. (You need to account for the time taken by the non-shifting combinators.)
Thanks for pointing that out. Here is a more stable version - accounted for the delay in the combinators. Now it's exact, although I don't know why in some tests it needs hard reset (delete everything and paste it again).



The R flag changes to signals every tick, the result is now correctly 60.
Top
Post Reply

Return to “Combinator Creations”