SCM

[#274] Inconsistent output for node labels

Date:
2008-12-23 21:46
Priority:
3
State:
Closed
Submitted by:
François Michonneau (francois)
Assigned to:
Ben Bolker (bbolker)
Operating System:
None
Severity:
None
Resolution:
None
Component:
None
Version:
None
URL:
Summary:
Inconsistent output for node labels

Detailed description
if you only ask for the node labels for an object with no node labels you get a character vector of length 0 if you only ask for the node labels, but get a vector of 'NA' if you ask for 'allnode'. It seems to me that it's not coherent. Any opinions?

> data(geospiza)
> labels(geospiza, "node")
character(0)
> labels(geospiza, "all")
[1] "fuliginosa" "fortis" "magnirostris" "conirostris" "scandens"
[6] "difficilis" "pallida" "parvulus" "psittacula" "pauper"
[11] "Platyspiza" "fusca" "Pinaroloxias" "olivacea" NA
[16] NA NA NA NA NA
[21] NA NA NA NA NA
[26] NA NA

Comments:

Message  ↓
Date: 2009-08-18 15:35
Sender: Ben Bolker

OK with me.

Date: 2009-08-13 22:20
Sender: Jim Regetz

I agree with François. For trees lacking node labels, I think it would be more consistent to return an explicit NA vector when which="internal" (formerly "node"). This would also be more consistent with how several other functions behave (e.g., the printed representation of a phylo4 object displays <NA>s in the label column; getNode in trunk returns a vector with <NA> names).

In fm-branch, at a glance it looks like returning x@node.label might do the trick? In trunk, a quick fix would be to return rep(NA, nNodes(object)) instead of character(0) in the label method for phylo4; this would also necessitate minor changes to the phylo4->phylo4d method, namely replacing several nodeLabels(x) calls with x@node.label (or adding additional code to drop NA elements). AFAICT this doesn't affect any other code in the trunk. I'm not sure about fm-branch.

I was also going to propose that the vector names (i.e., node ID numbers) need to be implemented and returned consistently, but it looks like that is now done in fm-branch (well, other than the no-node-labels case)? Nice!

Date: 2008-12-27 22:31
Sender: Ben Bolker

I don't see why this is a problem.
If you ask for "all" then you obviously have to
have a placeholder for the node labels, right?

Attached Files:

Changes

Field Old Value Date By
close_date2009-08-18 18:592009-08-18 18:59bbolker
status_idOpen2009-08-18 18:59bbolker
assigned_tonone2009-08-18 15:48bbolker
summaryInconsistant output for node labels2009-08-13 18:16bbolker
Thanks to:
Vienna University of Economics and Business Powered By FusionForge