What is it that you hate about the PhyloCode?

Mention of the PhyloCode can incite some pretty strong emotions among biologists. Some are supportive, but there's a lot of vitriol out there. Consider, for example the title of Carpenter's (2003) paper: A critique of pure folly. Yes, a paper with that title actually got published in a scientific journal. Why the hate?

The thing is, it's sometimes hard to pin people down on exactly why they dislike it. Part of the problem is that the PhyloCode is surrounded by misconceptions. Much of what's been written about it is shockingly ignorant, considering that the code is freely available online and not horribly long (certainly shorter than any of the other codes). Consider Benton (2000), who seems to have not even read the then-current draft and proceeded to write an entire review based on what he imagined the PhyloCode to be like.

This is not to say that all critiques are uninformed. But of those that are, I find that they fall into two camps. They either raise points that have since been addressed in later drafts, or they are simple matters of taste.

As an example of addressed issues, the critiques of how the PhyloCode was going to handle species are now defunct, since it won't cover species. I myself raised dozens of smaller issues to the authors of the code, who then either emended the draft of the code or convinced me that no change was needed.

And as an example of difference of opinion, some people don't see the utility of the "crown clade convention" adopted by recent drafts. Some people just don't like phylogenetic nomenclature, period. The rank-based systems (which, incidentally, should not be called Linnaean systems, per de Queiroz [2005]) do well enough for many people's purposes, and they don't see a reason to change. Of those who like phylogenetic nomenclature, some don't see the advantages of a centralized approach, and would rather let it grow freely (e.g., Sereno [pers. comm.]).

That's all fine; it's good for people to point out flaws if they are later addressed, and it's understandable that not all people would agree on matters of opinion. But I see so much misinformation out there that I think it has to be the source of much of the dislike out there. One popular article is titled What if we decided to rename every living thing on Earth?, when the PhyloCode has always advocated using existing names when possible. Pickett's (2005) report on the first ISPN meeting is titled The new and improved PhyloCode, now with types, ranks, and even polyphyly, when the PhyloCode has never had types (only specifiers, which are similar but operationally different), has always allowed ranks, and has never allowed polyphyly.

So let me put a question out there: If you dislike the PhyloCode, what is it about it that you dislike? And are you sure it's something actually in the code?

Sets for ActionScript

It's been a busy couple of months!

One of the things keeping me busy is, of course, Names on Nodes, the web application I am developing that will automate phylogenetic nomenclature. As part of that project, I have developed a mathematics package that I would eventually like to release as its own package. One class, however, is so useful that I have decided to jump the gun and offer it on its own.

We (ActionScript programmers) all know how useful the Array class is. It can be used to store a sequence of anything, so it can be repurposed as a list, a vector, an edge—all manner of collections.

Well, not all manner of collections. Just ordered collections that allow duplicate elements. What if you want a set: an unordered collection with no duplicates? I find I need sets all the time, but I have to use arrays. And arrays are not optimal for looking up an element's membership, or preventing duplication. As lists they're great, but as sets they suck.

For a while I used a class I'd made called ArraySet that wrapped an array, but this was only an improvement in API, not in performance. Then I took a cue from Java and created: HashSet.

Download HashSet.as

The HashSet class wraps a Dictionary object, which it uses as a hash table. If an element belongs to the set, then that element is a self-referential key in the dictionary. If it doesn't, then there is no such key in the dictionary. And HashSet extends Proxy, so you can use bracket notation for many operations,. You can also use for..in and for each..in loops.

Here's a quick example:

// Create and populate the set.
var s:HashSet = HashSet.fromObject([1, 2, 3]);

trace(s.size); // 3
trace(s[1]); // 1
trace(s[2]); // 2
trace(s[0]); // undefined
trace(s.has(1)) // true

// Trace all elements of the set.
for each (var i:int in s)
{
   trace(i);
}
// Trace all elements of the set (different method).
for (var x:* in s)
{
   trace(x);
}

trace(s); // {1, 2, 3}
s.add(1);
trace(s); // {1, 2, 3}
s.add(4);
trace(s); // {1, 2, 3, 4}
s.remove(1);
trace(s); // {2, 3, 4}
delete s[2];
trace(s); // {3, 4}
s[3] = undefined;
trace(s); // {4}

...and so on. Full documentation is in the class itself, so you can figure out the details for yourself. I will mention that HashSet also has a number of functions in common with Array (every, filter, forEach, map, some) and others that are unique to sets (get empty, diff, intersect, prSubsetOf, subsetOf, union). It also has a few functions that Array really ought to have (clone, equals, remove).

Download it and try it! The full version is integrated into the mathematics package that I'm still tweaking, but this is too useful to keep to myself any longer. At least, I think so—let me know what you think.