NumberNode's equal definition is impacted by the underlying representation #1378
Labels
feature-request
A feature should be added or improved.
Comments
|
We do have an equals method but it just compares the exact string representation of numbers. Comparing across numeric types is going to be... fun. |
|
Scala actually has this solved, and different representations of numbers can be compared accurately with a lot less edge cases. In particular, Scala libraries tend that need to support several number representations (such as Json libraries) tend to delegate to the |
mtdowling
added a commit
that referenced
this issue
Aug 25, 2023
Attempts to use the most optimal comparisons of number nodes, using .equals if both number values are of the same type, then the string representation of each value, finally followed by comparing the BigDecimal representation of each value using the string cache. If a BigDecimal is needed, it is cached on the number node for future checks. Closes #1378
mtdowling
added a commit
that referenced
this issue
Aug 25, 2023
Attempts to use the most optimal comparisons of number nodes, using .equals if both number values are of the same type, then the string representation of each value, finally followed by comparing the BigDecimal representation of each value using the string cache. If a BigDecimal is needed, it is cached on the number node for future checks. Closes #1378
mtdowling
added a commit
that referenced
this issue
Aug 25, 2023
Attempts to use the most optimal comparisons of number nodes, using .equals if both number values are of the same type, then the string representation of each value, finally followed by comparing the BigDecimal representation of each value using the string cache. If a BigDecimal is needed, it is cached on the number node for future checks. Closes #1378
alextwoods
pushed a commit
to alextwoods/smithy
that referenced
this issue
Sep 15, 2023
Attempts to use the most optimal comparisons of number nodes, using .equals if both number values are of the same type, then the string representation of each value, finally followed by comparing the BigDecimal representation of each value using the string cache. If a BigDecimal is needed, it is cached on the number node for future checks. Closes smithy-lang#1378
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm not sure whether this qualifies as a bug, as it's directly coming from what I'd qualify as a java gotcha, but the two nodes values defined below are not equal with one another :
Node.from(new java.math.BigDecimal("1.0e+10"))Node.from(1.0e+10)This makes comparing some models hard. It'd be nice to have the
equalsmethod of number nodes protect against this gotcha.The text was updated successfully, but these errors were encountered: