[
https://issues.apache.org/jira/browse/CALCITE-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726339#comment-17726339
]
Ian Bertolacci edited comment on CALCITE-5722 at 5/25/23 6:20 PM:
------------------------------------------------------------------
I've also noticed that this affects some other pieces of RangeSets, such as
[RangeSets.forEach|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#L252]
and
[RangeSets.map|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#L186].
Should these be changed as well?
The main issue with these is that they choose a value to pass out to the
handler (the "lower" bound in both cases), which would effectively hide the
other bound from the handler.
Lets say I was doing a forEach over {{{}`RangeSet[BigDecimal]`{}}}, and I
wanted to collect all the scales (which is specifically the issue with `equals`
vs `compareTo` for BigDecimals), then I would never receive the "upper"
BigDecimal's scale. So if my range set was something like {{`[ 1.0, 2.0, [3.0,
3.00000] ]`}} I would observe the maximum scale as 1, instead of 5.
was (Author: ian.bertolacci):
I've also noticed that this affects some other pieces of RangeSets, such as
[RangeSets.forEach|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#L252]
and
[RangeSets.map|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#L186].
Should these be changed as well?
The main issue with these is that they choose a value to pass out to the
handler (the "lower" bound in both cases), which would effectively hide the
other bound from the handler.
Lets say I was doing a forEach over BigDecimals, and I wanted to collect all
the scales (which is specifically the issue with `equals` vs `compareTo` for
BigDecimals), then I would never receive the "upper" BigDecimal's scale. So if
my range set was something like {{`[ 1.0, 2.0, [3.0, 3.00000] ]`}} I would
observe the maximum scale as 1, instead of 5.
> Sarg.isComplementedPoints fails with anti-points which are equal under
> `compareTo` but not `equals`
> ---------------------------------------------------------------------------------------------------
>
> Key: CALCITE-5722
> URL: https://issues.apache.org/jira/browse/CALCITE-5722
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.34.0
> Reporter: Ian Bertolacci
> Assignee: Ian Bertolacci
> Priority: Minor
>
> Example:
> {code:java}
> final Sarg<BigDecimal> badComplimentPointsSarg =
> Sarg.of(
> RexUnknownAs.UNKNOWN,
> TreeRangeSet.create(
> Arrays.asList(
> // Create anti-point around 1, with different scales
> Range.lessThan(new BigDecimal("1")),
> Range.greaterThan(new BigDecimal("1.00000000000"))
> )
> )
> );
> assertThat(badComplimentPointsSarg.isComplementedPoints(), is(true));
> {code}
> will fail.
> This is because [RangeSets.isPoints uses direct equality and not
> `Comparable.compareTo`
> equality|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/util/RangeSets.java#LL132C1-L133C1]
> The values {{`1`}} and {{`1.00000000000`}} are not equal under
> `BigDecimal.equals` but are equal under `BigDecimal.compareTo`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
