Re: [basex-talk] Optimization issue? - maps and count
Hi Johannes,
You’ve found a little bug that was introduced more than two years ago
(a wrong static type was attached to the map constructor; we ignored
the fact that a map lookup may yield an empty sequence). A new
snapshot is available [1,2].
Thanks for the report,
Christian
[1] https://github.com/BaseXdb/basex/issues/1766
[2] http://files.basex.org/releases/latest/
On Fri, Dec 6, 2019 at 5:18 PM Johannes Echterhoff
wrote:
>
> All,
>
> The following query:
>
>
>
> let $lookupSequence := ('a','b')
>
> let $map := map {'c': 'x'}
>
> let $mapLookupEvaluation := $map?($lookupSequence)
>
> return
>
> (
>
> 'Evaluation of the map lookup is: ' || string-join($mapLookupEvaluation,", "),
>
> 'count($mapLookupEvaluation) is: ' || count($mapLookupEvaluation)
>
> )
>
>
>
> Results in:
>
> Evaluation of the map lookup is:
>
> count($mapLookupEvaluation) is: 2
>
>
>
> I would have expected 0 instead of 2. Am I missing something?
>
> Best regards,
>
> Johannes
[basex-talk] Optimization issue? - maps and count
All,
The following query:
let $lookupSequence := ('a','b')
let $map := map {'c': 'x'}
let $mapLookupEvaluation := $map?($lookupSequence)
return
(
'Evaluation of the map lookup is: ' || string-join($mapLookupEvaluation,", "),
'count($mapLookupEvaluation) is: ' || count($mapLookupEvaluation)
)
Results in:
Evaluation of the map lookup is:
count($mapLookupEvaluation) is: 2
I would have expected 0 instead of 2. Am I missing something?
Best regards,
Johannes
Re: [basex-talk] Optimization issue?
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
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.gr...@gmail.com]
> Gesendet: Donnerstag, 24. Oktober 2019 12:41
> An: Johannes Echterhoff
> Cc: BaseX
> 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
> 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 := 200.
> >
> > 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.0001)
> >
> > - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->
> > ($num_1 >= 5000.0001)
> >
> > - pre-evaluate unary expression to xs:integer item: -5000
> >
> > - rewrite < comparison to range comparison: ($num_1 < -5000) ->
> > ($num_1 <= -5000.0001)
> >
> > - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->
> > ($num_1 <= -5000.0001)
> >
> > - 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.0001)
> >
> > - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->
> > ($num_1 >= 5000.0001)
> >
> > - pre-evaluate unary expression to xs:integer item: -5000
> >
> > - rewrite < comparison to range comparison: ($num_1 < -5000) ->
> > ($num_1 <= -5000.0001)
> >
> > - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->
> > ($num_1 <= -5000.0001)
> >
> > Optimized Query:
> >
> > let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let
> > $gt5000_2 := ($num_1 >= 5000.0001) let $ltMinus5000_3 :=
> > ($num_1 <= -5000.0001) 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
> >
> >
> >
> >
Re: [basex-talk] Optimization issue?
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.gr...@gmail.com]
Gesendet: Donnerstag, 24. Oktober 2019 12:41
An: Johannes Echterhoff
Cc: BaseX
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
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 := 200.
>
> 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.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->
> ($num_1 >= 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) ->
> ($num_1 <= -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->
> ($num_1 <= -5000.0001)
>
> - 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.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) ->
> ($num_1 >= 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) ->
> ($num_1 <= -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) ->
> ($num_1 <= -5000.0001)
>
> Optimized Query:
>
> let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let
> $gt5000_2 := ($num_1 >= 5000.0001) let $ltMinus5000_3 :=
> ($num_1 <= -5000.0001) 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
>
>
>
>
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
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 := 200.
>
> 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.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
> 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
> -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1
> <= -5000.0001)
>
> - 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.0001)
>
> - rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
> 5000.0001)
>
> - pre-evaluate unary expression to xs:integer item: -5000
>
> - rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
> -5000.0001)
>
> - rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1
> <= -5000.0001)
>
> Optimized Query:
>
> let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let
> $gt5000_2 := ($num_1 >= 5000.0001) let $ltMinus5000_3 := ($num_1 <=
> -5000.0001) 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
>
>
>
>
[basex-talk] Optimization issue?
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 := 200.
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.0001)
- rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
5000.0001)
- pre-evaluate unary expression to xs:integer item: -5000
- rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
-5000.0001)
- rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1 <=
-5000.0001)
- 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.0001)
- rewrite 'gt' comparison to range comparison: ($num_1 gt 5000) -> ($num_1 >=
5000.0001)
- pre-evaluate unary expression to xs:integer item: -5000
- rewrite < comparison to range comparison: ($num_1 < -5000) -> ($num_1 <=
-5000.0001)
- rewrite 'lt' comparison to range comparison: ($num_1 lt -5000) -> ($num_1 <=
-5000.0001)
Optimized Query:
let $t_0 := element x { ("200.") } let $num_1 := number($t_0) let $gt5000_2
:= ($num_1 >= 5000.0001) let $ltMinus5000_3 := ($num_1 <=
-5000.0001) 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
