auto-check for binary tree

[bobthacker]

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]

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]

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]

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]

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]

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]

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.