CHECK OUT PART 2 for corrections and more math! :D kzfaq.info/get/bejne/bMudhpNl0tG2d6c.htmlsi=RLGIBlMooxlgN848

I think a more optimal way to do piston extenders for n blocks is to use modular arithmetic. ([x mod y] is the remainder when x is divided by y, e.g. 35 mod 10 = 5) [these brackets aren't required, i just use them for clarity] basically, you push the first [n mod 12] blocks ([n mod 12] -> 1), then [12 + n mod 12], and repeat until you get to n. this is actually a generalization of @abugidaiguess's method for 13 pistons. If n mod 12 = 0 (i.e. n is divisible by 12), then it saves no extra steps. But otherwise, it saves exactly [n - (ceil(n / 12)) * (n mod 12)] over what is shown in the video! some examples: 13 pistons (video): 12 -> 1, 13 -> 1; 12 + 13 = 25 steps 13 pistons (modular): 1, 13 -> 1; 1 + 13 = 14 steps steps saved: 25 - 14 = 11 30 pistons (video): 12 -> 1, 24 -> 1, 30 -> 1; 12 + 24 + 30 = 66 steps 30 pistons (modular): 6 -> 1, 18 -> 1, 30 -> 1; 6 + 18 + 30 = 54 steps steps saved: 66 - 54 = 12 500 pistons (video): 12 -> 1, 24 -> 1, ..., 492 -> 1 (that's 12 * 41, btw), 500 -> 1; 12 * (1 + 2 + ... + 41) + 500 = 10832 steps 500 pistons (modular): 8 -> 1, 20 -> 1, 32 -> 1, ..., 488 -> 1, 500 -> 1; 8 * 42 + 12 * (1 + 2 + ... + 41) = 10668 steps saved: 10832 - 10668 = 164 (that's a lot!) btw I used a computer program to generate the number of steps for that last one, so it may not be 100% accurate!

It's so cool that #SoME3 is getting some really creative entries even from the channels you wouldn't expect to join.

For the record, short (1TP/0TP) pulses will also retract blocks, *if* the block was in the extended position when the pulse was produced - so can also be time-optimised in that way

I feel like this is exactly the type of video that 3b1b loves to see with this SoME. I love how gaming communities can go together like this with the math community.

For a 13 piston extender 1 , 13 -> 1 is more optimal than 12->1, 13->1. Further for a n-piston extender rather than iterating 12->1, 24->1 … n->1 you can simply do (n mod 12) -> 1, (n mod 12) + 12 -> 1, (n mod 12) + 24 -> 1 … n -> 1

for a 13 piston extender, you can just do 1, 13 → 1 saves 11 extensions, and should be fairly simple to generalise up until 24 at least edit: as a few replies have pointed out, it actually doesn't really matter which piston is extended first. i just happened to choose 1 in my head edit 2: wow okay so it turns out the method i thought of has since been generalised by the pinned commenter (who actually called it "@abugidaiguess's method"!) i honestly didn't put much thought into the comment beyond the specific case for a 13 piston extender, so i'm really glad other people did! :D

A detailed analysis of the optimal extension sequence: Consider the total cost of an n-extension. We can consider the total cost to move all required blocks 1 block forward, 2 blocks forward, 3 blocks forward etc. separately, because each extension pushes a subset of the pistons/block which have all currently been moved forward the same amount of times (i.e. it is impossible to simultaneously push two pistons that have moved a different number of times each, because there will be an air gap in between). The first set of blocks (that needs to be moved forward once) has size n, then the next set (that moves forward twice) n - 1, then n - 2 and so on until there is only 1 block that must be moved n times. The kth of these has size (n - k + 1) and requires ceil[(n - k + 1) / 12] extensions as each extension can only push at most 12 blocks. So the total cost is the sum from k=1 to n of ceil[(n - k + 1) / 12]. Notice, however, that this is equivalent to ceil[(n - 1 + 1) / 12] + cost(n - 1), that is, ceil(n / 12) + cost(n - 1), with cost(0) = 0. This can therefore be expressed as cost(n) = ceil(n/12) * (6 + n - 6*ceil(n/12)). Also note that this lower bound is achievable because we can simply do the process one step at a time, moving forward the first n-1 pistons in ceil(n/12) steps, then the next n-2 in ceil((n-1)/12), etc. The most interesting piston extender math (in my opinion) is that of "hipster" extenders, which are piston extenders that extend beyond the wiring itself. This means in order to power pistons beyond the wiring, movable power sources such as redstone blocks or observers must be extended and retracted themselves. This makes the analysis of the optimal sequence slightly more tricky. Every distance extended/retracted beyond the wiring requires recursively using the distances 1, 2 or 3 blocks before it one or more times (in order to extend and retract the power source, and move the piston back 1 block), leading to exponential growth in the length of the sequence.

It appears 3Blue1Brown has reached the Minecrafters

after finding that dispensers are a dynamical system I'm not surprised you've found some math surrounding piston extenders that warrants a whole math explanation vid, excited to see what you've put together and best of luck with your submission

The way you parallelized this is actually really similar to how CPUs are optimized. Cpus have several stages they have to do, and they used to have to every stage before the clock cycle. But modern cpus will only do one stage per clock cycle, but will run them all in parallel by starting a new instruction on each clock cycle.

I've gotta give you props for this. This is gotta be one of the most clear explanations I've seen. No crazy music; and straight to the point, and showing the steps behind each thought and conclusion. Subbed.

14:05 The little touch with the empty blocks accentuated by the glass texture is so aesthetically pleasing!

The true infinite piston extender: A flying machine Edit: How did this get 600 likes? wow. If anything i thought i'd get criticised for dodging the video's topic

The formula at 9:11 doesn't produce optimal results every time. Take the 13 piston extender, you could do 1, 13->1 and that's 14 pushes insted of 25

So I had an idea at around 8:12, and that's that the 13 block extension could be done more simply than 12->1, 13->1. I believe that the sequence 12, 13, 12->1 would also work but with less repetition. Therefore, this disproves that the formula for sequences of individual extensions does not necessarily always give an optimal result. Edit: Well it's not something unique I've came up with, but it is still true so I'll take that. Great video as always

There is a way to think about piston extenders which I would like to share! 1. Think about the blocks being moved to be air block, instead of pistons. 2. When an air block is in a certain location, movement on the two sides doesn't interfere with each other. 3. We can look at only a single air at a time, we can simply assume the movement in the back to happen first, until the air space is filled. 4. When extending, there are N air blocks to be moved. The first air block moves N meter, and the N'th air block moves 1 meter. 5. Moving air K meter to the back takes at least K/12 piston movements, rounded up, which is written as ⌈k/12⌉. This is because air moves a maximum distance of 12 blocks per piston movement. 6. Since this is always possible, the minimal amount of piston movements for an extension of N meter is the sum of ⌈k/12⌉, from k=1 to k=N. 7. This logic works the same for retraction; the minimal amount of movements is the sum of ⌈k/1⌉=k, from k=1 to k=N, which is actually just equal to ½N(N+1), or the N'th triangular number. Personally, I think my proof is very elegant, hope this helps!

3Blue1Brown--Grant Sanderson is one of my most watched channels on youtube. You are an absolute legend for sharing with the world the wonders of Maths and Minecraft, Mattbatwings. Thank you for all that you do; this is incredible!

This is the intersection of multiple internal Venn Diagrams I have. Math, Redstone, etc. What a video! Hope your SoME3 sub wins!

9:05 You can find a quadratic lower bound on the number of elements in your extension sequence as follows. Your initial state with n pistons can be represented by a sequence P^(n+1) H^n where P denotes a piston (or the block to push) and H a "hole", i.e., air. Your final state is (P H)^n P Note that both states have the same length. All your moves, i.e., individual piston extensions, will just swap P's and H's around in the state. So this means that the n holes must be moved somehow such that they appear in the even (2nd, 4th and so on) positions, by means of piston extensions. Observe that every move must take a clump P^l H with l

I legit am so happy you are making these videos. You explained so much to me about computer science and maths better than my actual teachers. Thanks so much

I’m so excited. SoME has been a great way for a pure math undergrad like myself to pass the summer. Cant wait to see how you take things :D

oh my god this was the most beautiful math video i've ever seen

Many people commented the extension in not optimal as you said, but I'd like to contribute with what I found: For N pistons with a delay D=(N-1)//12, the optimal sequence will be: 12->1[t=0],24->[t=1],36->1[t=2],...,N->1[t=D], where the number of steps will be N+D, with D+1 parallel sequences, each one being offset in time "t" by D too. For N=12 you can do 12->1[t=0] For N=13 you need to trigger a piston

I didn't think you would participate SoME3 ! This was definitely a surprise, but a pleasant one =)

This is probably one of the most intriguing and entertaining Redstone videos I've ever watched

That's really cool! I always love seeing all the SoM videos. Yours in particular is super well editing with great pacing and great explanations.

Also, I just came up with another algorithm for piston retraction that makes waaaay more sense as just numbers. Sequence(n) = 1-> n, Sequence(n-1) Which when you write it out, let's say for 3 pistons, is 1, 2, 3, 1, 2, 1 And for 4 pistons is 1, 2, 3, 4, 1, 2, 3, 1, 2, 1 You basically have to reduce the number you're counting up to by one after each time you count to it. So for 4 pistons, you first count up to 4, then up to 3, then to 2 and finally just the one last piston. If I'm not wrong, this should be just as efficient as the sequence you mention in the video having the same number as the minimum retraction, but the numbers here just go together so well. Heck this even just works the same way you use to calculate the min retractions possible!

10:30 twin towers

The footage of you actually building the contraptions is really nice, please continue to do this

This video unironically made math interesting to me. Your visuals are really easy to follow, I only backtracked like once (I usually backtrack a lot in videos). I like how you started simple and gradually went more complex leading to formulas. I'm definitely subbing!

This was an incredible video, the visuals were super helpful and the math was impressive. Great job!

Love this, math isn't exactly the _last_ thing I think of when I think of minecraft, so it's cool to see a deep dive into one of the game's most versatile mechanics!

for a 13 piston extender can't you just do 12 then 13->1 for the extension

Glad you made this video, I've spent a lot of time thinking about this same concept. I really like your design, it is very easily scalable.

Just came up with an idea for piston pushing optimization without parallelization. This is a pretty long comment, so if you don't like math, pls don't put yourself through pain by reading this. Defining variables :- total number of pistons = x (Let's say there are x pistons) piston push limit = L = 12 piston's position argument = n (each time we identify a piston, let's call it n) time/steps taken = t (t here acts as a counter, counting the number of steps taken) Note : x and L here is a fixed values while y and n keep changing based on the state of the system. t starts at zero and is incremented each time a piston moves. Math:- mod = modulus function, returns remainder of the division of the two arguments // = floor function, returns the closest integer smaller than the division quotient n to be pushed = f(x, t) = mod(x, L) - t for t < mod(x, L) mod(x, L) + ((t + mod(x, L)) // L) + L - t + 1 for t >= mod(x, L) after each loop, t is incremented by 1 (t++) I'm pretty sure this should work. If there are any math smarty-pants who wanna double check this, pls lemme know if I went wrong somewhere...

The extension sequence you describe is not optimal for every length piston extender. For example, with the 13 extender, you can have any one of the pistons 1-12 fire, creating a gap, then just extend from 13 to 1. However, I think this is just as fast as the sequence you named with parallelization, although requiring more piston extensions. Yours is probably easier to wire though (at least smaller) because you can just repeatedly power the same line from the back.

Funfact: retraction doesnt need a long pulse. With a sticky piston and a block on it. You can use 2 short pulses to extract and then retract

It was fun to follow along with the maths of deriving the sequences you used. Before watching past 2:30 I thought through the logic of a fast retraction sequence and found the same logic of alternating pulls and extensions explained by your parallelized sequence! The 13-block dilemma I also thought through several avenues of how to cut the sequence, but the same philosophy of 12-long chunks was shared by your solution.

i love this video! the editing was fantastic and i love the math behind it.

mattbatwings and 3blue1brown crossover is not something I know I needed, but holy crap I'm all here for it O.O

Its not that sticky pistons can't retract blocks with just a one tick pulse, but that they toggle the position of the block so if the block is touching the piston, after a one tick pulse it wont be, but if the block is not, a one tick pulse will pull it in.

Amazing video! Great editing and clever solutions!

This helped me make a one sided stackable piston extender using coppet bulbs and I just wanted to say thank you for simplifying these things for us!

Very good visuals! Sloimay made very cool animations. But I'd like to see more on retraction parallelization, it seemed quite glossed over.

This is actually a great way to introduce mathematical induction, that I've never thought of as a huge maths and redstone nerd! Ty again mattbattwings and best of luck !!

Beautiful video! Well done!

Loved this video! Another interesting bit of minecraft math that I've been looking into is an algorithm for generating piston sequences for a piston door of any size

here's the optimal extension sequence: (I'm gonna be refering to pistons by p+n) let's say we have a 13 extender, so push limit becomes a problem your way of doing it results in 25 extensions, which is of course not optimal the optimal sequence for a 13PE would be to first power p1 and then do p13 -> p1 (14 extensions in total) this works because by powering p1 we've "freed" p13 from the push limit, and it can now push p12 - p2 now when that happens the next piston we would ideally want to power is p12, so we'd want it to not be at its push limit as you said the piston's number also shows how many blocks are in front of it, and since we're now at 12 push limit is nonexistent and we can just push them all in order (p12 -> p1) here's the sequence in case you're confused: 1,13,12,11,10,9,8,7,6,5,4,3,2,1 (this is for 13pe) for bigger extenders here's how you'd find the optimal sequence: first of all, your sequence formula which you asked us to figure out if it's optimal or not, is only optimal for n*12 extenders so 12,24,36 etc the reason is because your sequence happens to only allow the last piston to fire after multiples of 12 so for a 24PE because it's the largest extender for which you only need one subsequence (25+PE need at least 2 subsequences) that means it's optimal the reason your idea isn't optimal for anything other than n*12 extenders is because most of the time it's wasting extensions that's why I made the 13PE example at the start of this comment... you're using 25 extensions while you only need 14 extensions, and you only need 14 because the push limit is already no longer a problem after extending p1 another example is a 14pe, for that you'd need 16 extensions, 2 of them would be to get p14 out of the push limit (those can be anywhere in the extender, as long as they make 2 gaps in the piston line which help the p14 -> p1 sequence always be out of the push limit) and the other 14 would be just p14 -> p1 another example is a 24PE - for that you'd need 12 extensions to get the p23 out of the push limit and then another 24 extensions to make the entire thing extend, resulting in 36 extensions total, which I can say with confidence is the optimal for 24PE TLDR: here's the logic for extenders of any length: you start with trying to extend every piston beginning from the one with the largest number and going towards p1, then when you find the first one that can extend, make all the ones after it also extend in order - now do the entire thing again until you reach the n piston (n is how big the extender is) this should look like the pistons extend in chunks of 12, first p12 -> p1 then p24 -> p1 then p36 -> p1 and so on... until you reach piston [n-n mod 12] at which point you should be able to power them all in order of n -> p1 for the full extension -------------------------------- if you didn't understand anything reply to this comment and I will try to explain

but spacewalker 46 piston extender >>>>

It is just amazing work. I have very much respect to people like you, because you made whole video which have a lot of details and explains in easy way smart, little tricky and interesting thing

This was amazeballs... My head has exploded with brilliant math. Also the piston retraction is so trippy/mesmerizing!

Extending two pistions (and having one pushing the other) at the same time (in the same game tick) is possible. I uploaded a short video showing in which cases this is possible, because there are some limitations to that. I don't know if this can be used to speed up pistion extenders even more.

Just casually scrolling through for all of the people who think they are smart and found the more optimal Extention method

I love this kind of video, hope you will continue to make them after SoME3. The incorporation and application of mathematics into minecraft was really well done. My one minor piece of constructive criticism is that, while I could feel that it worked, the proof that you showed for the retraction being optimal needed to be completed. Thank you so much for this great video.

Justwatched 3b1b SoME3 recommendations. Sadly didn't see this in the 25, but did see it in the comments. So came here to watch it. Again. Good job. 👍

you cant get a proof because its not optimal, for 13 you want 12 13 12->1 which is as fast as parallel but but without any parallel use, the way you want to think of this is you want it to push 12 as many times as you can, i havent formalized exactly what you have to do to do this but something along the lines of that will result in more possibly most optimal runtime

Your design is so clean, simple, and infinitely expandable!

I see that some people want piston 1 to push the block right in front of it, and then do [13,1], but I feel like starting as close to the next chunk as possible would be a bit more optimal, as in, for 13 pistons, piston 12 pushes, then you do [13,1]. For 25 pistons, you'd do 12, then 24, then [25,1], so you always end up only doing the n->1 pushes when you can push for the entire chain, instead of having any sub-chain pushes that aren't a single push that moves 12 pistons 1 step forward to free up pistons further back in the chain. To further extrapolate: Make every multiple of 12, starting from 12*1 and working up towards 12*m < n, push the 12 blocks in front of it, and when you reach 12*(m+1) >= n, just do the n->1 push chain.

This was your best video so far!

This video was everything I was hoping it'd be from the premise. Very nice

Thank you for helping fellow youtubers by putting the music you use in the description, well all appreciate it

This is the best video I've seen in a while. Obviously math and redstone relate quite heavily, but somehow with the animations and explanation, it was very clear and concise. Thank you for your inspiration.

Loved this! Answered questions I pondered.

You did a fantastic job with this one!

Very nice! Also some clarifications: • pistons don't need a long pulse to retract, they can retract with a normal single pulse. Technically you can get away with zero tick stuff to push multiple pistons in sequence at the same time but that gets very glitchy with update order shenanigans and you really don't wanna mess with that. • as others have pointed out, the reason you can't prove that the repeated steps are optimal is cause they aren't: the modular method is! • the act of sticky Pistons leaving behind a block when powered for a single tick is called "block spitting" and it was originally a bug, much like some other redstone features (quasi-connectivity comes to mind) • we technically have infinite piston extenders and retractors, though it's a bit cheaty to call then "extenders" since those are their own category of redstone tech: if you place a piston to push something that drags a sticky piston (facing backwards) with itself - such as a slime block - and then that triggers this piston to pull the other one along, you'd have a self-dragging contraption that moves infinitely until it encounters an obstacle. You can make the movement itself trigger pistons by using observer blocks. TA-DA! You have made a *redstone flying machine*! And fun fact, observers triggering when they move is ALSO a bug that became a feature! Aaaaah Minecraft...

the way you have the parallel pisron firing reminds me of a smarter every day video called STRANGE but GENIUS Caterpillar Speed Trick with caterpillars that ride each other like a wave

I love how this breaks things down. You're wrinkling my brain frfr.

Very well explained. Good job mate

the 13-piston example is best to illustrate that the 12-1, 13-1 system isn't optimal: If you trigger piston 1 first, then piston 13 has 12 blocks in front of it. the sequence 1, 13-1 would thus work the same as your sequence of 12-1, 13-1 while only adding a single piston push to the original. For something like 24 pistons, firing piston 12 first will "break off" the front set of blocks, then piston 24 can push the latter section, but then it stalls again so you need to push 12 again, then you can pust piston 23 etc. so the sequence becomes an alternation: 12,24,12,23,12,22 etc. which should end up being a lot faster than 12-1, 24-1 I've not finished the video but i saw you ask so i thought i'd post. I tried to build something in creative mode really quickly to see what i can do but realised i don't know how to pulse the redstone signal yet lol.

Something that didnt get said here but i think is mathematically interesting is that the retraction system is just the reverse of the push system when the push limit is 1 block.

I believe using the dividsion algorithm, n=sq+r, r from 0 to q-1, is a simpler formulation, using q=12 of course. Also, i believe the most optimal (though less simple/practical) sequence for an n piston extender is as follows: Let {12m} 1 to s indicate the sequence 12, 24, ... , 12s. Let [{12m} 1 to s, n-(a-1)]r indicate the sequence which consists of the sequence in square brackets repeated r times, where "a" is a counter (so the first time a=1, second time a=2, third a=3, and so on till a=r). The optimal sequence then, for some n=12s+r, r from 0 to q-1, is: [{12m} 1 to s, n-(a-1)]r, [[{12m} 1 to s-c, (n-r)-12(c-1)-b]12](s-1), 12->1, where "a" is a counter for r, b is a counter for 12, and c is a counter for s-1 (so for the first 12 repitions, b goes from 1 to 12 but c is 1, and for the next 12 c=2, and so on until c=s-1). In essence, this moves every multiple of 12 piston (rather than doing 12m->1) then moves the "highest" piston, which goes down by 1 each iteration. In counting steps, this video's proposed sequence {12m->1} 0 to s, n->1 has 12(1+2+...+s)+n steps. The sequence proposed in this comment has r(s+1)+12s(s+1)-12(1+2+...+s) steps, which can be simplified to n(s+1)-12(1+2+...+s) steps. In comparing, note that 12(1+2+...+s)=12((s^2)-(1+2+...+(s-1))) and see that, with the video's on the LHS and this comment's on the RHS, after simplifying we have 0?=?r-12. r-12

Beautiful animations. Thx

n < 13: n --> 1, n> 13: 1 + (Number of pistons - 13) ---> (Result of the past equation ) - 1, n --> 1 (One at a time)

A few observations : 1. Extension length formula is 6*floor((n-1)/12)*(floor((n-1)/12)+1) + n 2. For retraction, two different recursive formulas are possible, depending on whether you chose 1 or 3 for the 3 piston extender. You can choose to bridge the nth gap first and then recursively bridge the next gap, on and on, or you can do it the opposite way, bridging the 1st gap, then the 2nd, and so on. Indicating relevant subsequences with a semicolon, one sequence gives 1; 2, 1; 3, 2, 1, while the other gives 1, 2, 3; 1, 2; 1. Both are the same length. In recursive notation they both start with S(1) = 1, but the one in the video is Sequence(n) = Sequence(n-1), n - > 1, while the alternative is Sequence(n) = Sequence(n-1), 1 -> n.

Honestly this is a great vid, the topic is interesting and presented very well.

i have 0 interest in redstone and hardly any interest in math but you explain this in such an interesting way that i cannot stop paying attention. its so easy to understand because of the visuals and how well you explain everything, i love this.

I didn't know I needed this video, but I'm glad I watched it, really interesting!

Beautiful explanation, im amazed

Hey, this is insanely cool! Great video ❤

Nice job this gives me some great inspiration for some new machines.

This video is so cool, good job !

For the extender, it's better to think about trying to activate the backmost piston as soon as possible, similar to how it worked without a push limit. As it's only possible to move 12 blocks at a time, start with piston 12. Next, the furthest behind 12 that can successfully activate is 24, then 36, etc. Activate all the multiples of 12 until piston n can activate, then activate all the multiples of 12 until (n-1) can activate, repeat for all pistons in the extender. So the method for an n-piston extender, in pseudocode, looks like: let k = n while k > 0 let j = 12 while j < k { push j let j = j + 12 } push k let k = k - 1 } This sequence for the 40-piston extender is: 12, 24, 36, 40, 12, 24, 36, 39, 12, 24, 36, 38, 12, 24, 36, 37, 12, 24, 36, 12, 24, 35, 12, 24, 34, 12, 24, 33, 12, 24, 32, 12, 24, 31, 12, 24, 30, 12, 24, 29, 12, 24, 28, 12, 24, 27, 12, 24, 26, 12, 24, 25, 12, 24, 12, 23, 12, 22, 12, 21, 12, 20, 12, 19, 12, 18, 12, 17, 12, 16, 12, 15, 12, 14, 12, 13 -> 1 which has 88 pushes, while your method uses 112 pushes. It's unfortunately not nearly as neat to write the sequence out nor capable of parallelization, but it definite saves pushes. I believe this is optimal, though I don't know how to go about proving it. Though it seems @arcycatten already came up with a different solution that agrees on number of pushes, has a neater sequence, and is parallelizable.

did not expect to watch an math video to the end. good job!

I don’t know if it includes this but, you can do a 12 push for anything less than 25, then do the 24-1. This saves alot of redstone

I've been playing with redstone for the last 11 years, and only now do I understand how to generalize piston extenders. This is so cool!

I saw a lot of SoME2 videos, so I’m glad this is the first SoME3 video I watch.

Now I want to create this myself. But thanks for link on your map.

Really loved watching this Video, pausing, trying to figure stuff out on my own and thinking of how your logic could be improved on!

Giving a thumb up for the easy-to-understand animations. Subscribing for your hard work explaining complicated concepts using simple words!

Damn man you put crazy effort in your videos! Very Nice

bro a SOME video by you is just such a crazy crossover i didn’t even suspect could happen. it makes sense tho 🔥

A brilliant explanation, i love it. The visuals are helping a lot. Yet i still can miss something from there... I actually really want to understand redstone, like how should you look at it, and seeking math is the right thing. This video kinda opened my eyes on how piston extenders work. Now, i should check more of your videos (and maybe I'll finally get smarter)

The proof for the Retracrion only needs a small addition to be valid for any number of blocks: -6 is proven to be ideal for a 3 piston retraction -any extra piston adds n (new number of pistons) block movements, because every block in the old chain (n-1 pistons + 1 block upfront) needs to move back one more block each -any extra piston adds n ( new number of pistons) retractions in this algorythm, becase n->1 is added at the end of it => the required block movements and the number of retractions start at the same number and rise by an equal amount for each itteration of n, therefore both numbers are equal for any given n Q.E.D.

That was great, i love MC maths an 3b1b even tho i stumbled upon this video randomly, its great that when you made assumptions that you didnt know how to prove you let it be a conjecture and not a false statement, great explanations that go through the basis of both minecraft and maths while being concize.

Your clarity is poetry.

Started watching in the background while playing minecraft, just for background audio, but I have now spent the last 15 minutes just watching the video, standing still in minecraft. Nice work, very entertaining, and awesome :)

Optimal extension is given by f(n)= ceil(n/push lim) + f(n-1) Ceil is just rounding up after division. The idea is extend the final piston while using the remaining as little as possible. This will then produce a smaller chunk of size n-1 which we apply the same rule recursively. The final piston can be extended after ceil(n/push lim) pushes, and that value corresponds to maximal chunks (meaning always pushing the push limit) lies before it.

the 1, 13 → 1 method could also be extended to always push the m first pistons, where m is n%12 (n modulus 12) when n>12. this makes it so that you push the last chunk in the beginning saving you from having to push a half filled chunck through all the other piston in the end. edit: this was written before the paralization section so with that the total time it takes is the same. although this method could still reduce total pushes.

10:20 it's the same principle used in CPUs to parallelize instructions, it's called "instruction pipelining"