In the last tutorial, we encountered a problem with representing 1 as 
and 0 as 
— if we want to transform 0 into , we have to source a marble from somewhere. This can make our circuits messy.
revisiting representations
How did we end up here, anyway?
Ages ago, we chose to label with 1s and with 0s:
This was our reasoning:
- roons treats all marbles identically
- So we have to write the same value (1) on each
- Because we need 2 values, the only other place to write 0 is on each
It turns out this isn’t actually true. roons doesn’t treat all marbles identically. If it did, none of our patterns would work in the first place.
Consider this pattern:
Did the distributor 
treat A and B identically?
Put on your pedantry hats. A and B are not identical, because they are in different places.
This means we can trick the universe into encoding data in the positions of the marbles.
We call this lateral encoding. Instead of encoding values in marbles and holes — which we will now call presence encoding — we’ll encode them in the lateral (horizontal) position of the marbles.
We’re exploiting the arbitrariness of representations yet again — there was nothing special about our original scheme, so it’s perfectly fine to create another one when it’s convenient.
why lateral encoding?
Lateral encoding has some nice features. The main one is that it gives us a consistent marble supply — whether we get 
or 
, we always receive 1 and 1 .
This is very convenient for building a NOT gate:
This makes sense — we’re representing our data as and , and a crossing 
swaps and . Under LE our NOT gate doesn’t need a reservoir; it’s just a single common roon.
So why don’t we use lateral encoding for everything? In the next tutorial we’ll look at the tradeoffs.
continue
