>> So my opinion is that this small modulo operator patch is both useful and
>> harmless, so it should be committed.
>
> You've really failed to make that case --- in particular, AFAICS there is
> not even consensus on the exact semantics that the operator should have.
There is. Basically whatever with a positive remainder when the divisor is
positive is fine. The only one to avoid is the dividend signed version,
which happen to be the one of C and SQL, a very unfortunate choice in both
case as soon as you have negative numbers.
> So I'm inclined to reject rather than put in something that may cause
> surprises down the road. The usefulness doesn't seem great enough to
> take that risk.
If you reject it, you can also remove the gaussian and exponential random
distribution which is near useless without a mean to add a minimal
pseudo-random stage, for which "(x * something) % size" is a reasonable
approximation, hence the modulo submission.
> The way forward, if we think there is enough value in it (I'm not
> sure there is), would be to build enough expression infrastructure
> so that we could inexpensively add both operators and functions.
The modulo patch is basically 10 lines of code, I would not call that
"expensive"...
As I explained earlier, it would NOT be any different with an "expression
infrastructure", as you would have to add a lex for the operator, then a
yacc rule for the construction, the operator would need to be represented
in a data structure, and the executor should be able to handle the case
including errors... there is no way that this would be less that 10 lines
of code. It would basically include the very same lines for the executor
part.
> Then we could add a modulo operator with whatever semantics seem
> most popular, and some function(s) for the other semantics, and
> there would not be so much riding on choosing the "right" semantics.
The semantics is clear. I just choose the wrong one in the first patch:-)
--
Fabien.
