Rooted trees in nexus files

[Tiago Antão]

Hi,

I have been trying to use biojava to parse some trees on nexus files
and I have a small doubt:
If there is a rooted tree, how can one know what is the root vertex in
the weighted graph (JGraphT)?
I understand that there is no root if the tree is unrooted, but in
case it is rooted, how to determine the vertex?

Many thanks,
Tiago

--
"The hottest places in hell are reserved for those who, in times of
moral crisis, maintain a neutrality." - Dante
_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

The graphs returned by the Nexus parser are instances that implement  
the org.jgrapht.UndirectedGraph interface. Undirected graphs have no  
root.

cheers,
Richard

On 30 Oct 2009, at 21:14, Tiago Antão wrote:

> Hi,
>
> I have been trying to use biojava to parse some trees on nexus files
> and I have a small doubt:
> If there is a rooted tree, how can one know what is the root vertex in
> the weighted graph (JGraphT)?
> I understand that there is no root if the tree is unrooted, but in
> case it is rooted, how to determine the vertex?
>
> Many thanks,
> Tiago
>
> --
> "The hottest places in hell are reserved for those who, in times of
> moral crisis, maintain a neutrality." - Dante
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@...
> http://lists.open-bio.org/mailman/listinfo/biojava-l

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

2009/11/2 Richard Holland <holland@...>:
> The graphs returned by the Nexus parser are instances that implement the
> org.jgrapht.UndirectedGraph interface. Undirected graphs have no root.


Yes, that is a property of the jgrapht. But it might not be the case
of the original nexus file/tree. So, if the tree is rooted, how can
one know the root (without doing the parsing again ourselves to
discover it)? I note two things:
a) The root is obviously not one taxa, but one intermediate node.
b) Even if the tree is unrooted, it might be interesting to know the
"root", for instance to draw the tree, in the way that is was written
in the file.

Tiago
PS - I also added to bugzilla one but related to the parser, but that
is different problem...
_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

The current parser that converts the original Newick tree string into  
a JGraphT does not take the root into account, and therefore it is not  
recorded anywhere in the JGraphT object. Someone would have to change  
the parser to be able to make it record the root node.

In the meantime, the JGraph library which is used for displaying  
JGraphT graphs in a visual form does include root-finding methods, so  
maybe you could investigate there to see if any of the existing  
functions might help?

cheers,
Richard

On 2 Nov 2009, at 19:36, Tiago Antão wrote:

> 2009/11/2 Richard Holland <holland@...>:
>> The graphs returned by the Nexus parser are instances that  
>> implement the
>> org.jgrapht.UndirectedGraph interface. Undirected graphs have no  
>> root.
>
>
> Yes, that is a property of the jgrapht. But it might not be the case
> of the original nexus file/tree. So, if the tree is rooted, how can
> one know the root (without doing the parsing again ourselves to
> discover it)? I note two things:
> a) The root is obviously not one taxa, but one intermediate node.
> b) Even if the tree is unrooted, it might be interesting to know the
> "root", for instance to draw the tree, in the way that is was written
> in the file.
>
> Tiago
> PS - I also added to bugzilla one but related to the parser, but that
> is different problem...

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

2009/11/2 Richard Holland <holland@...>:
> In the meantime, the JGraph library which is used for displaying JGraphT
> graphs in a visual form does include root-finding methods, so maybe you
> could investigate there to see if any of the existing functions might help?

Did that. None can help as the graph is not directed (it would be
trivial with a directed graph ,of course).
In the current form, the nexus parser is of limited use for tree information:
1. For rooted trees it has a bug has it doesn't say what is the root
2. For unrooted trees, sometimes the "root" (what the user perceives
as root) is interesting information.

Tiago
_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

On 2 Nov 2009, at 23:11, Tiago Antão wrote:

> 2009/11/2 Richard Holland <holland@...>:
>> In the meantime, the JGraph library which is used for displaying  
>> JGraphT
>> graphs in a visual form does include root-finding methods, so maybe  
>> you
>> could investigate there to see if any of the existing functions  
>> might help?
>
> Did that. None can help as the graph is not directed (it would be
> trivial with a directed graph ,of course).
> In the current form, the nexus parser is of limited use for tree  
> information:
> 1. For rooted trees it has a bug has it doesn't say what is the root

The Newick strings used in the Nexus format are themselves undirected  
graphs. They don't specify which node is the root, which means it must  
be determined by computation after parsing the string. I'm unsure of  
the algorithm to use to do this. If there are people on this list who  
know the algorithm and have time to code it up, volunteers would be  
welcome.

> 2. For unrooted trees, sometimes the "root" (what the user perceives
> as root) is interesting information.

What the user perceives as root in an unrooted tree could be different  
for every user, so it would be hard to provide a standard function to  
read their mind! However if everyone can come up with a commonly  
agreed way of determining the most likely root computationally, it  
would be interesting to add this as a feature, with the caveat that it  
is only a best-effort approximation as the original tree is unrooted.

cheers,
Richard

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Hilmar Lapp]

The most common ways to root a tree is by mid-point rooting, or using  
an outgroup. The latter I suppose is equivalent as the user specifying  
a node as the root.

        -hilmar

On Nov 3, 2009, at 4:56 AM, Richard Holland wrote:

>
> On 2 Nov 2009, at 23:11, Tiago Antão wrote:
>
>> 2009/11/2 Richard Holland <holland@...>:
>>> In the meantime, the JGraph library which is used for displaying  
>>> JGraphT
>>> graphs in a visual form does include root-finding methods, so  
>>> maybe you
>>> could investigate there to see if any of the existing functions  
>>> might help?
>>
>> Did that. None can help as the graph is not directed (it would be
>> trivial with a directed graph ,of course).
>> In the current form, the nexus parser is of limited use for tree  
>> information:
>> 1. For rooted trees it has a bug has it doesn't say what is the root
>
> The Newick strings used in the Nexus format are themselves  
> undirected graphs. They don't specify which node is the root, which  
> means it must be determined by computation after parsing the string.  
> I'm unsure of the algorithm to use to do this. If there are people  
> on this list who know the algorithm and have time to code it up,  
> volunteers would be welcome.
>
>> 2. For unrooted trees, sometimes the "root" (what the user perceives
>> as root) is interesting information.
>
> What the user perceives as root in an unrooted tree could be  
> different for every user, so it would be hard to provide a standard  
> function to read their mind! However if everyone can come up with a  
> commonly agreed way of determining the most likely root  
> computationally, it would be interesting to add this as a feature,  
> with the caveat that it is only a best-effort approximation as the  
> original tree is unrooted.
>
> cheers,
> Richard
>
> --
> Richard Holland, BSc MBCS
> Operations and Delivery Director, Eagle Genomics Ltd
> T: [phone] ext 3 | E: holland@...
> http://www.eaglegenomics.com/
>
>
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@...
> http://lists.open-bio.org/mailman/listinfo/biojava-l
>

--
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================




_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Thasso Griebel]

Hi,

> On 2 Nov 2009, at 23:11, Tiago Antão wrote:
>
>> 2009/11/2 Richard Holland <holland@...>:
>>> In the meantime, the JGraph library which is used for displaying  
>>> JGraphT
>>> graphs in a visual form does include root-finding methods, so  
>>> maybe you
>>> could investigate there to see if any of the existing functions  
>>> might help?
>>
>> Did that. None can help as the graph is not directed (it would be
>> trivial with a directed graph ,of course).
>> In the current form, the nexus parser is of limited use for tree  
>> information:
>> 1. For rooted trees it has a bug has it doesn't say what is the root
>
> The Newick strings used in the Nexus format are themselves  
> undirected graphs. They don't specify which node is the root, which  
> means it must be determined by computation after parsing the string.  
> I'm unsure of the algorithm to use to do this. If there are people  
> on this list who know the algorithm and have time to code it up,  
> volunteers would be welcome.

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))

