Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auto-check for binary tree #37

Open
bobthacker opened this issue Feb 28, 2015 · 6 comments
Open

auto-check for binary tree #37

bobthacker opened this issue Feb 28, 2015 · 6 comments

Comments

@bobthacker
Copy link

the most common manipulation I need to do to get aRbor to read a tree is to make the tree binary.

Can we add a check when we read trees into any easy mode app:

is.binary.tree(phy) - if it returns FALSE, then do
phy<-multi2di(phy)

check again

is.binary.tree(phy) - if it returns TRUE, continue; if FALSE, need to print an error that Arbor could not generate a binary tree.

@jeffbaumes
Copy link
Member

We could add this to:

  • the conversion to ape tree. We should do this only if we always want binary trees in all of Arbor.
  • inside each analysis that needs it. This seems a quick-and-dirty approach that will not be too labor-intensive to do.
  • as a separate analysis, and have easy mode apps run a small workflow instead of a single step. I like this best.

Any thoughts from others on the path forward here?

@curtislisle
Copy link
Member

I agree with the separate analysis idea outside of tree reading. It does let us start to re-use analyses more than having each easy mode app with its own analysis infrastructure. There will be cases where we want to be able to preserve polytomies (more than 2 children) for some phylogenetic analyses, so this is why I don’t want to force all trees to binary.

I also prefer doing polygamy analysis at the “Upper Arbor” (UI & romanesco) level, instead of adding too much easy-mode specific logic into aRbor.

On Mar 2, 2015, at 9:19 AM, Jeffrey Baumes notifications@github.com wrote:

We could add this to:

the conversion to ape tree. We should do this only if we always want binary trees in all of Arbor.
inside each analysis that needs it. This seems a quick-and-dirty approach that will not be too labor-intensive to do.
as a separate analysis, and have easy mode apps run a small workflow instead of a single step. I like this best.
Any thoughts from others on the path forward here?


Reply to this email directly or view it on GitHub #37 (comment).

@lukejharmon
Copy link
Member

I agree with Curt - make it a little mini-step. And I think there are some advantages to allowing easy-mode to run whole workflows! Maybe it already can.

Curt good luck with your polygamy analyses!
:)

On Mar 2, 2015, at 6:31 AM, Jeffrey Baumes <notifications@github.commailto:notifications@github.com> wrote:

I agree with the separate analysis idea outside of tree reading. It does let us start to re-use analyses more than having each easy mode app with its own analysis infrastructure. There will be cases where we want to be able to preserve polytomies (more than 2 children) for some phylogenetic analyses, so this is why I don’t want to force all trees to binary.

I also prefer doing polygamy analysis at the “Upper Arbor” (UI & romanesco) level, instead of adding too much easy-mode specific logic into aRbor.

On Mar 2, 2015, at 9:19 AM, Jeffrey Baumes <notifications@github.commailto:notifications@github.com> wrote:

We could add this to:

the conversion to ape tree. We should do this only if we always want binary trees in all of Arbor.
inside each analysis that needs it. This seems a quick-and-dirty approach that will not be too labor-intensive to do.
as a separate analysis, and have easy mode apps run a small workflow instead of a single step. I like this best.
Any thoughts from others on the path forward here?


Reply to this email directly or view it on GitHub #37 (comment).


Reply to this email directly or view it on GitHubhttps://github.com//issues/37#issuecomment-76720827.

@bobthacker
Copy link
Author

We don't need for force this for all analyses, but I do think for the
current easy mode analyses, we do need to force binary and
collapse.singletons. Those are the single two biggest errors for all of the
students and Biospherians.

On Mon, Mar 2, 2015 at 10:27 AM, Luke Harmon notifications@github.com
wrote:

I agree with Curt - make it a little mini-step. And I think there are some
advantages to allowing easy-mode to run whole workflows! Maybe it already
can.

Curt good luck with your polygamy analyses!
:)

On Mar 2, 2015, at 6:31 AM, Jeffrey Baumes <notifications@github.com
mailto:notifications@github.com> wrote:

I agree with the separate analysis idea outside of tree reading. It does
let us start to re-use analyses more than having each easy mode app with
its own analysis infrastructure. There will be cases where we want to be
able to preserve polytomies (more than 2 children) for some phylogenetic
analyses, so this is why I don’t want to force all trees to binary.

