Add "daylight" layout method for unrooted trees. #124
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi Guang Chuang Yu and ggtree devs,
I started learning R a few months back (I have programmed in a bunch of other languages though) and this will be my first github commit. So any tips, tricks or suggestions on how to contribute will be very welcome.
The aim of this commit is to provide alternative layout methods for unrooted trees. I've added the "daylight" algorithm described in Inferring Phylogenies by Joseph Felsenstein, but his description is not very detailed and open to interpretation.
I looked at the Phylip program implementation of the daylight algorithm (in drawtree.c), but I could not understand it as it was not documented.
Hence, I started from scratch...
I've added an option to ggtree() layout.method so the same layout type (eg. unrooted) can have different layout methods used (e.g. equal-angle, daylight, n-body, etc).
As I'm not experienced in R, I'm not sure of the best conventions, but followed GCY's style.
I had to refactor the
layout.unrooted()
function so different layout methods can be added and called. Is there a better way to do this?The daylight algorithm is my own implementation so I'm sure there is room for optimization.
Suggestion: It would be really helpful for a "developers guide" on how to contribute to this project. It could include an overview of architecture, conventions, dos/don't. This would save contributors from making common mistakes or taking time to reverse engineer the program to figure out how to do stuff.
Anyway, I hope this helps.