describes a tree rooted between "A" and the clade (B,C), and with the  
surrounding brackets this is unique.

In nexus the situation might be a bit different. nexus allows you to  
prefix the newick string with [&R] or [&U] to indicate rooted/unrooted  
trees. For example:

tree treename = [&R] ((A,(B,C)),(D,E));

is a valid rooted nexus tree where the root is placed between the  
clades [A.B,C] and [D,E], although in this example the newick is  
surrounded with brackets and rooted uniquely by itself.

>> 2. For unrooted trees, sometimes the "root" (what the user perceives
>> as root) is interesting information.
>
> What the user perceives as root in an unrooted tree could be  
> different for every user, so it would be hard to provide a standard  
> function to read their mind! However if everyone can come up with a  
> commonly agreed way of determining the most likely root  
> computationally, it would be interesting to add this as a feature,  
> with the caveat that it is only a best-effort approximation as the  
> original tree is unrooted.

BioNJ implements multiple methods to determine a root in a neighbor-
joining tree. I can look it up, but I think the most common ways to  
compute the root are: try to place the root in the "middle" such that  
your tree is balanced and you have equal number of leaves to both  
sides of the tree. The other method I remember is based on the edge  
weights. Basically you find the longest path between two leaves and  
place the root in the middle of that path (based on the path length).
I think the most common way though is to specify an outgroup node and  
place the root on the path between that outgroup and its successor. I  
am not sure if the outgroup can be described in nexus somehow.

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.

cheers,

Thasso

--
Dipl. Inf. Thasso Griebel-------------------Lehrstuhl fuer Bioinformatik
Office 3426--http://bio.informatik.uni-jena.de--Institut fuer Informatik
Phone [phone]-----------Friedrich-Schiller-Universitaet Jena
Fax [phone]----------Ernst-Abbe-Platz 2, 07743 Jena, Germany


--
Dipl. Inf. Thasso Griebel-------------------Lehrstuhl fuer Bioinformatik
Office 3426--http://bio.informatik.uni-jena.de--Institut fuer Informatik
Phone [phone]-----------Friedrich-Schiller-Universitaet Jena
Fax [phone]----------Ernst-Abbe-Platz 2, 07743 Jena, Germany




_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

2009/11/3 Thasso Griebel <thasso.griebel@...>:
> 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

_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

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@...>:
>> 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: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

If somebody would provide the desired changes to the parser interface
(wrt this bug and the other one reported previously), I might offer to
to the grunt work.

But somebody has to say which interface changes are desired.
I remember which problems exist:
1. Lack of knowledge of root node
2. The p* stuff.

Tiago
2009/11/3 Richard Holland <holland@...>:

> 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@...>:
>>>
>>> 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: [phone] ext 3 | E: holland@...
> http://www.eaglegenomics.com/
>
>

--
"The hottest places in hell are reserved for those who, in times of
moral crisis, maintain a neutrality." - Dante

_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

> 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@...>:
>> 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@...>:
>>>>
>>>> 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: [phone] ext 3 | E: holland@...
>> 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: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

But the point is that the class interface changes to the outside user:
1. How does one report back the root to the user?
2. Regarding the prefix stuff, should the user be allowed to specify a
preferred prefix?

Both this things imply interface changes visible to users.
If you still need volunteers to do the change, I can do it. But I need
to know what changes to the user interface are to be done.
For 1, maybe a method getRoot, returning a string with the name of the
root node?
For 2, maybe an extended version of the parse function with a suffix
as input parameter?

2009/11/3 Richard Holland <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@...>:
>>>
>>> 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@...>:
>>>>>
>>>>> 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: [phone] ext 3 | E: holland@...
>>> 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: [phone] ext 3 | E: holland@...
> http://www.eaglegenomics.com/
>
>

