Thanks, yeah I thought so too. Merged
On Wed, Oct 26, 2022 at 10:31 AM Robert Muir wrote:
>
> I think deferring the advance call like this is fine and harmless,
> only because this DoubleValues "caches" the result for the current
> doc, so its idempotent anyway.
>
> Yes, about "advancing all the
I think deferring the advance call like this is fine and harmless,
only because this DoubleValues "caches" the result for the current
doc, so its idempotent anyway.
Yes, about "advancing all the operands" as I mentioned, expressions
has no clue about this. If you wanted to change it, you'd have to
see https://github.com/apache/lucene/pull/11878 ... it doesn't do what
I initially asked for (still advances all of the operands), but it
delays until doubleValue() is called, which is safe and could have
some impact
On Wed, Oct 26, 2022 at 9:58 AM Michael Sokolov wrote:
>
> Hi, yes, makes sense
Hi, yes, makes sense Mikhail, that will address most of the problem.
But I also think, given the way Expressions work (they always return
true from advanceExact) there is no reason for them to advance their
operands. This shifts the burden/concern from the developer who no
longer has to think as ha
Hello, Michael.
I suppose you can bind f2 to custom lazy implementation of DoubleValuesSource,
which defer advanceExact() by storing doc num and returning true always,
and actually advancing on doubleValue() only.
On Tue, Oct 25, 2022 at 8:13 PM Michael Sokolov wrote:
> ExpressionFunctionValueSo
