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

[Peter Cowan]

On Apr 20, 2009, at 12:31 PM, Jim Regetz wrote:

> Thanks for the response. A few comments below...
>
> Peter Cowan wrote:
>>
>> On Apr 13, 2009, at 5:14 PM, Jim Regetz wrote:

[snip]

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

Agreed.  I'm less worried about missing cases that are 'cladewise' but  
not identified by ape.  For one reason, we can't know if a tree is in  
a particular order or not without basically reordering it, and it  
would be unwise to assume that unmarked trees in ape are cladewise, as  
it is very possible to change the order and not update the order flag.

Secondly, to the best of my knowledge the order slot really only  
serves to improve performance.  Reordering trees in cpu intensive (and  
the phylobase reorder commands are in R).  It shouldn't cause problems  
to import trees as 'unknown' because the phylobase reorder commands  
are (or should be) insensitive to prior order.

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

Actually the way we export trees is a bad idea.  While, "cladewise" is  
the same as pre order, "pruningwise" isn't exactly postorder.  In  
fact, there is a TODO in the export command to rectify that.   
"Pruningwise" is actually what's called a 'bottom-up' traversal.  I  
considered adding a reorder method for that, but didn't have a use  
case for it aside from compatibility with ape, so I've held off.

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

If I don't hear any objects by the end of the day, I'll go ahead and  
commit option 2.

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

Hmm, that's the mirror I use, and sure enough it appears to have 2.3.   
I must be losing it.

Peter