--
"The hottest places in hell are reserved for those who, in times of
moral crisis, maintain a neutrality." - Dante

_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Peter Midford-2]

Tiago,
             If you return a directed graph, the root will be a node  
with no incoming edges.

Peter

On Nov 3, 2009, at 13:55, Tiago Antão wrote:

> But the point is that the class interface changes to the outside user:
> 1. How does one report back the root to the user?
> 2. Regarding the prefix stuff, should the user be allowed to specify a
> preferred prefix?
>
> Both this things imply interface changes visible to users.
> If you still need volunteers to do the change, I can do it. But I need
> to know what changes to the user interface are to be done.
> For 1, maybe a method getRoot, returning a string with the name of the
> root node?
> For 2, maybe an extended version of the parse function with a suffix
> as input parameter?
>
> 2009/11/3 Richard Holland <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@...>:
>>>>
>>>> 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@...>:
>>>>>>
>>>>>> 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: [phone] ext 3 | E: holland@...
>>>> 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: [phone] ext 3 | E: holland@...
>> http://www.eaglegenomics.com/
>>
>>
>
>
>
> --
> "The hottest places in hell are reserved for those who, in times of
> moral crisis, maintain a neutrality." - Dante
>
> _______________________________________________
> Biojava-l mailing list  -  Biojava-l@...
> http://lists.open-bio.org/mailman/listinfo/biojava-l

Peter E. Midford
Mesquite Developer
Peter.Midford@...





_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

A getRoot() function sounds good. It would return the String label of  
the root node, the same as which identifies the corresponding vertex  
in the JGraphT model. An equivalent setRoot() would be nice.

The prefix for the parser currently is hardcoded as p. Two new methods  
- set and getDefaultPrefix which accept a string should be provided  
(it should check that the string is valid, i.e. all alphanumeric and  
with no spaces or other Newick-sensitive characters). The parser  
should be changed to use the output from getDefaultPrefix() instead of  
the hardcoded p. The default behaviour should be such that it behaves  
the same as at present unless the user explicitly says otherwise by  
calling the setDefaultPrefix() method.

Personally I would also alter the methods that return JGraphTs so that  
they return their Directed equivalents if possible. I believe that  
these can still be unrooted - you'd have to check the JGraphT  
documentation to make sure.

Richard.

On 3 Nov 2009, at 18:55, Tiago Antão wrote:

> But the point is that the class interface changes to the outside user:
> 1. How does one report back the root to the user?
> 2. Regarding the prefix stuff, should the user be allowed to specify a
> preferred prefix?
>
> Both this things imply interface changes visible to users.
> If you still need volunteers to do the change, I can do it. But I need
> to know what changes to the user interface are to be done.
> For 1, maybe a method getRoot, returning a string with the name of the
> root node?
> For 2, maybe an extended version of the parse function with a suffix
> as input parameter?
>
> 2009/11/3 Richard Holland <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@...>:
>>>>
>>>> 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@...>:
>>>>>>
>>>>>> 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: [phone] ext 3 | E: holland@...
>>>> 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: [phone] ext 3 | E: holland@...
>> 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: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Thasso Griebel]

Hi,

> A getRoot() function sounds good. It would return the String label  
> of the root node, the same as which identifies the corresponding  
> vertex in the JGraphT model. An equivalent setRoot() would be nice.

Though you have to keep in mind that switching the root to another  
node has certain implications on the tree structure and this has to be  
taken into account when the newick string is parsed and the graph is  
created. You have to parse the graph from newick and then "reroot" the  
tree as the root might not be equal to the one specified in the newick  
string.

> Personally I would also alter the methods that return JGraphTs so  
> that they return their Directed equivalents if possible. I believe  
> that these can still be unrooted - you'd have to check the JGraphT  
> documentation to make sure.

