hendrikmuhs commented on a change in pull request #460:
URL: https://github.com/apache/lucene/pull/460#discussion_r761990896
##########
File path: lucene/core/src/java/org/apache/lucene/util/fst/FST.java
##########
@@ -720,9 +745,9 @@ long addNode(FSTCompiler<T> fstCompiler,
FSTCompiler.UnCompiledNode<T> nodeIn)
}
if (targetHasArcs && (flags & BIT_TARGET_NEXT) == 0) {
- assert target.node > 0;
+ assert targetNode > 0;
Review comment:
> also - if we were able to encode negative offsets we could always
apply this variable encoding
A negative offset would mean you target a node that has not been written
yet. That's not possible by design. In addition it is not necessary, the way
the fst is constructed is from the leafs to the root. A parent always has a
higher offset than its child. Therefore negative offsets never happen.
Absolute vs. relative coding: I wasn't able to use relative addresses all
times, if "fixed length arcs" are used I switch this optimization off
completely. To always use relative coding I must replace all absolute
addresses. I am not sure this is even possible.
When 1st experimenting with this technique years ago, I did some
measurements and calculations. In smaller fst's absolute coding is sufficient,
we have small addresses anyway. The larger the fst gets the more interesting
relative coding becomes. If the fst is highly compressible the absolute address
was often smaller than the relative ones. E.g. leafs usually compress like
that. For larger fst's and fst's that do not compress well (because of values)
relative coding works nicely, because the construction yields good locality.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
