Maximum density data storage
Posted: June 21st, 2014, 9:53 am
Looking over a chronology of slow-salvo technology that I wrote up recently, I realized that Calcyman's O(sqrt(log t)) diameter pattern had slipped my mind. It showed up just a month before the Gemini spaceship appeared, so it's not surprising that Life research changed direction then. It was suddenly clear that it was enormously more efficient to store construction information in glider streams, rather than in stable binary patterns on "data tapes".
Osqrtlogt.mc can be downloaded from within Golly 2.6: Help > Online Archives > Very Large Patterns. It was a last (and also very nearly first!) experiment with stable two-dimensional data storage. After early prototypes with 32x32 and 32x16 storage densities, I came up with a set of slow-salvo operations that worked inside a 16x16 diamond. This was a quick manual search, and the results now look incredibly inefficient to me -- but this is what ended up getting built into osqrtlogt.mc:
Now I'm wondering if the storage density can be quadrupled -- 8fd x 8fd seems as if it may just barely be enough space, at least if synchronized gliders are used. I would think there ought to be a destructive read operation out there that uses just a few gliders, coming from two directions... maybe from two synchronized Gemini-type construction arms. The presence of an object, most likely a block, would modify an exploratory spark. If a glider returns from such a reaction, another recipe would be triggered to rebuild the object in the same location. What's the minimum recipe for 8fd READ and WRITE -- three pairs of gliders? Maybe even just two pairs?
16fd x 16fd seemed like a good size for my original idea, which was to use only slow salvos from one direction to do READ and WRITE operations in 2D. This is why the above salvos are so ridiculously long -- I showed that it was possible for slow salvos to duplicate or move a target (a block or honeyfarm) from one 16fd open lane to the next, without disturbing the bit array. Calcyman adjusted the design by adding a secondary arm to re-create the honeyfarm "read head" wherever it was needed, instead of maintaining it and moving it from place to place.
No doubt 28 gliders is way too many, even for this task. Can anyone find a way to reduce the total cost of READ and WRITE to something less than 38 slow gliders? I suppose the current total is a bit more than 38, if the data processing salvos are really all unidirectional -- there has to be some junk left over somewhere after both READ and WRITE, so that the next salvo has a target to work with.
Osqrtlogt.mc can be downloaded from within Golly 2.6: Help > Online Archives > Very Large Patterns. It was a last (and also very nearly first!) experiment with stable two-dimensional data storage. After early prototypes with 32x32 and 32x16 storage densities, I came up with a set of slow-salvo operations that worked inside a 16x16 diamond. This was a quick manual search, and the results now look incredibly inefficient to me -- but this is what ended up getting built into osqrtlogt.mc:
Code: Select all
#C WRITE and destructive READ salvos in a 2D grid of bits
#C with 16fd x 16fd spacing. 28G read, 10G write from a honeyfarm.
x = 332, y = 329, rule = LifeHistory
145.A$144.A.A$145.2A14$129.A31.A$128.A.A29.A.A$129.2A30.2A14$113.A31.
A31.A$112.A.A29.A.A29.A.A$113.2A30.2A30.2A12$150.E$149.E.E$97.A31.A
19.E.E9.D31.A$96.A.A29.A.A19.E9.D.D29.A.A$97.2A30.2A30.2D30.2A$145.2E
7.2E$144.E2.E5.E2.E$145.2E7.2E2$150.E$149.E.E$149.E.E$150.E6$81.A31.A
31.A31.A$80.A.A29.A.A29.A.A29.A.A$81.2A30.2A30.2A30.2A12$118.E$117.E.
E$65.A31.A19.E.E9.A31.A$64.A.A29.A.A19.E9.A.A29.A.A$65.2A30.2A30.2A
30.2A$113.2E7.2E$112.E2.E5.E2.E54.3A$113.2E7.2E55.A$180.A$118.E$117.E
.E$117.E.E$118.E$186.2A$186.A.A2.3A$186.A4.A$192.A2$49.A31.A31.A31.A$
48.A.A29.A.A29.A.A29.A.A$49.2A30.2A30.2A30.2A7$205.2A$205.A.A$205.A3$
86.E$85.E.E64.3A$33.A31.A19.E.E9.D31.A22.A59.2A$32.A.A29.A.A19.E9.D.D
29.A.A22.A58.A.A$33.2A30.2A30.2D30.2A81.A$81.2E7.2E$80.E2.E5.E2.E$81.
2E7.2E2$86.E$85.E.E$85.E.E$86.E5$220.2A$17.A31.A31.A31.A42.2A62.A.A$
16.A.A29.A.A29.A.A29.A.A41.A.A61.A$17.2A30.2A30.2A30.2A41.A11.2A$167.
2A$169.A55.2A9.2A$225.A.A8.A.A$225.A10.A7$238.2A$54.D183.A.A$53.D.D
64.3A49.A65.A$.A31.A19.D.D9.A31.A22.A50.2A$A.A29.A.A19.D9.A.A29.A.A
22.A49.A.A$.2A30.2A30.2A30.2A$49.2D7.2D182.2A$48.D2.D5.D2.D111.2A68.A
.A$49.2D7.2D112.A.A67.A$172.A$54.D$53.D.D$53.D.D$54.D$183.3A$183.A$
184.A3$17.A31.A31.A42.2A$16.A.A29.A.A29.A.A41.A.A$17.2A30.2A30.2A41.A
11.2A$135.2A$137.A3$199.2A$199.A.A$199.A4$211.3A$211.A$140.A71.A$33.A
31.A73.2A$32.A.A29.A.A72.A.A$33.2A30.2A2$88.3E49.2A$20.2E66.E51.A.A$
21.2E66.E50.A$20.E$214.3A22.2A$214.A24.A.A$215.A23.A$151.3A$151.A92.
2A$152.A91.A.A$244.A2$49.A199.2A$48.A.A198.A.A$49.2A198.A$218.2A$218.
A.A33.2A$218.A35.A.A$226.3A25.A$167.2A57.A$167.A.A57.A31.2A$167.A91.A
.A$259.A$231.3A$231.A32.2A$179.3A50.A31.A.A$179.A84.A$180.A$269.2A$
269.A.A$269.A4$245.3A$245.A$182.3A22.2A37.A$182.A24.A.A$183.A23.A2$
212.2A$212.A.A$212.A2$217.2A39.2A$217.A.A38.A.A$217.A40.A$186.2A$186.
A.A33.2A$186.A35.A.A$194.3A25.A$194.A$195.A31.2A$227.A.A$227.A$199.3A
$199.A32.2A$200.A31.A.A$232.A2$237.2A$237.A.A$237.A4$213.3A64.2A$213.
A66.A.A$214.A65.A6$295.2A$295.A.A$226.2A67.A$226.A.A$226.A2$298.2A$
298.A.A$298.A14$311.3A$311.A$248.2A62.A$248.A.A69.3A$248.A71.A$321.A
4$320.3A$263.2A55.A$263.A.A55.A$263.A4$266.2A$266.A.A$266.A62.3A$329.
A$330.A12$279.3A$279.A$280.A$288.3A$288.A$289.A4$288.3A$288.A$289.A7$
297.3A$297.A$298.A!16fd x 16fd seemed like a good size for my original idea, which was to use only slow salvos from one direction to do READ and WRITE operations in 2D. This is why the above salvos are so ridiculously long -- I showed that it was possible for slow salvos to duplicate or move a target (a block or honeyfarm) from one 16fd open lane to the next, without disturbing the bit array. Calcyman adjusted the design by adding a secondary arm to re-create the honeyfarm "read head" wherever it was needed, instead of maintaining it and moving it from place to place.
No doubt 28 gliders is way too many, even for this task. Can anyone find a way to reduce the total cost of READ and WRITE to something less than 38 slow gliders? I suppose the current total is a bit more than 38, if the data processing salvos are really all unidirectional -- there has to be some junk left over somewhere after both READ and WRITE, so that the next salvo has a target to work with.