You have to change that method signature if you want to use the same  
method. The only relationship between JGraphTs UndirectedGraph and the  
DirectedGraph counterpart is that they both extend the Graph  
interface, but a DirectedGraph is not an UndirectedGraph. Switching to  
DirectedGraph definitely breaks the current API ! I don't know how you  
usually handle such situations in BioJava, but this clearly breaks  
compatibility. Maybe it would be better to introduce a new method that  
returns directed graphs ?

cheers,
-thasso

>
> Richard.
>
> On 3 Nov 2009, at 18:55, Tiago Antão wrote:
>
>> But the point is that the class interface changes to the outside  
>> user:
>> 1. How does one report back the root to the user?
>> 2. Regarding the prefix stuff, should the user be allowed to  
>> specify a
>> preferred prefix?
>>
>> Both this things imply interface changes visible to users.
>> If you still need volunteers to do the change, I can do it. But I  
>> need
>> to know what changes to the user interface are to be done.
>> For 1, maybe a method getRoot, returning a string with the name of  
>> the
>> root node?
>> For 2, maybe an extended version of the parse function with a suffix
>> as input parameter?
>>
>> 2009/11/3 Richard Holland <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@...>:
>>>>>
>>>>> 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@...>:
>>>>>>>
>>>>>>> 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: [phone] ext 3 | E: holland@...
>>>>> 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: [phone] ext 3 | E: holland@...
>>> 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: [phone] ext 3 | E: holland@...
> http://www.eaglegenomics.com/
>

--
Dipl. Inf. Thasso Griebel-------------------Lehrstuhl fuer Bioinformatik
Office 3426--http://bio.informatik.uni-jena.de--Institut fuer Informatik
Phone [phone]-----------Friedrich-Schiller-Universitaet Jena
Fax [phone]----------Ernst-Abbe-Platz 2, 07743 Jena, Germany




_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

2009/11/3 Richard Holland <holland@...>:
> The prefix for the parser currently is hardcoded as p. Two new methods - set
> and getDefaultPrefix which accept a string should be provided (it should
> check that the string is valid, i.e. all alphanumeric and with no spaces or
> other Newick-sensitive characters). The parser should be changed to use the
> output from getDefaultPrefix() instead of the hardcoded p. The default
> behaviour should be such that it behaves the same as at present unless the
> user explicitly says otherwise by calling the setDefaultPrefix() method.

This default behavior would still raise an exception with nodes called
p* . I would suggest a minor change: If there is a clash, the parser
would try the next p* (or whatever defaultPrefix) ...

Example to make it clear: if there is a leaf called p2, internal nodes
generated would be p1, p3, p4, ....

--
"The hottest places in hell are reserved for those who, in times of
moral crisis, maintain a neutrality." - Dante
_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Tiago Antão]

2009/11/4 Thasso Griebel <thasso.griebel@...>:

>> Personally I would also alter the methods that return JGraphTs so that
>> they return their Directed equivalents if possible. I believe that these can
>> still be unrooted - you'd have to check the JGraphT documentation to make
>> sure.
>
> You have to change that method signature if you want to use the same method.
> The only relationship between JGraphTs UndirectedGraph and the DirectedGraph
> counterpart is that they both extend the Graph interface, but a
> DirectedGraph is not an UndirectedGraph. Switching to DirectedGraph
> definitely breaks the current API ! I don't know how you usually handle such
> situations in BioJava, but this clearly breaks compatibility. Maybe it would
> be better to introduce a new method that returns directed graphs ?

I also don't know how BioJava sorts these kinds of issues. But my
personal, outsider, opinion would be in your direction, ie:
a. Not break the current API
b. Add a new method with a directed graph
c. (extra) Add a new method boolean isRooted(void) to check is the
tree is rooted or not...

Best
Tiago
_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

