Hi,
I'm Shuxin. Recently I came across this test case in which BaseX returned an incorrect result. Currently I could not confirm it as a bug and is only a corner case which might not be of importance, but there are some interesting behaviors which I'm also curious about.
Give XML document
<A1 id="1"><B1 id="2"></B1><B1 id="3"></B1></A1>
and XPath query
//A1[((count(./*) idiv 3) * -1763118392 * 2144097893) != 1]
BaseX return empty result set while node A1 should be returned. This should be related to overflow since making either number smaller BaseX will then return correct result and therefore could be considered not a bug. But interestingly, this only occurs when the operand given after idiv (in this case 3) is greater than 2, which result is 0. If changed to (count(./*) idiv 2) or (count(./*) idiv 1), the operand is larger but correct results are still returned. Simply substituting the whole (count(./*) idiv 3) to constant either 0, 1, 2 all returns correct results. This indicates that BaseX should have the ability of handling this expression, but is somehow affected. The version of BaseX I produced this on is the latest development commit e607ecc.
Still, this is just a corner case which might not require a fix. I submit this report just for your reference. Thank you very much!
Best Regards, Shuxin Li 2023.4.5
Hi Shuxin,
Thanks for the new test case. I think you got it right, it looks like a corner case, which is caused by an internal optimization. It can be explained via the following expression, which yields "false" and "true" (while one might expect "false" and "false"):
0 * 3780298429396748056 = 1, 0 = 1 div 3780298429396748056
As 1 div 3780298429396748056 is defined to return the decimal value 0, the result will be changed if the right-hand operand of the multiplication is moved to the right-hand side of the comparison – which is precisely what our optimizer does when compiling your test expression:
//A1[((count(./*) idiv 3) * -1763118392 * 2144097893) != 1]
We decided to do so because it works out fine in all practical use cases we encountered so far.
But thanks anyway for your feedback! Maybe we can refine our processor to suppress optimizations for which we can statically detect that the result would change.
Best regards, and looking forward to your next reports, Christian
basex-talk@mailman.uni-konstanz.de
-
Christian Grün -
Shuxin Li