ZZ-space and using its dimensions

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

Hello!

I've been toying with ZZ and gZZ enough to have quite a long personal
TODO list :-) Now, before running into doing this stuff, I feel like I
should have a deeper understanding of the possibilities and limitations
of the space. I think one of the most important things is to comprehend
how to use the multidimensionality right. I have read mostly the
gzigzag documentation, which gives some examples on this subject too. I
don't know if I could already find this somewhere, but here are my
thoughts. If this isn't redundant, please read through and comment.



1 Different dimensions present different kinds of atomic relations


You can do _everything_ in one dimension: think of your computers
one-dimensional RAM. 

You can do _everything_ without dimensions: graphs in CS don't have
dimensions, still one can describe any structure using only graphs.

You can do _everything_ having one dimension per relation ie. infinite
number of dimensions: here the dimensions have totally lost their
meaning, and their number means nothing.

Now, in ZigZag, it seems best to have each dimension contain all
relations of a single type. We have "d.cursor", "d.handle", 
"d.cellcreation" etc. all represent one special relationship between the
cells connected along that dimension. This seems reasonable, as we want
to describe or find out certain types of relations at a time. The
(bi)directional structure of ZigZag luckily allows us even to see these
relations in pairs, "if your my child then I'm your parent".


1.1 Splitting relations up

The first problem, encountered when thinking about ZZ by the definition,
are the limitations. How do we describe one-to-many or many-to-many
relations? Of course this is possible (we know it right away as we see
computer RAM as a special case of this), but the question is, how to
describe these relations meaningfully, so that we get some advance from
the underlying ZZ-space.

One solution given is to have clone cells, ie. dummy cells pointing to
the real cell along d.clone. This way we can create any number of
similar relations, we'll simply extend the rank along d.clone with one
clone cell per cell's relation. This way has its shortcomings: When we
get cell data we must /everywhere/ check for d.clone relation and
possibly run through the rank to get the data cell. 

|Data|
   |
|Clone|<-|uses|
   |
|Clone|<-|uses|
   |
|Clone|<-|uses|

More simple way to represent the relations is actually given here:
headcell is in one-to-many relation with its clones, witch run down the
rank along d.clone. One more way could be using d.rel for the relation
with the first of the set, and then let rest of the set run down the
rank along d.enumerate.

|uses|-|Item A|
          |
       |Item B|
          |
       |Item C|

On many-to-many relations, one way is to use conventional adjacency
matrices, marking cells in table "+" if there's a relation, " " if not.
         |Cell A| |Cell B| |Cell C|
|Cell 1| |  +   |-|  +   | |  +   |
            |        |   |    |
|Cell 2| |      |-|      |-|  +   |
            |        |        |
|Cell 3| |  +   |-|  +   |-|  +   |

This is extremely bad: we need n*m (n^2) dummy cells, we must run
through the empty cells to find the relations, there are no constraints
for the relations.

A way better is given: use one-to-many relation to both directions.
This could look like the adjecency matrix, we just remove the " " cells
and connect their positive and negative relations. (This thanks to
local euclidity)


The point is, we must break these more complex relations back to
simpler ones, probably expressing the original relation with two
dimensions. To me this seems to be a good thing. The bad thing you've
already felt: there is more than one way to do it. Now the question is,
is there always an optimal way, so we could write it down somewhere and
let everyone learn it - or do we have to learn these different ways and
learn to decide when to use each one. (Current gZZ implementation uses
several of these.)


1.2 Reserving each dimension to one relation type

Think of "d.1" and "d.2" and "d.3". What relations do they represent?
Now, take this example:

We have a simple applitude (a structure and a way to change and see it)
for e-mail. We have the contents of a mail in one cell, and the next
mail can be found poswards on "d.next" of the cell. The user sees one
message a time in the window, and he can get previous mail pressing "-"
and next pressing "+". (A _simple_ applitude, as I told you!) It's
important that the mail is on a rank on "d.next", otherwise the
applitude can't know what to do when "+" or "-" is pressed.

We have also another simple applitude, kind of a garbage collector.
When I don't need a cell anymore I can drag cells into its view, and
the next time I ask it to take the rubbish out, it'll go and
detach/erase these cells. And, you guessed it, it uses "d.next" to
get to the next cell to remove. When I try to add some junk mail to the
list, the best thing the applitude can do is to say it's not possible,
the cell is already connected along this dimension. 

Note that the clone cells won't help. If it was the content we were
interested in - like if I list things I must read - then it would
suffice to clone the e-mail for listing. And even then, the applitude
would have to know of clone cells. (Should we make these mandatory,
like I suggested d.cellcreation to be?)

The solution is to make sure each dimension is used for a single task.
We can make the applitudes configurable, make them able to choose a
fresh dimension when they're used for the first time, make it possible
to change/translate dimensions when importing data sets (be it slices or
something else) etc. If we make sure each applitude can be used with
several configurations at a time, it's also possible to mix data sets
of the same type of applitude, eg. have different lists shown by list
applitude.


The problem is, we can't have "default" dimensions - dimensions used 
for several unrelated tasks - like "d.1", "d.2" and "d.3". OK, let's
forget them, it's easy to change the places the implementation depends
on them. Now, how do we define a convenient way to travel in the space?
At the moment, we can see two or three dimensions at once. If we won't
have these "default" dimensions, it'll be a lot of turning and trying
to find one's way further. (On the current visualisations, that is. I'm
sure many clever ones can be designed.)

(To be continued with parts 2, 3, etc. if you find these useful or if
I get good comments.)


Tuukka