[Biojava-l] Rooted trees in nexus files

[Richard Holland]

> 1. Lack of knowledge of root node

The Newick tree string is read as-is and is not parsed. It only gets  
parsed at the point of conversion to a Undirected or WeightedGraph  
inside the TreeBlocks.java source code (inside the two types of get-As- 
JGraphT methods). It's at this point the string is parsed and it's  
here that root note determination should take place. It's already  
known whether &R or &U have been specified here, which should help the  
code work out what to do.

> 2. The p* stuff.

Exactly the same part of the code as described above. Wherever it  
pushes values to the stack but prepends them with 'p' first, you'll  
need to change the 'p' to some instance variable and provide a getter/ 
setter to change it, with 'p' being the default setting.

cheers,
Richard

>
> Tiago
> 2009/11/3 Richard Holland <holland at eaglegenomics.com>:
>> Agreed that there is a bug. Now all we need is someone to go in and  
>> fix it!
>> :)
>>
>> cheers,
>> Richard
>>
>> On 3 Nov 2009, at 18:16, Tiago Antão wrote:
>>
>>> 2009/11/3 Thasso Griebel <thasso.griebel at uni-jena.de>:
>>>>
>>>> There is a way to uniquely  get a root from a newick string.  
>>>> Usually a
>>>> rooted newick is surrounded with brackets, which indicates the  
>>>> root as
>>>> the
>>>> highest node in the tree. For example:
>>>>
>>>> (A, (B,C))
>>>>
>>>
>>> Agree, it is quite easy to get the root of the tree from the newick
>>> representation. But it should be done on parsing and returned in  
>>> some
>>> way by the parsing system. If the user has to do it again, it means
>>> that the user has to parse it again just to know the root node.
>>>
>>>> I would also suggest to generally parse trees as rooted trees  
>>>> (maybe jsut
>>>> for th initial internal model). Creating an unrooted tree from a  
>>>> rooted
>>>>  one
>>>> is easy, remove the root and forget about directions. The other  
>>>> way might
>>>> be
>>>> hard and ambiguous.
>>>
>>> 100% agree.
>>> The newick _representation_ always has a root by virtue of the way  
>>> it
>>> is done. If that root has meaning or not depends. Doing as you  
>>> suggest
>>> seems the most reasonable idea.
>>> I would add that even if it is an unrooted tree, the topology  
>>> might be
>>> of interest. In my case I am doing a comparative visualizer and it
>>> might be nice for the user to be able to visualize the topology as
>>> specified. It has no biological meaning, but in practice, for many
>>> users, it helps.
>>> I note that PhyloXML (even by virtue of being a XML format) always
>>> represents the phylogenies as trees (not weigthed DAGs). There an
>>> attribute rooted which can be true or false.
>>>
>>> But, anyway. Even assuming a very conservative view on this, the
>>> current parser, for rooted trees, does not allow to determine  
>>> where is
>>> the root. I think that there would be a consensus that that is a  
>>> bug?
>>>
>>> Tiago
>>
>> --
>> Richard Holland, BSc MBCS
>> Operations and Delivery Director, Eagle Genomics Ltd
>> T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
>> http://www.eaglegenomics.com/
>>
>>
>
>
>
> -- 
> "The hottest places in hell are reserved for those who, in times of
> moral crisis, maintain a neutrality." - Dante

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
http://www.eaglegenomics.com/