I'e been tring to develop a workable implementation of nested interval tree
encoding using continued fractions:
http://arxiv.org/ftp/cs/papers/0402/0402051.pdf

However, I'm running into a snag when I try to decode the materialzed path
of certain nodes using the Euclidean algorithm. The first child node of any
parent does not decode properly; for instance: 3.12.5.21.1 which is
correctly encoded as the continued fraction of 4173/1354 is decoded as
3.12.5.22:

4173 = 1354 * 3 + 111
1354 = 111 * 12 + 22
111 = 22 * 5 + 1
22 = 1 * 22 + 0

Other nodes like 3.12.5.21, 3.12.5.22, and 3.12.5.21.2 are correctly
decoded; so this looking like a special case involving the first child node.

Is there any way to detect and handle this without looking-up the parent
node? Would using reversed continued fractions avoid this?

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric

One possible answer, which is inelegant, but wroks is to re-compute the node
as the materialzed path is extracted and perform a check at the end and
adjust the 'tail' of the path as needed.

I'm hoping for something less brute-force...

-Eric