I also prefer doing polygamy analysis at the “Upper Arbor” (UI &
romanesco) level, instead of adding too much easy-mode specific logic into
aRbor.

On Mar 2, 2015, at 9:19 AM, Jeffrey Baumes <notifications@github.com
mailto:notifications@github.com> wrote:

We could add this to:

the conversion to ape tree. We should do this only if we always want
binary trees in all of Arbor.
inside each analysis that needs it. This seems a quick-and-dirty
approach that will not be too labor-intensive to do.
as a separate analysis, and have easy mode apps run a small workflow
instead of a single step. I like this best.
Any thoughts from others on the path forward here?


Reply to this email directly or view it on GitHub <
https://github.com/arborworkflows/aRbor/issues/37#issuecomment-76718707>.


Reply to this email directly or view it on GitHub<
https://github.com/arborworkflows/aRbor/issues/37#issuecomment-76720827>.


Reply to this email directly or view it on GitHub
#37 (comment).

Robert W. Thacker, PhD
Professor
Department of Biology
University of Alabama at Birmingham
464 Campbell Hall
1300 University Boulevard
Birmingham, AL 35294-1170
voice: 205-934-9685
fax: 205-975-6097
email: thacker@uab.edu
http://www.uab.edu/cas/biology/thacker http://www.uab.edu/biology/thacker
http://www.portol.org

@curtislisle
Copy link
Member

The current easy mode architecture could be easily retargeted to run a two step workflow, which forces the binary tree then runs ancestral states / phylosignal. I vote this is the best thing to do in the short-term. All we do is make a workflow through advanced mode and change the easy mode code to call the workflow instead of directly calling the second step alone.

On Mar 2, 2015, at 11:31 AM, bobthacker notifications@github.com wrote:

We don't need for force this for all analyses, but I do think for the
current easy mode analyses, we do need to force binary and
collapse.singletons. Those are the single two biggest errors for all of the
students and Biospherians.

On Mon, Mar 2, 2015 at 10:27 AM, Luke Harmon notifications@github.com
wrote:

I agree with Curt - make it a little mini-step. And I think there are some
advantages to allowing easy-mode to run whole workflows! Maybe it already
can.

Curt good luck with your polygamy analyses!
:)

On Mar 2, 2015, at 6:31 AM, Jeffrey Baumes <notifications@github.com
mailto:notifications@github.com> wrote:

I agree with the separate analysis idea outside of tree reading. It does
let us start to re-use analyses more than having each easy mode app with
its own analysis infrastructure. There will be cases where we want to be
able to preserve polytomies (more than 2 children) for some phylogenetic
analyses, so this is why I don’t want to force all trees to binary.

I also prefer doing polygamy analysis at the “Upper Arbor” (UI &
romanesco) level, instead of adding too much easy-mode specific logic into
aRbor.

On Mar 2, 2015, at 9:19 AM, Jeffrey Baumes <notifications@github.com
mailto:notifications@github.com> wrote:

We could add this to:

the conversion to ape tree. We should do this only if we always want
binary trees in all of Arbor.
inside each analysis that needs it. This seems a quick-and-dirty
approach that will not be too labor-intensive to do.
as a separate analysis, and have easy mode apps run a small workflow
instead of a single step. I like this best.
Any thoughts from others on the path forward here?


Reply to this email directly or view it on GitHub <
https://github.com/arborworkflows/aRbor/issues/37#issuecomment-76718707>.


Reply to this email directly or view it on GitHub<
https://github.com/arborworkflows/aRbor/issues/37#issuecomment-76720827>.


Reply to this email directly or view it on GitHub
#37 (comment).

Robert W. Thacker, PhD
Professor
Department of Biology
University of Alabama at Birmingham
464 Campbell Hall
1300 University Boulevard
Birmingham, AL 35294-1170
voice: 205-934-9685
fax: 205-975-6097
email: thacker@uab.edu
http://www.uab.edu/cas/biology/thacker http://www.uab.edu/biology/thacker
http://www.portol.org

Reply to this email directly or view it on GitHub.

@jeffbaumes
Copy link
Member

Indeed @curtislisle, easy mode should be able to handle running a workflow. In OO terms, a workflow "is a" analysis and is referenced the same way, so no additional logic is needed in the easy mode apps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants