Hello Everyone, There are several TinkerPop issues that were opened due to the behaviour of the sum() step handling of overflows. The latest release 3.7.3 of TinkerPop handles overflow/underflow by silently wrapping the value around to the minimum/maximum value for the relevant type.
Example: // int overflow wraps around to negative value gremlin> g.inject([Integer.MAX_VALUE,1]).sum() ==>-2147483648 This wrapping behaviour can be unexpected for users as demonstrated by the following issues: https://issues.apache.org/jira/browse/TINKERPOP-2877 https://issues.apache.org/jira/browse/TINKERPOP-3115 https://issues.apache.org/jira/browse/TINKERPOP-3099 For TinkerPop 3.8 I’m proposing to improve overflow handling through type promotion. This would mean that in the event of overflow/underflow, the following automatic type promotions would be applied: Float->Double Double->Infinity Byte->Short Short->Integer Integer->Long Long->throw ArithmeticException Example: // int promoted to long gremlin> g.inject(Integer.MAX_VALUE, 1).sum() ==>2147483648 One should note that I’ve chosen type limits for automatic promotion to be Double and Long and not BigDecimal and BigInteger. This is to avoid automatic promotion to extended types that are not necessarily supported by all GLVs or providers. I also intend to add a number casting step which allow users to cast numeric values to a given type (similar to asDate() but for numbers), which would allow users to fine tune the overflow handling in their system, provided the casting is applied before the sum(). Other steps which can encounter overflow will also be affected by these changes such as mean(), sack(), etc. Please reach out if you have any feedback regarding this topic. Cheers, Andrea
