zz,gbg": Raster naming (was Re: [zzdev] Dimension existence

[Ted Nelson <ted@xxxxxxxxxx>]

Tuukka suggests
>accurate specs: In what states of existence can a dimension be? (I
>suggest we name cell-in-the-middle-and-all-dimensions aka SingleCell
>raster as FlatRaster.)

With regard to the parenthetical part, 

>(I
>suggest we name cell-in-the-middle-and-all-dimensions aka SingleCell
>raster as FlatRaster.)

I think the matter of naming the rasters-- the system of cells
 traversed in a view-- is a fundamental issue that should be
 tackled carefully.  (Correct naming is extremely important, and
 the fact that almost everything in the computer field is misnamed
 considerably adds to the field's complexity.)

But this naming of the rasters should be kept separate from the 
 enhancements of their presentation.  For instance, Tuomas'
 wonderful vanishing perspective and looping connection lines
 are a kind of decoration that doesn't change the raster-- it's still
 a centered column raster-- but it adds useful information,
 including both the looping connections and the animation
 between views.  

- - -
As to the metaphysical part of Tuukka's question--
>In what states of existence can a dimension be? 

-- I need to have this explained to me :)

Best. Ted


I prefer to use the term "raster" for the sequences of scan
 of particular rows and columns associated with a view.
 There are many of possible interest.  The two elemental ones
 we have now might be called "row" and "column" rasters,
 except there are others conspicuously possible and possibly
 quite useful-- for example-- all the rows from the *leftmost*
 column, and all the columns from the *top* row.  So I would
 tentatively say "centered row raster" and "centered column
 raster" for these main two.



At 04:34 PM 7/25/00 +0300, you wrote:
>
>Hello again,
>Now that I have first versions of FlatRaster ready, I need some more
>accurate specs: In what states of existence can a dimension be? (I
>suggest we name cell-in-the-middle-and-all-dimensions aka SingleCell
>raster as FlatRaster.)
>
>As I wrote earlier (but you didn't have anything to say of it), at the
>moment dimensions are created the first time they're used. 'Usage' means
>creating a cell along the dimension or trying to go along the
>dimension. This way most dimensions are created when gZZ creates the
>client space or when the user cycles to the dimension in a view.
>
>This policy is good for most of cases. It doesn't assure existence of
>any implicit dimensions, however. At the moment such dimensions are
>d.cellcreation, d.slices and d.masterdim. d.cellcreation is the one
>revealing the problem: it should exist always, but as it isn't
>referenced during normal startup procedure, it isn't there (visible)
>before the user creates it (using it as a view dimension). I think it
>should be. The effect is visible in FlatRaster (I haven't commited it
>yet, though.)
>
>Possible solutions: (kinda dirty ones)
>- have a list of these implicit dimensions and "touch" them during
>startup
>- initialize d.masterdim with these implicit dimensions (also from a
>list)
>
>
>Tuukka
>
>----------------------------------------
>E-Mail: Tuukka.Hastrup@xxxxxx
>WWW:    http://www.iki.fi/Tuukka.Hastrup
>ICQ:	#11321669
>
>
>
_________________________________________
Theodor Holm Nelson              
Project Professor, Keio University SFC Campus, Fujisawa, Japan
Visiting Professor, University of Southampton, England
 ?  e-mail: ted@xxxxxxxxxx   ?  world-wide fax 1/415/332-0136
 ?  http://www.sfc.keio.ac.jp/~ted/    ?  http://www.xanadu.net
 ? Coordinates in USA      Tel. 415/ 331-4422
  Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
_________________________________________