Re: Expressions greedy advanceExact implementation

2023-09-15 Thread Greg Miller
Reviving this thread with another thought… I think we can improve on this last solution and lazily advance an expression’s referenced double values without needing to push complexity down into compiled expression. What if we do something like this? https://github.com/apache/lucene/pull/12560

Re: Expressions greedy advanceExact implementation

2022-10-26 Thread Michael Sokolov
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

Re: Expressions greedy advanceExact implementation

2022-10-26 Thread Robert Muir
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

Re: Expressions greedy advanceExact implementation

2022-10-26 Thread Michael Sokolov
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

Re: Expressions greedy advanceExact implementation

2022-10-26 Thread Michael Sokolov
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

Re: Expressions greedy advanceExact implementation

2022-10-26 Thread Mikhail Khludnev
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: >

Re: Expressions greedy advanceExact implementation

2022-10-25 Thread Robert Muir
Iirc the expressions acts like a simple scripting engine where it just compiles bytecode for your expression and you are able to bind variables that you pass to the method... I don't know of an easy way to do this. On Tue, Oct 25, 2022, 1:13 PM Michael Sokolov wrote: >

Expressions greedy advanceExact implementation

2022-10-25 Thread Michael Sokolov
ExpressionFunctionValueSource lazily evaluates in doubleValues: an expression like condition ? f1 : f2 will only evaluate one of f1 or f2. At the same time, the advanceExact() call is greedy -- when you advance that expression it will also advance both f1 and f2. But here's the thing: it