You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
jquartel opened this issue
Nov 23, 2022
· 2 comments
· Fixed by #5467
Assignees
Labels
grelThe default expression language, GREL, could be improved in many ways!Type: BugIssues related to software defects or unexpected behavior, which require resolution.
If you have an integer-only expression you expect the result to remain integer, but here are a couple of instances where using a negative integer can result in a floating point result (note that the only way I know how to test for the resultant type is to use toString):
If the first (or only) value of the expression is a negative integer, as in toString(-1+2,"%d")
If a variable in a with() or forEach() function is a negative integer, as in with(-1,a,toString(2+a,"%d"))
In both of these cases the result is Error: java.util.IllegalFormatConversionException: d != java.lang.Double
but if you use "%f" in the string conversion you get 1.000000 .
I am using OpenRefine Version 3.6.2 in Safari Version 16.1 on MacOS 12.6.1 .
The text was updated successfully, but these errors were encountered:
jquartel
added
Type: Bug
Issues related to software defects or unexpected behavior, which require resolution.
Status: Pending Review
Indicates that the issue or pull request is awaiting review by project maintainers or collaborators
labels
Nov 23, 2022
tfmorris
added
grel
The default expression language, GREL, could be improved in many ways!
and removed
Status: Pending Review
Indicates that the issue or pull request is awaiting review by project maintainers or collaborators
labels
Nov 23, 2022
Very weird! I can confirm the bug, but it's in code that's worked for over a decade. I strongly suspect a compiler bug, but I've reorganized things to work around the problem.
Actually, this is probably due to the binary numeric promotion which is called out in the JLS, so perhaps it's been broken for a while due to the specification being tightened up, but we didn't have test coverage for this case, so no telling how long it's been broken.
tfmorris
changed the title
Negative integers can incorrectly promote expressions to float
Negative integer literals (w/unary minus sign) are incorrectly interpreted floats
Nov 23, 2022
tfmorris
changed the title
Negative integer literals (w/unary minus sign) are incorrectly interpreted floats
Negative integer literals (w/unary minus sign) incorrectly interpreted as floats
Nov 23, 2022
grelThe default expression language, GREL, could be improved in many ways!Type: BugIssues related to software defects or unexpected behavior, which require resolution.
If you have an integer-only expression you expect the result to remain integer, but here are a couple of instances where using a negative integer can result in a floating point result (note that the only way I know how to test for the resultant type is to use toString):
If the first (or only) value of the expression is a negative integer, as in
toString(-1+2,"%d")
If a variable in a with() or forEach() function is a negative integer, as in
with(-1,a,toString(2+a,"%d"))
In both of these cases the result is
Error: java.util.IllegalFormatConversionException: d != java.lang.Double
but if you use "%f" in the string conversion you get 1.000000 .
I am using OpenRefine Version 3.6.2 in Safari Version 16.1 on MacOS 12.6.1 .
The text was updated successfully, but these errors were encountered: