Bug/500 constant filters #501
Conversation
| @@ -125,7 +125,8 @@ impl GeneratorFilter { | |||
| } | |||
| } | |||
|
|
|||
| unreachable!("Filter must only use markers from the table.") | |||
| // Compute constant columns in the first column | |||
| table[0] | |||
There was a problem hiding this comment.
From my high level understanding: Would it not be more intuitive to make this function return an Option?
Because in an example where the filter is only using constants, the column marker should really be none, no? (I could be wrong here, since I'm not totally sure what the OperationColumnMarker is.)
There was a problem hiding this comment.
I guess the way the function is named, it makes sense. I changed it accordingly and set the default value after the call.
|
Does anybody know a fix for the python binding? The suggestion |
Maybe that part of the parser could be rewritten to produce a smaller closure, but for now, I'd just go with increasing the limit. This is only coming up now because the check for this in |
aannleax
force-pushed
the
bug/500-constant-filters
branch
from
aa6804d
to
5f10954
Compare
I had code that computed the column on which a filter is going to be applied on. This depended upon the input variables, e.g. when computing
a(x, y, z), 2 * x > z, the less-than filter should be applied on columnzas the value forxhas to be bound when computing the filter. The code that finds the last occurrence of a variable panicked if the filter did not contain any variable.To fix this I simply assign constant filters to the first column.
Fixes #500.