[Phylobase-devl] Aug. virtual hackathon

[François Michonneau]

> > I think it addresses 2 issues:
> > 1. It seems to me that in the trunk version, it's difficult to make sure
> > that the labels are returned in the correct order or in a way which
> > allows the user to know which node is associated with each label. Also,
> > it seemed to me that if we start to provide functions to reorder the
> > trees then the issue of matching nodes and labels could have been
> > complicated. Adding these internal names to the labels provide a more
> > transparent way of matching labels than relying on the order of the
> > nodes that can be altered by reordering methods.
> 
> I don't mean to belabor this, but I still don't quite understand.  My understanding was that node.label was a vector where the index corresponded to the node number. Tree reorder only changes the order of the edge matrix and the vectors of edge.length and edge.label.  It doesn't change the node numbers or the order of the node.label vector.

Sorry for not being more precise here, but I don't remember what exact
problem I was facing with the way node labels are stored in the trunk.
Maybe it was because I was already thinking about allowing non-unique
node labels...

> > 2. The other advantage of using these internal names is that it's going
> > to be possible to allow non-unique names for labels and keeping the
> > option of having different data associated with nodes named
> > identically. 
> 
> If I understand the problem here, the primary issues is with associating the data in the first place.  Once data has been associated with a particular node we should be able to keep track of it, right?  

Yes... In fm-branch, the node number is the row name of the data, so it
seems easier to me to keep track of the node/data association.

> > > Also what changes might need to be made to other code, specifically do you think I'll need to update the plotting code to handle the new label system?
> > 
> > I think I have implemented most of the changes that the modification of
> > the labeling structure implied... at the exception of the plotting code.
> > I am not very familiar with this part and I can't really estimate if a
> > lot of changes are necessary. However, most of the changes in my branch
> > are internal. So, if we decide to go with fm-branch, there shouldn't be
> > more change to the plotting code to do.
> 
> I'm planning on making some changes to the plotting code anyway, so I should be able to make any required changes, by the end of the hackathon.

Cool!

  -- François

> Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.r-forge.r-project.org/pipermail/phylobase-devl/attachments/20090818/a38a3e26/attachment.pgp