Counter swapping

[VALUEX]

This guide, as all other counter computing/efficiency guides, aims to make block code almost obsolete using counters.

Concept

I will have a system, call it system S. This system will contain counters A and B, both of which I wish to swap their values. What do I mean by this? I want A to become B, and B to become A. How will we do this?

Practice

1. Place down a trigger(call it N). This trigger will start our entire system. Make it transmit on channel “start swap”.
2. Place down another trigger(call it M). M will trigger and activate on channel “start swap”, and will broadcast on “trigger a”. It will also trigger on “trigger a”.
3. Counter A(mentioned in concept) will decrease on “trigger a”, and will have a target of 0. Counter C will increase on “trigger a”, and will have a target of 0.
4. When A reaches target → M deactivates. Use a channel for this, “target = A”, and have a third trigger(call it L) that will trigger on “target = A” and activate on that channel.
5. Have trigger L increment A and decrement B(mentioned in concept). Have L be recursive using channel “trigger b”.
6. B will have a target of 0, when reached, deactivate L. Use channel “target = B”.
7. K should increment counter B and decrement C. K will broadcast on “trigger c” and receive on “trigger c”.
8. On target reached by C → deactivate K. Use channel “target = C”.

Finish

I may have made mistakes in explaining that, so if I did, please let me know! Thanks!

[PhoenixWander]

Ok hang on I’m lazy is this more memory efficient than block code?

[VALUEX]

Yes. Consumption: 235g’s(3 counters = 75g’s, 4 triggers = 160g’s, 75 + 160 = 235).

[PhoenixWander]

Well, if this really can work properly, this is insane. ~0.25% memory saved per code block

[Apollo]

This kind of makes sense.

So what I’m getting from this is that there’s a trigger loop running for each counter that flows into the other. The trigger loop stops when the counter is 0.

My main question would be: What would you need to do if you wanted to have a set target value for the counters A and B? Would you use another counter?

[VALUEX]

This is mainly to swap the values. If you want counter A and B to some number specific, you’d add two counters with the values to swap to. (I’m not sure if I understood what you meant)

[Apollo]

@VALUEX, I did some testing and I figured out this could be done with only three triggers.
The triggers have to loop themselves and then the counters have to broadcast from trigger to trigger until the entire thing is done.

[VALUEX]

So you have two triggers for the system and 1 to start the system or three for the system(swapping) itself?

[Apollo]

All three are for swapping.

[VALUEX]

Oh, ok. I had originally theorized the idea like that, but I added an extra trigger to add a way to control the system. It’s optional though.

[Apollo]

Also, do you have a problem with the counter maximum of 300? I’m referring to the loop breaker in case of a trigger loop going off forever.

Property counter loop and others

So… I am having trouble understanding this gimkit phenomenon if you connect a counter to the property when the counter is incremented, then the value of said property is increased. Now there is another function in the property device: “when value changes” NOW this gave me an idea, theoretically if you connect a button to a counter, and that counter to a property, then set it to when the property of the value is changed have it increment the counter causing the property to change going into this…

[VALUEX]

Yes, but it can be fixed by adding a 0.015s delay(I believe).

[some_kid]

How intriguing. This is useful, even as just a for loop that executes the number of times equal to a number stored on a counter.

@VALUEX

aims to make block code almost obsolete using counters.

You can’t make block code obsolete with just this. The main uses of block code are:

1. Doing complex math.
2. Checking a property against another property.
3. Accessing values stored in properties.
4. Accessing certain functionality for certain devices. (eg. changing text)
5. Accessing a property or channel based off of a variable (eg. broadcast on give_item_x)

This can slightly mitigate number 3, but doesn’t invalidate the other uses of blocks.

It’s a great guide though, and it is certainly useful!

[VALUEX]

@some_kid

You can’t make block code obsolete with just this.

Not with just this guide, with the combination of every possibly counter computation possible.
I’m pretty sure counters are turing complete (triggers definitely are), so technically, counters can replace block code (assuming no limitations like device placement, memory, and time, but because those limits exist, we can only replace blocks that revolve around computing problems. Tasks like adding a message to the activity feed would be impossible for counters given the limits that exist).

@some_kid

1. Doing complex math.
2. Checking a property against another property.
3. Accessing values stored in properties.
4. Accessing certain functionality for certain devices. (eg. changing text)
5. Accessing a property or channel based off of a variable (eg. broadcast on give_item_x)

1. Complex math is based (there is the problem of calculus–and other higher fields of mathematics–but you can solve some problems encountered in calculus using basic rules for solutions. An example is the power rule for derivatives which states: the derivative of a function ax^b is bax^(b-1) which you can translate into a bunch of counters to make the rule work; basic subtraction and multiplication) on simple math rules that are repeated many times and used in different sequences. A lot of math is just a bunch of rules and formulas that can be simplified and reconstructed into logic and basic arithmetic. There is the idea of variables out there in math, but that also has rules (solving ax + b = cx + d, simplifies to x = (b-d)/(c-a)) that can be broken down. Maybe not everything, but a great part.
2. That has been figured out here.
3. Technically, a counter is a property, or at least, can be. Because a counter can be a property, you can access a counter’s value to access a property’s value.
4. Given enough memory and time, you could place a large number of counters that represent one large text device.
5. A variable can be another property or a constant. Counters can act as reference properties in order to access the property. Accessing a counter-property from a list of counters can be thought of as memory. Each counter is a memory address with bits. We can access each counter by their address. A second list of counters/triggers can be updated to store the address and a sequence of triggers/counters handles the computation/transformation between the two lists that will extract a given counter-property given another counter-property. (I hope that makes sense…sorry for the bad explanation.)

In theory, counters can do it all, in practice, they can only go so far (triggers + counters = a much more powerful combination which gets us 85% to the finish line–beating block code).