Two small feature requests

[maxtaco]

Hi, Thanks for this package. I have two small feature requests:

1. A procedural-style in-order traversal: zoom to the minimum element of the tree, and then call next() iteratively to traverse the tree in-order. You can stop whenever you'd like (which isn't the case for the existing forEach). Also, unlike the existing forEach, the implementation is iterative and not recursive.
2. Delete an node by its object representation, and not its value. This is especially useful if you have multiple objects with the same key. A very small refactor is required for this --- to split delete into two small functions, and also the return newNode from insert.

Test code included for these newfeatures. Thanks.

[maxtaco]

Ah shoot, I forgot that pushes to my branch still show up in yours. I definitely didn't mean for that last commit (the change to package.json) to get to your repo. Sorry about that.

[scttnlsn]

Awesome...love the .next() style iteration! I'm a little confused why delete_node is necessary though. How/why would you have multiple objects with the same key?

[maxtaco]

For example a list of events keyed by completion time, like how node
implements setTimeout. On the one hand you need to be able to insert new
events arbitrarily into the tree since the user specifies when the event is
inserted and what its completion time will be. On the other hand you need
to be able to iterate from the lowest key upward at every time step as you
handle all of the events that have completed. There could be two events
that complete at the same time.

The example code might look like:

var x = events.minimum();
var y;
while (x && x.key < Date.now()) {
   y = x.next();
   tree.delete_node(x);
   // do something with x.value
   x = y;
}

Thanks!
On Jun 5, 2013 11:19 PM, "Scott Nelson" notifications@github.com wrote:

Awesome...love the .next() style iteration! I'm a little confused why
delete_node is necessary though. How/why would you have multiple objects
with the same key?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1#issuecomment-19022769
.

[scttnlsn]

As is, I don't think duplicate keys are allowed. In the use case above couldn't the values just be an array of events that complete at the same time (specified by the key)?

[maxtaco]

Good point about insert clobbering repeated keys, I didn't see that. There's now an option to the Tree() constructor to enable one mode of operation or the other, with the default behavior as before.

If you want to store duplicate keys as an array of values, is the onus then on the user to make that happen? I.e, every insert then becomes a lookup and then an insert if the lookup fails? Doable, but it does double the number of traversals.

There's also something a little bit unsettling when it comes to depending on strict equality of keys, especially for floats that can show rounding error. For hash tables, I agree, this isn't a concern, but for red-black trees, which are useful for storing values keyed by continuous keys, it's a common case. Why bother worrying about equality if you don't need to?