Thanks for the confirmation. BaseX should have been released in October; I think we’ll eventually have to target November.

On Fri, Oct 25, 2019 at 11:23 AM Johannes Echterhoff echterhoff@interactive-instruments.de wrote:

Dear Christian, Tested the snapshot yesterday, and now the expression works as expected. Thank you. Do you have a target date for the release of BaseX 9.3? Best regards, Johannes

-----Ursprüngliche Nachricht----- Von: Christian Grün [mailto:christian.gruen@gmail.com] Gesendet: Donnerstag, 24. Oktober 2019 12:41 An: Johannes Echterhoff echterhoff@interactive-instruments.de Cc: BaseX basex-talk@mailman.uni-konstanz.de Betreff: Re: [basex-talk] Optimization issue?

Dear Johannes,

Thanks for the reproducible test case. The bug (a too eager merge of combined range expressions) was fixed and a new snapshot is available [1,2].

Cheers Christian

[1] https://github.com/BaseXdb/basex/issues/1744 [2] http://files.basex.org/releases/latest/

On Thu, Oct 24, 2019 at 10:54 AM Johannes Echterhoff echterhoff@interactive-instruments.de wrote:

...

Hello,

I’m experiencing some strange behavior when executing the following query in the BaseX 9.2.4 GUI (nevermind the awkward query structure – that is just to be able to inspect the results of the individual evaluation steps):

let $t := <x>200.0000</x>

let $num := number($t)

let $gt5000 := $num gt 5000

let $ltMinus5000 := $num lt -5000

return $gt5000 or $ltMinus5000

The result is true, although it should be false.

The compilation and optimization logs for this query in the GUI tell us the following:

---

Compiling:

• rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1

...

= 5000.000000000001)

• rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->

($num_1 >= 5000.000000000001)

• pre-evaluate unary expression to xs:integer item: -5000

• rewrite < comparison to range comparison: ($num_1 < -5000) ->

($num_1 <= -5000.000000000001)

• rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->

($num_1 <= -5000.000000000001)

• inline $gt5000_2

• inline $ltMinus5000_3

• simplify or: (true())

• pre-evaluate or to xs:boolean item: (true()) -> true()

• remove unused variable $num_1

• remove unused variable $t_0

• simplify FLWOR expression: true()

Optimized Query:

true()

---

When the return statement is changed to “return ($num,$gt5000,$ltMinus5000,$gt5000 or $ltMinus5000)” then the result of the boolean operation (last element of the result sequence) is false, as expected.

The GUI log then is:

---

Compiling:

• rewrite > comparison to range comparison: ($num_1 > 5000) -> ($num_1

...

= 5000.000000000001)

• rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->

($num_1 >= 5000.000000000001)

• pre-evaluate unary expression to xs:integer item: -5000

• rewrite < comparison to range comparison: ($num_1 < -5000) ->

($num_1 <= -5000.000000000001)

• rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->

($num_1 <= -5000.000000000001)

Optimized Query:

let $t_0 := element x { ("200.0000") } let $num_1 := number($t_0) let $gt5000_2 := ($num_1 >= 5000.000000000001) let $ltMinus5000_3 := ($num_1 <= -5000.000000000001) return ($num_1, $gt5000_2, $ltMinus5000_3, ($gt5000_2 or $ltMinus5000_3))

---

Am I missing something, or could this be a bug in BaseX 9.2.4? With BaseX 9.0.2, both queries (with the different return statements) returned the expected value false for the boolean operation.

Best regards,

Johannes