-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use base64 radix to support 5e11 to -5e11 #171
Conversation
Previous benchmarks from #170 are roughly in the same ballpark. I don't see anything pointing to memory utilization going higher as well, but will run specific benchmarks for them once again.
|
…rdersThemCorrectly
@@ -325,7 +325,7 @@ private void deleteRangePattern(Range range) { | |||
|
|||
// when bottom byte on forkOffset position < top byte in same position, there must be matches existing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You demonstrate courage by wading into this code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its been the best source of learning a whole lot more of neat tricks within ruler.
*/ | ||
class ComparableNumber { | ||
// Use scientific notation to define the double number directly to avoid losing Precision by calculation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice useful comment
Issue #, if available: #42
Description of changes:
This change move from hex to base64 for numbers and subsequently allows to now support 5e11 to -5e11 numberic range. We still use hex for CIDR, and so selectively change to the older hex based digit system when necessary.
In case it matters, 5e11 was picked intentionally as
5e11 * 1e6
is the most we'd be able to support throughLong
primitive. Beyond we trigger integer overflows. As solution, we either have to find a different normalization method, or switch to BigDecimal. I expect BigDecimal math to have a performance hit. I chose to not tackle these in the interest of time.Apologies for any silly errors in the diff. This change was a bit rushed.
Benchmark / Performance (for source code changes):
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.