Closed baldawar closed 1 week ago
Rishi, should we have a close look now or do you want to polish some more first?
hey @timbray this isn't ready yet to review. Still polishing. Didn't realize github sends out a notification even for draft PRs.
No prob. One request: when you think it's stable, it would be useful to include any new language in README.md or wherever that states the constraints on numeric values. Formerly: +/-5B, 6 fractional digits. Or maybe it doesn't change?
Alright this one is ready for some scrutin @timbray .
BTW, Quamina probably won't follow this path, because unfortunately Go doesn't have built-in BigDecimal, and the benefits of having 6 rather than 5 decimal digits is smaller than the cost of accepting an uncontrolled external dependency. Would hope that some future version of Go gets good decimal support because I like the approach in this PR.
In earlier versions of this PR, you had remarked that there was one controversial part, where you fell back to parsing hex versions of numbers in the data. I think that is now gone? I didn't see it.
Left a comment here https://github.com/aws/event-ruler/pull/166/files#r1668969004.
One optimization that Quamina does makes a big difference.
Its there but implemented as a counter https://github.com/aws/event-ruler/blob/ccafd48aee587ec45239ba630c0a679dd837278b/src/main/software/amazon/event/ruler/ByteMachine.java#L115
I didn't realize hex numbers aren't legal JSON. I had only looked at the types of numbers Java supports but missed checking if they are part of JSON spec or not.
Let me remove this bit and associated tests for now.
Issue #, if available: https://github.com/aws/event-ruler/issues/163
Description of changes:
As was reported in issue 163, ruler today ignores precision and causes false matches for numbers or rules with high precision numbers. This change moves away from using
double
for doing arithmetic adjustments withinComparableNumber
.Along the way the API to generate comparable numbers is changed from using
Strings
instead ofDouble
. This allows for more accurate rule matching for numbers with 6+ digits without compromising on performance.A bunch of our tests needed to be changed / fixed as a result of this change. These have been fixed. We're added additional test cases to help catch precision issues in future.
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.