>
> You have to change that method signature if you want to use the same  
> method. The only relationship between JGraphTs UndirectedGraph and  
> the DirectedGraph counterpart is that they both extend the Graph  
> interface, but a DirectedGraph is not an UndirectedGraph. Switching  
> to DirectedGraph definitely breaks the current API ! I don't know  
> how you usually handle such situations in BioJava, but this clearly  
> breaks compatibility. Maybe it would be better to introduce a new  
> method that returns directed graphs ?

Whether or not to break the API depends on a few things. First, how  
old and well adopted is the code. Second, is the existing API  
illogical or just plain wrong. A balance between the two gives the  
confidence in which the API can be changed.

In this instance, the code is fairly new, not widely adopted, and the  
existing API is clearly wrong by forcing all JGraphT graphs to be  
undirected.

To keep everyone happy, I would introduce a new method with a new name  
that takes a boolean or enum option indicating what type of graph the  
user wants (undirected,directed,whatever). I would then deprecate the  
existing method and move its contents into the undirected part of the  
new method, and replace the old method contents with a call to the new  
method with the option set to undirected.

cheers,
Richard

> cheers,
> -thasso
>
>
>
>
>
>
>>
>> Richard.
>>
>> On 3 Nov 2009, at 18:55, Tiago Antão wrote:
>>
>>> But the point is that the class interface changes to the outside  
>>> user:
>>> 1. How does one report back the root to the user?
>>> 2. Regarding the prefix stuff, should the user be allowed to  
>>> specify a
>>> preferred prefix?
>>>
>>> Both this things imply interface changes visible to users.
>>> If you still need volunteers to do the change, I can do it. But I  
>>> need
>>> to know what changes to the user interface are to be done.
>>> For 1, maybe a method getRoot, returning a string with the name of  
>>> the
>>> root node?
>>> For 2, maybe an extended version of the parse function with a suffix
>>> as input parameter?
>>>
>>> 2009/11/3 Richard Holland <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@...>:
>>>>>>
>>>>>> 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@...>:
>>>>>>>>
>>>>>>>> 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: [phone] ext 3 | E: holland@...
>>>>>> 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: [phone] ext 3 | E: holland@...
>>>> 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: [phone] ext 3 | E: holland@...
>> http://www.eaglegenomics.com/
>>
>
> --
> Dipl. Inf. Thasso Griebel-------------------Lehrstuhl fuer  
> Bioinformatik
> Office 3426--http://bio.informatik.uni-jena.de--Institut fuer  
> Informatik
> Phone [phone]-----------Friedrich-Schiller-Universitaet  
> Jena
> Fax [phone]----------Ernst-Abbe-Platz 2, 07743 Jena,  
> Germany
>
>
>

--
Richard Holland, BSc MBCS
Operations and Delivery Director, Eagle Genomics Ltd
T: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l

[Richard Holland-6]

Sounds good.

On 4 Nov 2009, at 12:40, Tiago Antão wrote:

> 2009/11/3 Richard Holland <holland@...>:
>> The prefix for the parser currently is hardcoded as p. Two new  
>> methods - set
>> and getDefaultPrefix which accept a string should be provided (it  
>> should
>> check that the string is valid, i.e. all alphanumeric and with no  
>> spaces or
>> other Newick-sensitive characters). The parser should be changed to  
>> use the
>> output from getDefaultPrefix() instead of the hardcoded p. The  
>> default
>> behaviour should be such that it behaves the same as at present  
>> unless the
>> user explicitly says otherwise by calling the setDefaultPrefix()  
>> method.
>
> This default behavior would still raise an exception with nodes called
> p* . I would suggest a minor change: If there is a clash, the parser
> would try the next p* (or whatever defaultPrefix) ...
>
> Example to make it clear: if there is a leaf called p2, internal nodes
> generated would be p1, p3, p4, ....
>
> --
> "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: [phone] ext 3 | E: holland@...
http://www.eaglegenomics.com/


_______________________________________________
Biojava-l mailing list  -  Biojava-l@...
http://lists.open-bio.org/mailman/listinfo/biojava-l