[Phylobase-devl] Testing framework

[François Michonneau]

  I just committed a change that should take care of problem 1.

  Apparently, I wasn't thinking clearly when I coded the new version of
getNode! I'll fix it tomorrow...

  Cheers,
  -- François


On Thu, 2009-08-13 at 14:42 -0700, Jim Regetz wrote:
> Hi François et al,
> 
> I just ran my RUnit tests against the fm-branch build. Happily, most 
> passed. Here is a summary of the failures:
> 
> 1. Several involved phylo -> phylo4(d) coercion. Mostly these reflects 
> fm-branch improvements (e.g., now handling numeric node labels in ape 
> phylo objects), and it will be easy enough to update the tests after the 
> merge. But something is definitely broken when using the argument that 
> allows node labels to be converted to data upon coercion to phylo4d. 
> Quick example:
> 
> tr <- read.tree(text="(spA:0.2,(spB:0.1,spC:0.1)2:0.1)1:0.07;")
> 
> # this fails in fm-branch, but works in trunk
> phylo4d(tr, check.node.labels="asdata")
> ## Error in switch(which, tip = { :
> ##   You are trying to match node data to tip nodes. Make sure that your 
> ## data identifiers are correct.
> 
> Assuming we want to retain this behavior, we'll have to fix something here.
> 
> 2. In fm-branch, coercion of phylo4d to data.frame produces an 
> "ancestor" column instead of "ancestr", which seems like a good change 
> to me! Just a simple matter of updating the test to reflect this change 
> after the merge.
> 
> 3,4. Two sets of test failures were both caused by a change to getNode 
> in the case where the node argument is an integer (node ID). In trunk, 
> the function *always* returns a vector of the numeric IDs, with the 
> labels as element names. Of course, an element and/or its name may be NA 
> depending on whether the requested node exists in the tree and has a 
> label. In fm-branch, the returned element name is sometimes the label, 
> and other times the ID (even differing within the same returned vector). 
> This strikes me as a programming landmine, and I strongly favor the 
> trunk behavior. As an example, notice how seemingly contradictory 
> results are possible in the (perfectly valid) case where node labels are 
> themselves number-like:
> 
> data(geospiza)
> nodeLabels(geospiza) <- as.character(101:113)
> 
> # in fm-branch
> getNode(geospiza, c(1, 15, 101), missing="OK")
> ## fuliginosa        101        101
> ##          1         15         NA
> 
> # in trunk
> getNode(geospiza, c(1, 15, 101), missing="OK")
> ## fuliginosa        101       <NA>
> ##          1         15         NA
> 
> I admit the <NA> name isn't pretty, but IMHO it gives less room for 
> misinterpretation and surprising downstream behavior.
> 
> Thanks,
> Jim
> 
> 
> François Michonneau wrote:
> > Hi -
> > 
> >   I have started a page where we can lists the tests that are needed:
> > http://123.writeboard.com/2bb68a414b3d8424b
> > 
> > password: Phyl0base
> > 
> >   Cheers,
> >   -- François
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.r-forge.r-project.org/pipermail/phylobase-devl/attachments/20090813/6aaa98e3/attachment-0001.pgp