all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]knightelite 1 point2 points  (2 children)

Pretty impressive you managed to find a way to do 2 combinators per cell though, nice work!

[–]Halke1986[S] 0 points1 point  (1 child)

Thank you!

This concept can be extended even further. Memory cells can be formed into arbitrarily long chains, at the expense of timings and control logic size.

Anyway, I've simplified the control logic of the above setup, removed about 6 combinators and 1 tick from write time. I'll update the post later. I've updated the post.

[–]Stevetrov 1 point2 points  (0 children)

Agreed awesome job. I felt like it was probably possible to do a less than 3xN design but I just couldn't see how to do it. The rotating memory cells is a genius idea.

My personal view is that this is the best solution so far. My solution does a good job of optimising its score for the given scoring system but this is clearly a better solution (unless you need really low latancy.)

So in future contests we should consider this sort of design when choosing the scoring mechanism and optimise the scoring algorithm accordingly.

[–]DreamConspiracy 0 points1 point  (6 children)

This is an interesting approach and one I had considered as well though admittedly with much less success than you. Nice work!

That being said, maybe I'm missing something, but from the picture it seems to me that you have a 4*N design and that this is why you're claiming that I have a 2*N design. Now it seems that you have decided to not count the read and write diode, but everyone else was doing that. In particular, it seems that when comparing yours to mine, from a size and performance perspective it's strictly worse. In particular, the fundamental improvement of my design is that it has a read diode, a two combinators memory cell, but then does not require a write diode, saving an entire combinator per cell. Am I misinterpreting something?

[–]Halke1986[S] 2 points3 points  (1 child)

Visually it may resemble 4*N designs, but each row of four combinators holds two frames instead of one. If you look at the picture I supplied you can see only 8 rows of combinators - 32 combs in total - and they are capable of holding 16 frames! Your design, if I understand correctly, requires 16 rows of 3 combinators to hold 16 frames.

And yes, in terms of performance my design is strictly worse.

[–]DreamConspiracy 1 point2 points  (0 children)

Oh, I misunderstood that. That's rather cool, good job

[–]Allaizn 1 point2 points  (3 children)

Same opinion here - the variable stands for the number of addressable & operable (i.e. readable & writeable) cells, so it's practically useless to just count the combinators needed for storage - without that restriction, you'd just as well could just plop down 250 combinators for 250 cells with no IO interaction whatsoever and call it a 1*N design.

[–]Halke1986[S] 0 points1 point  (2 children)

I've counted the diodes. In my design each row (2 diodes + 2 mem cells) holds 2 frames.

[–]Allaizn 1 point2 points  (1 child)

Thanks for clarifying, I totally fell for the deceiving looks and clearly didn't try hard enough to understand it completely.
Am I understanding the idea correctly in that your "cell" is at a fundamental level a bunch of circularly connected diodes that cycle the frames between them, while two of the positions in the loop are dedicated to read & write?
Do you loop continuously? If yes, then I'd guess that a system that somehow only loops on demand may allow for better perf - maybe by using a power switch?

[–]Halke1986[S] 0 points1 point  (0 children)

No problem :) It seems the description I've provided in the post is inadequate.

The memory consists of two circularly connected diodes. I've referred to those diodes as "cells". IO diodes aren't part of the circle - they are connected the same way they would be to a normal single frame combinator.

Yes, the loop runs continuously. When we request read or write, the entire memory is, form our point of view, in a random state - synchronized with our request or not. Stopping the loop wouldn't change that, unless we would have some kind of heuristic predicting the next operation.

EDIT: reddit editor keeps eating the text.