[Phylobase-devl] phylo vs phylo4 'order' attribute conflict

Peter Cowan pdc at berkeley.edu
Mon Apr 20 18:36:40 CEST 2009

On Apr 13, 2009, at 5:14 PM, Jim Regetz wrote:

> Hi all,
> I'd be happy to enter this via the R-forge bug tracker instead, but it
> doesn't look like there is a lot going on there so I'll start out on  
> the
> mailing list.

Jim, either one works well.  Thanks for sending in this report!

> When it exists, the 'order' attribute of a phylo object can be either
> "cladewise" or "pruningwise". This attribute is preserved when  
> coercing
> from phylo to phylo4. However, valid phylo4 objects can only take on  
> the
> order values "unknown", "preorder", or "postorder", as specified in  
> the
> built-in vector phylo4_orderings. Hence the following error:
>> data(bird.families)
>> tr <- reorder(bird.families)
>> as(tr, "phylo4d")
> Error in checkTree(object) :
>   unknown order: allowed values are unknown,preorder,postorder
> I suppose the coercion method should either ignore the phylo order
> attribute if it isn't relevant for phylo4 objects, or deal with it  
> in a
> way that doesn't conflict with the phylobase usage of this attribute.

Agreed.  Currently every time we make a phylo4 or phylo4d object we  
run checkTree() to ensure that it makes sense.  Apparently we were a  
bit over aggressive with the ordering.  On import of ape trees we  
should do one of the following:

1. Set order to unknown
2. Add cladewise and pruningwise as possible orderings for trees even  
though we have no command that take or output a tree in those orderings.

I favor #2.  Any objections?

> On a related note, I believe phylobase::subset always fails with ape
> 2.3, because the newly revised ape::drop.tip (called internally by
> subset) explicitly reorders trees as cladewise, creating an order
> attribute that phylobase currently regards as invalid.
> FYI, I'm using ape 2.3 and the r426 build of phylobase.

ape 2.3 hasn't hit cran for the Mac yet, and my attempts to build from  
SVN failed, due to some missing file.  So I can't confirm this, but  
perhaps it's time for our own tree subsetting function.



> Thanks,
> Jim
> _______________________________________________
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl

More information about the Phylobase-devl mailing list