[Phylobase-devl] a graphics challenge ...

[Schliep, Klaus]

About the tree rearrangements! It is mainly just rearranging some of the elements in the edge matrix and than reordering the edge matrix for plotting etc. A recursive tree definition is more elegant for these kind of things, especially for NNI rearrangements.
A problem really is to save all these trees, as they can take a substantial amount of space. Also computations (parsimony/likelihood) often only evaluate the quartets or triplets that changes during the rearrangement and the rest of the tree is ignored (also RaxML evaluates only a subset of all possible SPR moves). It is maybe still useful to have for simulations or as a development tool, as you can try these things faster in R than C++, but maybe not for the mainstream user.
The multiphylo element in ape saves quite a bit of memory by storing the taxa labels only once. One could save even more space if only the additional (different) bipartitons or splits (possibly instead of nodes or edges) of each tree together with their information are stored. This would require some kind of a multiphylo4 object.

Cheers,
Klaus


PS: I have written some C code to reorder trees into "pruningwise" order and it works fine even if the tree was not in "cladewise" order (which caused the ape function to crash R), this should fix some of the ordering problems mentioned, but it is for the ape phylo class. The order the edges can however differ from the ape function in a plot. Some thing like tree <- phangorn:::reorderPruning(tree) should do the trick, if you want to try.








-----Original Message-----
From: phylobase-devl-bounces at lists.r-forge.r-project.org [mailto:phylobase-devl-bounces at lists.r-forge.r-project.org] On Behalf Of Brian O'Meara
Sent: Thursday, 12 March 2009 7:56 a.m.
To: Peter Cowan
Cc: phylobase-devl at r-forge.wu-wien.ac.at; Ben Bolker
Subject: Re: [Phylobase-devl] a graphics challenge ...



On Mar 11, 2009, at 12:30 AM, Peter Cowan wrote:

> As a former student myself, I'd be willing to help mentor this time
> around.

Cool!

>
> What types of projects would move phylobase forward?  A parser for
> one of the xml phylogeny formats?  Metadata support?  Multi-
> phylo4?  Tighter integration with NCL? Rewrites of performance
> sensitive methods in C? A testing framework for the package?

Just FYI, there's a proposal on the NESCent page to add nexml parsing
to NCL. Iff that gets accepted and completed, updating the NCL in
phylobase would automatically bring in xml input.

>
> Other ideas?

There are some ideas on our features page: <http://r-forge.r-
project.org/tracker/?atid=491&group_id=111&func=browse>. I personally
like the idea of incorporating branch swapping algorithms (TBR, NNI)
into phylobase (but are they around somewhere there already? --
didn't see them). This is a basic "tree" function that isn't commonly
available (I had to code my own in C++ a few years ago, though now
there's a library to do it; phangorn can do NNIs in R). It has some
chewy bits (for example, you'd want to know when you've exhausted all
possible TBR swaps for a given topology, but how do you store this
information?; also, what happens to information on nodes/edges, how
do you assign initial branch lengths if relevant, etc). But I don't
think this is a core feature in the same way that communicating with
ape or reading nexus are. There's also the practical issue of utility
-- who's going to use these functions? You're probably not going to
code a tree search algorithm in R.

Another idea, though probably not for phylobase sensu strictu, is to
finish the R-Mesquite bridge started at the hackathon.

Also, just to bubble it up again, Ben's email from Jan. on things to
do before release is below. Anything that can be done coding-wise
(rather than design or documentation) to get the release out would be
helpful & appropriate.

Begin forwarded message:
> From: Ben Bolker <bolker at ufl.edu>
> Date: January 14, 2009 3:58:16 PM EST
> To: phylobase-devl at r-forge.wu-wien.ac.at
> Subject: [Phylobase-devl] stalled ...
>
>
>   So -- where are we?
>
>   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.
>
>>
>> 5. make the naming-convention changes as recommended
>
>   NOT DONE.  Volunteers?  Francois wanted some plurals to
> be kept ...

[some progress has been made on this]

>
>>
>> 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 propose that we DELAY:
>>
>> 1. updating ncl to the newer version (unless Brian has this all ready
>> to go)
>
>   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.
>
>   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 ...



>
> Peter
>
>
>
> On Mar 9, 2009, at 7:35 PM, Hilmar Lapp wrote:
>
>> I'd like to echo Brian's comment. You (phylobase) can have students
>> working over the summer for you; all you need to do is put up a
>> project idea and designate mentor(s).
>>
>> I know that mentoring is also work, but the results can greatly push
>> along a project.
>>
>> Let me know if there's anything I can help with coordinating this.
>>
>>      -hilmar
>>
>> On Mar 9, 2009, at 12:05 PM, Brian O'Meara wrote:
>>
>>> Good link, Ben. Google Summer of Code is starting up again, and
>>> there
>>> are no R projects yet on the NESCent page (<https://www.nescent.org/
>>> wg_phyloinformatics/Phyloinformatics_Summer_of_Code_2009>).
>>> Perhaps a
>>> way to charge the paddles?
>>>
>>> Brian
>>>
>>> On Mar 9, 2009, at 2:07 AM, Ben Bolker wrote:
>>>
>>>>
>>>> http://www.stat.columbia.edu/~cook/movabletype/archives/2009/03/
>>>> more_on_display.html
>>>>
>>>> Someday soon I hope to get out the defibrillator and see if we can
>>>> get phylobase going again ...
>>>>
>>>> cheers
>>>>   Ben
>>>>
>>>> --
>>>> Ben Bolker
>>>> Associate professor, Biology Dep't, Univ. of Florida
>>>> bolker at ufl.edu / www.zoology.ufl.edu/bolker
>>>> GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> ________________________________
>>> Brian O'Meara
>>> NESCent
>>> Durham, NC
>>> http://www.brianomeara.info ________________________________
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> --
>> ===========================================================
>> : Hilmar Lapp  -:-  Durham, NC  -:- hlapp at duke dot edu :
>> ===========================================================
>>
>>
>>
>>
>> _______________________________________________
>> 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
>


________________________________
Brian O'Meara
NESCent
Durham, NC
http://www.brianomeara.info
________________________________



_______________________________________________
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