Make "support" a property of TreeNode

[qiyunzhu]

Please complete the following checklist:

• I have read the guidelines in CONTRIBUTING.md.

• I have documented all public-facing changes in CHANGELOG.md.

• This pull request includes code, documentation, or other content derived from external source(s). If this is the case, ensure the external source's license is compatible with scikit-bio's license. Include the license in the licenses directory and add a comment in the code giving proper attribution. Ensure any other requirements set forth by the license and/or author are satisfied. It is your responsibility to disclose code, documentation, or other content derived from external source(s). If you have questions about whether something can be included in the project or how to give proper attribution, include those questions in your pull request and a reviewer will assist you.

• This pull request does not include code, documentation, or other content derived from external source(s).

Note: REVIEWING.md may also be helpful to see some of the things code reviewers will be verifying when reviewing your pull request.

---

This pull request involves a notable change to the original logic of TreeNode. Please read and think carefully. Following our previous discussions @wasade @RNAer @mortonjt , I changed support from a method to a property. Along with this change,

• The support property has a default value of None. It will not be assigned when a Newick tree is read. This is because branch support values are not part of the Newick standard. They are just denoted as node labels in most practices.
• A new method assign_supports. It traverses a tree and attempts to extract support values from all internal node labels. The logic is similar to assign_ids. Therefore, if the user wants to get support values from a Newick tree, they need to execute tree.assign_supports() once.
• The way a node label is printed is revised. It becomes support:name if both apply, or support or name if either applies. This affects both str and ascii_art. The way a node label is printed is consistant before and after assign_supports. This ensures backward compatibility with previous versions of scikit-bio.

For example, a Newick tree is ((a,b)'75:Ecoli':1.6,(c,d)Mtb:1.4,(e,f)80)root;. In this case, node Ecoli has a support value of 75, the node Mtb has no support value, and the node joining e and f has a support value of 80. After assign_supports is executed, the name of node Ecoli becomes 'Ecoli', and the support property is assigned integer 75. When one prints the manipulated tree, the output is consistent with the original form.

IMPORTANT: Mathematically, "support value" is a property of a branch, not a node. It is usually marked as a node label because of historical and convenience reasons. This practice has caused confusions in many studies and bioinformatics tools, especially in the re-rooting operation, which is necessary in many applications. Please check out this article in 2017:

A Critical Review on the Use of Support Values in Tree Viewers and Bioinformatics Toolkits

The current PR does not address the re-rooting problem. But as we proceed we will have to consider it seriously. I already have a working prototype that can correctly handle re-rooting with support values. It is quite complicated.

So please read and decide whether we should seriously go down this path (making support a property). Then we can take care of rooting.

[qiyunzhu]

Hi @wasade @antgonza @charles-cowart This is the scikit-bio pull request we discussed during Monday's code review. I resolved the conflicts. Could anyone merge it? Thanks!

[antgonza]

One question, will this be confusing? I mean, it could get confusion if what you are seeing is a name or a support, no? For example, if we have this function return nombre; we will not now if nombre is the support or the name; one option is to return nombre: or :nombre to be sure ...

[antgonza]

Just read below that the support is really different than the name and the reason this is not confusing ... leaving comment here just for reference ...

[qiyunzhu]

Thanks for your comment and merging! The support thing is indeed tricky.