On Apr 27, 4:17 pm, Terry Brown <[EMAIL PROTECTED]> wrote:
> On Sun, 27 Apr 2008 08:09:30 -0700 (PDT)
> "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
>
> > Putting the children list in the tnode
> > makes sense; putting the parents list in the tnode does not.
>
> Sounds like you have this sorted out. In unified node world...
> thinking aloud also, both parents and children lists would be on the
> vnode, there being no other node on which to be...
Correct. I am thinking this is a big strike against the unified node
world: all clones must share parents.
I have just pushed some major revisions to the sax-graph world. The
new code could be called yet another "big collapse" in complexity. It
was made possible by getting really clear about what the parents list
means.
The major new "invention" is a method called
v.computeParentsOfChildren. Here it is:
def _computeParentsOfChildren (self,children=None):
'''add all nodes in v.t.vnodeList to the parent list of all v's
children.'''
v = self
if not children: children = v.t.children
for child in children:
child.parents = []
for v2 in v.t.vnodeList:
if v2 not in child.parents:
# g.trace('Adding %s to parents of %s' % (v2,child))
child.parents.append(v2)
As you can see: it reconstitutes the parent list of v's children (or
the given children) by appending v and all clones of v to each child's
parent list.
It turns out that I had various versions of this code scattered in
various places. Have a name for this operation really improves the
code's reliability and clarity.
Besides being called in the read and undo code, this code appears "in
line" in the p._link methods.
I have hopes that this is the last big piece of the puzzle. All unit
tests pass, and I am about to start using the code for real. However,
I still do not recommend the code for your testing yet--some nasty
bugs may remain.
Edward
P.S. Code such as:
if v2 not in child.parents:
child.parents.append(v2)
appears in many places in the graph world's internal code. Such code
could be simplified by using Python sets, though that would mean that
Leo would require Python 2.4 or above.
But my real point is that the asymmetry between v.parents and
v.t.children is that v.parents is in essence a set, while v.t.children
is a list in which position matters (a lot). Perhaps this is the
clearest way to demonstrate the asymmetry.
P.P.S. Today's work as been tons of fun. It is rare, I think, to have
such basic computer-science algorithms be so important in practice.
The only other example in Leo that comes to mind is the sort/merge
algorithm in the new colorizer.
EKR
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~----------~----~----~----~------~----~------~--~---
