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

[Jim Regetz]

Thanks for the response. A few comments below...

Peter Cowan wrote:
> 
> 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?

I do think #1 seems a shame because it discards something that *is* 
known about the order. That said, a potential downside of #2 is that 
some cladewise trees would be imported as 'unknown' and others as 
'cladewise', depending only on the superficial difference of whether the 
(phylo) order attribute had been set.

Perhaps this gets into thorny territory, but any reason not to have this 
phylo import code do more or less the reverse of what the export code 
currently does? I acknowledge I am ignorant of any bigger picture 
ordering issues you all may have grappled with previously.

Either way, my vote (if I actually had one :) would be for a quick fix 
that has minimal side effects elsewhere and leaves open the possibility 
for more elegant handling of tree ordering later.

>> 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.

Perhaps a mirror problem? I actually use the Berkeley CRAN mirror, and 
have successfully installed ape 2.3 on OS X (both using R 2.8.1 and now 
R 2.9.0).

And yes, I recall the missing file problem building ape from SVN. But 
IIRC, what's missing are the sample tree files "bird.families.tre" and 
"bird.orders.tre", which I just manually copied into my working copy of 
ape/dev/ape/data/ from the ape source available on CRAN.

Jim

> Thanks,
> 
> Peter
> 
>> Thanks,
>> Jim