Skip to content

Use Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY #4496

Merged
gianm merged 6 commits intoapache:masterfrom
metamx:double-min-max-value-bugs
Jul 7, 2017
Merged

Use Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY #4496
gianm merged 6 commits intoapache:masterfrom
metamx:double-min-max-value-bugs

Conversation

@leventov
Copy link
Copy Markdown
Member

@leventov leventov commented Jul 1, 2017

Instead of Double.MIN_VALUE and Double.MAX_VALUE, same for Float.

Double.MIN_VALUE is the smallest positive non-zero double value, not "very negative" value.

The effect e. g. is that DoubleMaxAggregator with expression column could never return anything negative (seems so).

Also there is a bug in RTree where maxCoords are filled with Float.MAX_VALUE, and opposite for minCoords.

…Double.MIN_VALUE and Double.MAX_VALUE, same for Float
@leventov leventov added this to the 0.10.1 milestone Jul 1, 2017
@leventov leventov removed the WIP label Jul 1, 2017
Comment thread codestyle/checkstyle.xml
<property name="message" value="Use Comparators.naturalNullsFirst() instead of Ordering.natural().nullsFirst()"/>
</module>

<module name="Regexp">
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these patterns need to be prohibited? I'm not sure.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think yes, because they are 1) never needed in the codebase so far 2) bug-prone, people use them instead of Infinity constants.


mergedPositions[currentIndex] = mm0;
//mergedPositions[nextIndex] = Float.MAX_VALUE; // for debugging
//mergedPositions[nextIndex] = Float.POSITIVE_INFINITY; // for debugging
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks that should be removed.

heapSize = heapDelete(heap, reverseIndex, heapSize, reverseIndex[currentIndex], deltas);

//deltas[currentIndex] = Float.MAX_VALUE; // for debugging
//deltas[currentIndex] = Float.POSITIVE_INFINITY; // for debugging
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks that should be removed.


// mark the merged bin as invalid
// deltas[nextIndex] = Float.MAX_VALUE; // for debugging
// deltas[nextIndex] = Float.POSITIVE_INFINITY; // for debugging
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks that should be removed.

Copy link
Copy Markdown
Contributor

@gianm gianm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but would appreciate more unit tests verifying that the behavior is good now (such as for the doubleMin/doubleMax aggregators). Especially to verify that all the code paths involved do deal well with infinities.

@gianm
Copy link
Copy Markdown
Contributor

gianm commented Jul 6, 2017

@leventov do you have any thoughts on my comment about tests? This is one of the last patches blocking 0.10.1-rc2 so I'm hoping we can resolve it quickly.

@drcrallen
Copy link
Copy Markdown
Contributor

Also the json serde needs to make sure it handles the values for positive and negative infinity as well

@leventov
Copy link
Copy Markdown
Member Author

leventov commented Jul 6, 2017

@gianm I have another patch I want to include into 0.10.1, not published yet

@gianm
Copy link
Copy Markdown
Contributor

gianm commented Jul 7, 2017

Thanks for adding some tests. I would prefer one for doubleMin/doubleMax too but will not consider that blocking to the PR. Please resolve conflicts too and this looks good to me.

@leventov
Copy link
Copy Markdown
Member Author

leventov commented Jul 7, 2017

@gianm doubleMin/doubleMax bug couldn't probably exploited now. It needs to have EvalExpr of null converted from float column, I didn't find a way to do that so that Calcite's type checker doesn't complain.

Comment thread codestyle/checkstyle.xml
<property name="message" value="Use Float.POSITIVE_INFINITY"/>
</module>
<module name="Regexp">
<property name="format" value="Float\.MIN_VALUE"/>
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure how this check style will work. Does this means any usage of Float.MIN_VALUE is prohibited ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes; see #4496 (comment). I guess if anyone needs it for real then the checkstyle rule could be removed or altered.

@gianm gianm merged commit d168a42 into apache:master Jul 7, 2017
gianm pushed a commit to gianm/druid that referenced this pull request Jul 7, 2017
* Use Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY instead of Double.MIN_VALUE and Double.MAX_VALUE, same for Float

* Replace usages in comments

* Fix RTree

* Remove commented code

* Add tests
float[] initMaxCoords = new float[numDims];
Arrays.fill(initMinCoords, -Float.MAX_VALUE);
Arrays.fill(initMaxCoords, Float.MAX_VALUE);
Arrays.fill(initMinCoords, Float.NEGATIVE_INFINITY);
Copy link
Copy Markdown
Contributor

@b-slim b-slim Jul 7, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with the code of Rtree but am not sure if this change really make sense. After this change any operation on the root node coordinate will always return infinity, while before i can have for instance an incremental change over the root coordinate.
Eg, node.getMinCoordinates()[0] [* or /] 100 will return Infinity if we use Float.NEGATIVE_INFINITY as oppose to it will have a defined value if we keep Float.MAX_VALUE

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be ok. I didn't check the full code around RTree in druid, but usually the min/max coordinates of an RTree node represents a minimum range covering all coordinates of the children nodes. It is used for early pruning when traversing the tree. So, I think the min/max coordinates of the root node shouldn't used for any computation.

@b-slim
Copy link
Copy Markdown
Contributor

b-slim commented Jul 7, 2017

@gianm was still looking to review this PR...

if (ratio >= 1) {
// handle very unlikely case that value is > 2^64
return Double.MAX_VALUE;
return Double.POSITIVE_INFINITY;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as comment above why this need to be +infinity and not just Max_value ?

@gianm
Copy link
Copy Markdown
Contributor

gianm commented Jul 7, 2017

@gianm was still looking to review this PR...

Ah, sorry, didn't realize that. I'd say keep reviewing and if you uncover anything that needs to change let's get it in to 0.10.1.

@leventov leventov deleted the double-min-max-value-bugs branch July 7, 2017 17:20
jon-wei pushed a commit that referenced this pull request Jul 7, 2017
)

* Use Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY instead of Double.MIN_VALUE and Double.MAX_VALUE, same for Float

* Replace usages in comments

* Fix RTree

* Remove commented code

* Add tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants