[
https://issues.apache.org/jira/browse/TINKERPOP-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17956227#comment-17956227
]
ASF GitHub Bot commented on TINKERPOP-3115:
-------------------------------------------
Cole-Greer commented on code in PR #3121:
URL: https://github.com/apache/tinkerpop/pull/3121#discussion_r2127780422
##########
docs/src/upgrade/release-3.8.x.asciidoc:
##########
@@ -30,6 +30,26 @@ complete list of all the modifications that are part of this
release.
=== Upgrading for Users
+==== Auto promotion of number types
+
+Previously, operations like sum or sack that involved mathematical
calculations did not automatically promote the result
+to a larger numeric type (e.g., from int to long) when needed. As a result,
values could wrap around within their current
+type, leading to unexpected behavior. This issue has now been resolved by
enabling automatic type promotion for results.
+
+Now, any mathematical operations such as Add, Sub, Mul, and Div will now
automatically promote to the next numeric type
+if an overflow is detected. For integers, the promotion sequence is: byte →
short → int → long → overflow exception. For
+floating-point numbers, the sequence is: float → double → infinity.
+
+As a example the following query...
+
+"""
+g.withSack(32767s).inject(1s).sack(sum).sack()
+"""
+
+Before would return a short overflow exception or wrap to -1 depending on
language, but now returns 32769i.
Review Comment:
```suggestion
The following example showcases the difference in overflow behavior between
3.7.3 and 3.8.0
[source,groovy]
----
// 3.7.3
gremlin> g.inject([Byte.MAX_VALUE, (byte) 1], [Short.MAX_VALUE, (short) 1],
[Integer.MAX_VALUE,1], [Long.MAX_VALUE, 1l]).sum(local)
==>-128 // byte
==>-32768 // short
==>-2147483648 // int
==>-9223372036854775808 // long
gremlin> g.inject([Float.MAX_VALUE, Float.MAX_VALUE], [Double.MAX_VALUE,
Double.MAX_VALUE]).sum(local)
==>Infinity // float
==>Infinity // double
// 3.8.0
gremlin> g.inject([Byte.MAX_VALUE, (byte) 1], [Short.MAX_VALUE, (short) 1],
[Integer.MAX_VALUE,1]).sum(local)
==>128 // short
==>32768 // int
==>2147483648 // long
gremlin> g.inject([Long.MAX_VALUE, 1l]).sum(local)
// throws java.lang.ArithmeticException: long overflow
gremlin> g.inject([Float.MAX_VALUE, Float.MAX_VALUE], [Double.MAX_VALUE,
Double.MAX_VALUE]).sum(local)
==>6.805646932770577E38 // double
==>Infinity // double
----
> Better handle overflows with sum()
> ----------------------------------
>
> Key: TINKERPOP-3115
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3115
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.7.2
> Reporter: Stephen Mallette
> Priority: Minor
> Labels: breaking
>
> {{code}}
> gremlin> g.inject([(byte) 126, (byte) 2]).sum(local)
> ==>-128
> {{code}}
> that output seems unexpected. oddly it didn't work that way for the global
> version of {{sum()}} because the type auto promoted to {{long}} because there
> was multiplication by the {{bulk}} which was {{long}}. That changed on
> TINKERPOP-3088 though so now even the global version will work like this.
> seems like it would be better to promote they type whenever it didn't fit
> into the space allotted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
