Re: fractal 512 belt balancer
I don't really understand the semantics of 4:6-6, (8*8to8)to(8*8to8)to(8*8to8), (2 * N to N) to (N * 2 to 2), 4:2*1+4=6 and similar. It's not explained anywhere and it doesn't look like what's in your paper either.JohnyDL wrote:I got the 16:48, 64:288: and 256:1536 to work by taking advantage of their square numbersJohnyDL wrote:So you then need to do a little more for full throughput, I worked out a maximum bound for the full throughput but not a formula for the perfect number, I'm guessing it's only another half as many splitters as you have rows, but I can't be certain of that as seemingly any layout I pick for redistributing the lanes to that last set of splitters in my head I can think of a set of lanes input and the outputs to match that it wouldn't provide full throughput. That's not to say it couldn't be done just to say I can't visualise and test things on this scale without my computer and factorio in front of me and while that would give you a minimum bound for full throughput balances of size 2^n, n>2 I'm not sure it works perfectly. These are the ranges I get for full throughput balancers.
4:6-6, 8:16-20, 16:40-56, 32:96-144, 64:224-352, 128:512-832, 256:1152-1920, 512:2560-4352, 1024:5632-9728
As I recall the best I've managed for my 16 to 16 is 48 splitters giving me full throughput, 288 for the 64 to 64, 1.5k for the 256 to 256. Which might mean the answer is in the middle of the range or that there are better solutions I haven't found or something else. I don't know.
(4*4to4)to(4*4to4)to(4*4to4), (8*8to8)to(8*8to8)to(8*8to8) and (16*16to16)to(16*16to16)to(16*16to16), basically allowing the full throughput by allowing N unique paths from each of the input N to N balancers to each of the outputs... I then thought maybe I could do a 32 to 32 by (8*4to4)to(4*8to8)to(8*4to4) should do the same leverage right, well taking it one or 2 steps forward I realised your fractal has done the hard work for me
the way your balancer does it's conversion from (2 * N to N) to (N * 2 to 2), that's how you leverage it into full throughput, but you don't tag it onto the same end again no the genius bit is tagging it onto the other end for full through put with the smallest number of splitters, in effect you get the exploit I was using to get throughput with fewer splitters pushed to it's limit. Not (N to N) to (N to N) sharing a few splitters which is the common way of guaranteeing full throughput while trying to use a few less splitters. No, instead you do (N * 2 to 2) to (2 * N to N) to (N * 2 to 2) Now it doesn't matter if you use the fractal N to N in the middle though I'm betting you will or some alternative (as I might), so long as it's one of the count perfect balancers with 1, 4, 12, 32, 80 etc splitters it will work. And you end up hitting that minimum sequence of splitters required for full throughput
4:2*1+4=6, 8:2*4+8=16, 16:2*12+16=40, 32:96, 64:224, 128:512, 256:1152, 512:2560, 1024:5632
I haven't practically tested it or used d4rkc0d3r's balancer program yet (I will) but the logic holds each splitter input has 2 distinct routes to each output splitter and any input pair and output pair also have distinct routes. In my head I can extend this to any equal number of lanes whether they share splitters or not as half a lane would go to one of the N to N and the other to the other and could meet back up at the other side at any point, exchanging part of one route with part of another doesn't effect the throughput and 2 half lanes can easily share the same lane without adding bottle necks. Do you agree with me on this logic?
When making a new language you kinda have to teach it to others before speaking it if you want to be understood .
N:M means N-Balancer (N inputs and outputs) with M splitters?
(8*8to8)to(8*8to8)to(8*8to8) is... what? Do you have three 64-to-8 balancers chained after another?