Quad-pumped!?

Post all other topics which do not belong to any other category.
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:

Quad-pumped!?

Post by golfmiketango »

In theory, since combinators slow down in low-power situations, it should be possible to exploit the polyrhythms created between under-powered and fully-powered combinators to create "phase-modulated" combinator designs which exceed the one <stuff-tuple>/UPS bandwidth-limit of red and green wires and combinator brains.

Don't worry, devs, I'm not expecting this to be supported by the game. But I do find it to be an amusing and fairly seductive idea.
User avatar
MeduSalem
Smart Inserter
Smart Inserter
Posts: 1687
Joined: Sun Jun 08, 2014 8:13 pm
Contact:

Re: Quad-pumped!?

Post by MeduSalem »

I believe that emulating phase-modulated signals using the superposition principle on individual signals that work on a clock instead would still be easier to implement and easier to handle than trying to implement low/high-power situations on purpose to artificially slow down a combinator.

You can't exceed the 60 updates per second anyways as there are no half- or quarter-updates and anything that would happen in between getting delayed to the next update... so you'd have to superposition signals to increase the bandwidth in a single wire. That or use more parallel wires (which would be a lot easier than decomposing a superpositioned signal) if the amount of individual signals on a wire aren't enough. Which is like ridiculous since there are alphanummeric, color and item channels available... far more than enough for most practical applications in Factorio.
golfmiketango
Filter Inserter
Filter Inserter
Posts: 549
Joined: Fri Jan 29, 2016 2:48 am
Contact:

Re: Quad-pumped!?

Post by golfmiketango »

MeduSalem wrote:I believe that emulating phase-modulated signals using the superposition principle on individual signals that work on a clock instead would still be easier to implement and easier to handle than trying to implement low/high-power situations on purpose to artificially slow down a combinator.

You can't exceed the 60 updates per second anyways as there are no half- or quarter-updates and anything that would happen in between getting delayed to the next update... so you'd have to superposition signals to increase the bandwidth in a single wire. That or use more parallel wires (which would be a lot easier than decomposing a superpositioned signal) if the amount of individual signals on a wire aren't enough. Which is like ridiculous since there are alphanummeric, color and item channels available... far more than enough for most practical applications in Factorio.
Yes, all of these objections comport with my assumptions (I haven't seriously attempted to test them because I'm pretty sure. It's more of an amusing thought experiment than a serious idea).

I suppose there is an opportunity to do some real science about this, however, in that I'm not sure anybody has documented the precise method is used to slow down under-powered combinators. But if we knew... I'm not sure how useful the information would be, as it's hard to imagine how we could exploit this, except as, i.e., a means to detect low power, an application for which there is already prior art documented here on the forums.
User avatar
DaveMcW
Smart Inserter
Smart Inserter
Posts: 3733
Joined: Tue May 13, 2014 11:06 am
Contact:

Re: Quad-pumped!?

Post by DaveMcW »

The maximum possible throughput of a wire is 32 bits per signal per tick.

Any scheme to send duplicates of the same signal signal will end up reducing the number of bits per signal. (If you implement it perfectly, you can get the duplicate signals to add up to 32 bits again).

But a simpler technique is to pack four 8-bit signals into a single 32-bit packet and unpack it at the other end.
User avatar
MeduSalem
Smart Inserter
Smart Inserter
Posts: 1687
Joined: Sun Jun 08, 2014 8:13 pm
Contact:

Re: Quad-pumped!?

Post by MeduSalem »

DaveMcW wrote:The maximum possible throughput of a wire is 32 bits per signal per tick.
Exactly... there can't be any numbers greater than that on a signal channel.
DaveMcW wrote:Any scheme to send duplicates of the same signal signal will end up reducing the number of bits per signal. (If you implement it perfectly, you can get the duplicate signals to add up to 32 bits again).

But a simpler technique is to pack four 8-bit signals into a single 32-bit packet and unpack it at the other end.
Eventually depends on what kind of machine one is trying to implement... If one doesn't need to process entire words, and rather has something like a bunch of Finite State 1-bit machines that shall be controlled (which I was assuming in my previous post), then one is able to encode more signals into one 32 bit packet... but 32 bit is still the upper limit.
Post Reply

Return to “General discussion”