Re: [zzdev] More about dimensions (lists)

[Tuukka Hastrup <Tuukka.Hastrup@xxxxxx>]

On  8 Aug, Tuomas Lukka wrote:
>> This seems like a problem. It comes from the ZZ space axioms - the
>> possiblity to have loops, I mean. It makes the model clean, there's no
>> need for special restriction "you can't loop". But the general data
>> structure case is to not have loops. And every loop can be reduced to a
>> list. Think about the DimLists: there's a finite number of dimensions,
>> but infinite number of steps forward. You can want it to be infinite so
>> you can cycle through it forever, but you can also want to get just a
>> finite list containing all the dimensions.
> 
> There are supposed to be headcells for looping lists. With them, reading
> just the dimensions is going to be easy. You can also see manually whether
> you're looping.

Here, it seems like we're destroying the loops. When a loop has
a beginning, it also has an end. And this defines a list.

>> In short: DimList cycle is just a hack to make it easier to cycle
>> through dimensions. Is it so with every other loop too?
> 
> You could also say that ZigZag is a hack to mke it easier to structure and
> visualize information naturally. Both are equally true in a sense.

A hack? A well defined structure. I mean, does it _tell_ something,
mean something, to have a rank that loops? Because at least as a list,
a looping rank _means_ an infinite list. And as there is finite amount
of dimensions, a loop is a hack.

And imho we're talking about that naturalness. It's not natural to be
consistent or exact, but we'll need it for the abstractions in our code.
We should think over these and then implement the higher level
abstractions ourselves, to eliminate the need to be consistent later on.
We're building a universal data structure, a system based totalitarily
on it, _and_ a framework. Isn't it the framework designer task to think
over the best ways to do things and then give an implementation to these
ways?

>> Suggestion #1: we rename d.2 as d.next and give it the honour to be one
>> of the very special dimensions in ZZ space, implementing one-to-many
>> relations.
> 
> Clones are also a one-to-many relation. Should that too be handled on
> d.next? 

Shall I say: a good question =) Not really, we don't need to. At the
moment clones are clones of the cell before them. For the first time,
you clone the data cell, after that you clone just the clone cell. So
we have these relations that "cascade" like d.next and d.clone.

But we might want to think this through, however =) These cascading
relations are a very interesting case: the headcell really has a
meaning - it's the first or the original or the one pointed to etc. 

Let's imagine d.clone turned into a corner list (I don't want to do
this to d.next right now! ;-) It would be as easy as before to find the
original cell from a clone. What would it change? You could distinguish
between "a clone of a clone" and "another clone of the original." It
would be more complex to create a clone: you'd have to check whether
the clone list for this cell already existed and perhaps initialize the
list.

At first glimpse, it seems to me it wouldn't be worth the effort to
make d.clone a corner list. But this could change if we are to provide
a general interface to one-to-many relations.

> In a sense, d.2 *is* the d.next you are thinking about: Ted's
> comment about it is that it's usually used to indicate sequence.

A part yes, a part no. "Usually" is not enough. Make it 'always' and
I'll make it a ZZSpace property like d.clone and d.masterdim, and
provide a general interface to it. Then it could help the users to know
it by name "d.next". I see it could be possible, because d.next is
really important and omnipresent - it's one-to-many relations
everywhere.

As we're talking about this, we could find out if it would be possible
to generalize d.1 and d.3 too. d.1 seems to mean pretty much "is a"
(often a list) or "is defined by" or "is sum of these parts". d.3 is
not used so much (maybe some other dimension could be more important),
but it's found in meanings "inheritance" and "superclass", abstraction:
"is-a-special-case-of".

I feel very smart doing this (please don't _shoot_ but take me down ;-)
I've felt there's never going to be a clean way to deal with these
thousands of dimensions. Or dozens - our "ZZ Subgroup's" nickname is
"d.n haters" =)

>> Suggestion #3: think through the loops now; could we get rid of them,
>> should we make special operations for them (ie. getNeighbour and
>> getLoopNeighbour), should we always have both a looping and a
>> non-looping version of lists (along d.next and d.lnext)
> 
> I feel that this would be unnecessary complexity: if you are afraid of
> loops, you should simply use LoopDetector. It's very simple and cheap. 
> Because if your structure is any more complicated than a list, you *are*
> going to have potential loops and removing lops from lists is not going to
> help you any.

Two different things here:
- be careful to avoid crashes when it's possible to run to an infinite
loop
- have the structure represent the meaning

LoopDetector's clever. (It could detect small loops too). But I wasn't
talking about this technical problem. An example: in compass raster, I
go through the DimList loop. I will get some dimensions several times,
and I will show them several times. This is wrong. 

I thought the looping was there because you'd like to represent a
structure that has loops. Not because you didn't want to check
end-of-loop and loop manually. For the first purpose, the feature is
relevant, for the second we could've just defined an interface function
instead.

This dimension list example is a good example: there's a good reason to
have and to not to have the dimensions as a loop. We'll want these both
at the same time. I could make an advanced guess, though: whatever is
using the list will now whether it wants a loop or a rank. So it could
decide between getNeighbour and getLoopNeighbour. But I called this a
problem: this way the looping link would mean nothing at all. Bye bye
all mathematical beauty.
 
>> Suggestion that-is-the-most-relevant: think about this, tell me why I'm
>> wrong, and tell me what to do in compass raster :-)
> 
> Maybe change d.masterdim to d.2?

Yup, these is sure the right thing to do for the dimension list. But
it's a more general problem. We'll get lots of corner lists. Should be
spec this stuff and make it a supported feature? 


Tuukka

P.S. Sorry. I'm trying to spare words, but it's not that easy.

---------------------------------------
E-Mail: Tuukka.Hastrup@xxxxxx
WWW:    http://www.iki.fi/Tuukka.Hastrup
ICQ:	#11321669