Can't read newick trees with bootstrap values

[phlaster]

Say I fetched the bac120 tree from GTDB, which has bootstrap values attached:

$ head -c 300 bac120_r220.tree 
((((((GB_GCA_018399855.1:0.231365194,((GB_GCA_029548025.1:0.017591564,GB_GCA_002328585.1:0.014591482)100.0:0.094102735,(GB_GCA_026414805.1:0.049504513,(GB_GCA_937920495.1:0.040077782,(GB_GCA_029907515.1:0.014559045,GB_GCA_020721905.1:0.038630067)100.0:0.015858596)100.0:0.01939392)100.0:0.030186971)'

Now Phylo chokes with it:

[richardreeve]

@phlaster - this seems to be the same issue as #74. Does that look right? There is a potential hack proposed to get around it, but we really need a new parser to read this format that I hadn't come across when I wrote Phylo. I take it you use trees with this format a lot?

[phlaster]

@phlaster - this seems to be the same issue as #74. Does that look right?

Yes, I've made a little research and as far as I can tell, this problem arises, when the tree labels the inner nodes not with some names, but with their support (bootstrap) values. Like degree of confidence, that this branch is is a real thing, and if it is high you shouldn't just attach its children directly to the parent node above.

There is a potential hack proposed to get around it

If you mean this function, it replaces all those support values with random node names, which removes useful information.

I take it you use trees with this format a lot?

As far as I can tell from my small experience, this is quite common in phylogenetics to omit inner node names and sometimes put numeric support values there (either floating point (0,1] or integer [1,100]). And yes, I literally couldn't operate on GTDB tree file without removing all support values. I also use IQ-TREE, for example, which builds phylogeny and writes bootstrap values as inner node labels:

Say there is a tree with no inner labels:

((A,B),(C,D))Root;

we can label the nodes (your parser accepts it):

((A,B)X,(C,D)Y)Root;

if we need to attach support values instead we should be able to write:

((A,B)95,(C,D)95)Root;

which is your current parser disallows (due to value duplications). I found out, square brackets can be used to insert comments inside tree, but it is not universally accepted. But there is a format extension New Hampshire X format which allows to attach arbitrary information to nodes:

((A,B)X[&&NHX:S=95],(C,D)Y[&&NHX:S=95])Root;

sorry for too much handwaving