[Phylobase-devl] stalled ...

[Peter Cowan]

On Jan 14, 2009, at 12:58 PM, Ben Bolker wrote:

>
>  So -- where are we?

At this point, I think we should make all the backwards incompatible  
changes we've been discussing.  Everything else can be deferred as far  
as I'm concerned.

>  From before:
>
>> 1. merge my branch (with the aforementioned controversial
>> ordering)  {Peter, can you help with this if/when we
>> decide to go for it?}
>
>  DONE.
>
>> 2. see what we can do to detect & fix problems with unrooted trees:
>> this includes a lot of Steve's "to do" list (sorting out nodeId,
>> nNode, etc.)
>
>  ???
>>
>> 3. fix problems in node labeling on plots that stem from
>> the change in edge matrix format (Peter may already have a fix
>> for this but was waiting on other changes)
>
>   DONE.
>>
>> 4.  PDC proposes that we change the NA in the root-node-row
>> to (-1) instead; I propose that we add a "dropRoot" function
>> (which just operates on a raw edge matrix, not on a phylo4
>> object) to abstract the operation of dropping the appropriate
>> row (essentially substituting for places where we have na.omit
>> or edge[!is.na(edge[,1]),] in the code now
>
>  NA to -1 switch not made.
>  edges now has a drop.root argument (default = FALSE) that
> should do this.

I'd still rather have -1 than NA, there are cases when have the NA is  
a problem but it's useful to have an nrow(edge) == nNodes().  Is there  
a reason for keeping NA aside from inertia?

>>
>> 5. make the naming-convention changes as recommended
>
>  NOT DONE.  Volunteers?  Francois wanted some plurals to
> be kept ...

I think this should be a priority.  Nothing is worse than having  
commands "disappear" when updating to a new version.  So before we  
release an 'official' version we should pick final names.

>> 6. with some input from Emmanuel, implement SOME form of
>> checking/consistency rule for ordering when importing/exporting
>> from/to ape
>
>   NOT DONE. Volunteers?

I'd be okay with deferring this.  It won't be surprising to users if  
we make this better in the future right?

>>  I propose that we DELAY:
>>
>> 1. updating ncl to the newer version (unless Brian has this
>> all ready to go)
>
>  AGREED.

Also agreed

>>
>> 2. adding metadata/annotation slots, although if we know
>> their GENERAL form it would be nice to add them to phylo4[d]
>> objects now because adding slots later breaks backward compatibility
>> of saved objects (but we may just have to bite the bullet and
>> do it later).  In particular if these were slots of type list()
>> we could be vague about what we were going to put in (at the
>> cost of less-strong typing of the objects)
>
>  Could add as list() if we can agree on names for the slots,
> how many.
>

I'd be okay with deferring this as well.  This is an enhancement that  
won't break older code right?

>  PS: if someone wants to take a look at the "hard way" simulator
> code in section 9 of the vignette and suggest ways that this could
> be done more easily (possibly by adding convenience functions and/or
> accessors that do the hard work), please feel free ...

I can take a look at this, sometime next week probably.  We should  
also decide how we are going to handle newlines for the vignette.  I  
think that I've been soft wrapping and Ben has been hard wrapping,  
which causes havoc with svn.  Do you have a preference Ben?

Cheers

Peter
>

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