[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
:zz: ZigZag Design Notes: SLICE LOGIC 1 (d6
- To: zzdev@xxxxxxxxxx
- Subject: :zz: ZigZag Design Notes: SLICE LOGIC 1 (d6
- From: Ted Nelson <ted@xxxxxxxxxx>
- Date: Tue, 14 Jul 1998 19:35:41 +0900
- Cc: ted@xxxxxxxxxxxxxx
- Reply-to: zzdev@xxxxxxxxxx
[illustration accompanying this email: zzSliceLogic.bmp]
SLICE LOGIC 1
The main objective of the ZigZag Slice system is to be able to combine
pieces of zzstructure. Relatively fixed material (ends of rows, ends of
columns, titles) are expected to stay in RAM, with other stuff coming and
- to limit RAM usage without going to some system of virtual memory
- to allow the user to select the portions being worked on
- to allow slices to slide into the middle of other slices according to the
user's desire. (Thus slices should be connectable anywhere, even in the
middle of ranks.)
MANY logics and rule-sets are possible for this. I have thought about this
for some years.
What follows is the simplest method I could work out that does the job
neatly. It is called "Slice Logic 1" because it's the easy one that I
think we should implement first. (Last week I produced a document with a
more complex system, possibly for implementation later, and quite
interesting technically-- I think-- but I want you to see this one first.)
This system need not be implemented all at once. For instance, we can
forbid Part II at first.
- - - - -
PART 0. SKIP ON FIRST READING.
0000. (If a rank has a leading edge, it cannot be a ringrank and
necessarily has a trailing edge.)
000. ASSUME that the user can neatly divide the world into slices.
Slices, like dimensions, may have any names, but with a prefix: slices
begin with "s.". Lexical order thereafter will be significant.
00. There may be a d.slice and d.slicelist, not discussed here.
(Eventually-- or now if there is a need-- the list of slices can be
maintained along d.slice, and the cells of a slice can be connected on a
list in d.slicelist. Still under consideration.)
- - - - -
PART I. PREFLET LOGIC.
0. A ZigZag slice is a data set with cells which may be connected to each
other in the ordinary ZZ way. But not necessarily; there may also be loose
cells in the slice.
1. Slice 0 (s.0) is always resident.
Other slices may be called in as needed.
2. Slices are independent structures. CONNECTIONS BETWEEN SLICES ARE NOT
OF THE USUAL KIND, with doubly-linked cells. Instead, they have
*preferred* points of attachment.
3. PREFERENCE OF ATTACHMENT IS EXPRESSED BY MEANS OF A 'PREFLET'-- a piece
of information in the cell specifying a cell in another slice to which it
would *like* to be attached, negward, in a specified dimension.
In the current design, a cell may have only one preflet in a given
4. The process of resolving preflets determines the way in which the
slices are attached. However, once attached, the slices are stitched
together doubly-linked in RAM somehow as ordinary zzcells. (Implementation
is not significant; eventually different slices should be storable by
different databases or other methods.)
5. When a slice is brought in, only the preflets of its leading edge-- all
the negend cells-- are considered. (This could be done thusly: test all
cells to see if they are negends; test all negends for preflets.)
6. Any cell with a preflet for a cell already resident, and not contested
by any other cell's preflet, gets to insert/attach itself to the specified
7. If a cell has a preflet for a cell which is not currently resident, the
preflet is ignored.
8. Two cells may have to be separated to honor a preflet specifying one of
them. These two cells will rejoin when the slice is swapped out, if
IF THEY HAVE A LOCKED LINK (not yet implemented), they may not be separated.
9. If two leading cells in two slices both have a preflet for the same
cell in another slice which is resident, the slice with lower lexical order
wins-- and the second slice attaches itself *indirectly*, to the trailing
edge (posend) of the winning cell's rank. See illustration.
10. If two leading cells in the same slice A have a preflet for the same
cell in a second slice B which is resident, the slice with lexically lower
cellname wins-- and the second slice attaches itself *indirectly*, to the
trailing edge (posend) of the winning cell's rank. See illustration.
(This would probably lead to the two ranks in A later becoming a single
rank, due to rule 12.)
11. Whenever a slice is swapped in or out, the preflets of all current
slices must be resolved again.
12. Whenever a slice is swapped out, its detached negends are given
preflets again. These preflets will normally be to the cells from which
the cell has just been detached in s.0-- either directly or indirectly.
13. If swapping a slice out severs a rank in some other slice (usually
s.0), that rank is reconnected where the swapped-out cells have just been
taken away. (This will re-attach cells which were separated by the
incoming slice, unless they have been moved.)
- - - - -
Consider the illustration. Assume that the x-axis is d.1 and the y-axis is
Not shown is s.0, which contains cells 16, 42, 131, 265 and 22. These are
not necessarily negends.
Shown are two slices, s.2 and s.4. They have leading-edge preflets for
some of the same cells in s.0.
The preflets for 13 and 22 take effect without conflict. What follows is
about resolving the others.
Both s.2 and s.4 have a leading-edge preflet in d.2 for cell 16. s.0 wins.
The cell in s.4 with a preflet for 16 connects to the *trailing* edge of
the same rank in s.2 (cell 68).
Similarly, both slices share a preflet for cell 42 in d.2. s.2 wins, and
s.4 connects to the trailing cell in the same rank, cell 4.
Similarly, both slices share a preflet for cell 265 in d.1. s.2 wins, and
s.4 connects to the trailing cell in the same rank, cell 31.
If s.2 is swapped out, preflets are considered again at the leading edges
of all slices (except s.0). Thus s.4's preflets for 16, 42 and 265 then
cause them to be directly attached to 16, 42 and 265.
If s.4 is then swapped out, each rank of s.4 which is extracted from within
a rank in s.0 causes that rank in s.0 to be reconnected.
- - - - -
PART TWO: CROSSING OF CELLS BETWEEN SLICES. (May be disallowed in Phase 1.)
13. (The user somehow knows where the slice boundaries are.)
14. If a cell is moved / hopped / connected into a different slice, and
has *no* other connections to its former slice, all its contents are moved.
The information that travels with it includes its contents, processor of
origin, cell of origin, and which slice the cell of origin is on.
15. If a cell is moved / hopped / connected / cloned into a different
slice, and retains connections to its former slice, a Remote Clone is
made. The information that travels with it includes its contents,
processor of origin, cell of origin, and which slice the cell of origin is on.
16. When a cell is swapped in, Remote Clones must be resolved.
If a Remote Clone's connections in all slices are consistent with each
other, it is considered to be one with its origin, and they are shown as
only one cell. However, if they are inconsistent-- more than one
connection posward or negative in a given dimension-- the second instance
is deemed to be a clone. After each operation its connections should be
checked for compressibility to one cell.
Theodor Holm Nelson, Visiting Professor of Environmental Information
Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
http://www.sfc.keio.ac.jp/~ted/ PERMANENT E-MAIL: ted@xxxxxxxxxx
Home Fax: 0466-46-7368 From USA: 011-81-466-46-7368
Project Xanadu (Permanent)
3020 Bridgeway #295, Sausalito CA 94965
Tel. 415/ 331-4422, fax 415/ 332-0136
Quotation of the day, 98.07.13:
"Obsolete power corrupts obsoletely." TN86