Skip to content

Conversation

totakura
Copy link

Current call to epsilon is made with the assumption that the dynamic type content_type is compatible with double. This does not hold true for numeric types that are bigger than double, e.g: absl::uint128. This CL fixes it by binding the call to content_type's type.

This fixes #1430.

Current call to epsilon is made with the assumption that the dynamic type `content_type` is compatible with double. This does not hold true for numeric types that are bigger than double, e.g: `absl::uint128`. This CL fixes it by binding the call to `content_type`'s type.
@totakura totakura marked this pull request as ready for review September 15, 2025 12:14
Copy link
Collaborator

@barendgehrels barendgehrels left a comment

Choose a reason for hiding this comment

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

Thanks, looks OK to me
(and now I see there were 2 PR's so that's why the other is closed)

@totakura
Copy link
Author

Made a mistake with the author email used to commit in the other PR. The current PR uses the correct email with my employer domain.

Copy link
Collaborator

@tinko92 tinko92 left a comment

Choose a reason for hiding this comment

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

This looks good to me. epsilon for some custom integer type will be zero, so same behaviour as comparing to ~1e-16. It requires any content_type to have a numeric_limits specialisation but the header already requires that anyway.

This comparison to an unscaled epsilon looks dubious in general, but that's unrelated to the PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Compiler error when using absl::uint28 as content_type for RTrees
3 participants