| Subject: | String id and string index are not the same thing |
According to your documentation, find() returns (among other things) a
string index, and string() takes a string index as its argument, so in
principle I should be able to do this:
use Tree::Suffix;
my $tree = Tree::Suffix->new();
$tree->insert('word0');
$tree->insert('word1');
for my $result ($tree->find('word1')) {
my ($index, $start, $end) = @$result;
print "[", $tree->string($index), "]\n";
}
And in fact I can: it prints
[word1]
However, if I add a line that calls find() in between the two
insert()s, e.g.
$tree->insert('word0');
$tree->find('foo');
$tree->insert('word1');
it no longer works--the script now prints the empty string.
The problem seems to be that you have confused string ids with string
indices. While you claim that the argument of string() is a string
index, in fact the function treats its argument as if it were a string id.
The index is a field in LST_StringHashItem, whereas the id is a field
in LST_String. A new index is generated each time a new string is
entered into the tree; a new id is generated each time a new string is
*created*, which includes not only calls to insert(), but also calls
to find() and perhaps others. This explains why doing a find() before
an insert() can change the behavior.
I seem to have fixed the problem in my own case by modifying find() so
that it returns ids instead of indices, so I can subsequently pass
these values as arguments to string(). I imagine this change would
break some existing scripts, though. See attached patch. I have not
tested it heavily. Note that I had to modify string() as well. My
guess is that at some point you noticed a case in which the index being
passed to string() wasn't equal to the id of the string it was supposed
to retrieve, and you mistakenly thought it was a simple off-by-one error.
Also, the doc for strings() says that it returns a list of ids, but it
actually returns indices.
| Subject: | id_index_patch |
Message body not shown because it is not plain text.