[
https://issues.apache.org/jira/browse/TINKERPOP-3088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888724#comment-17888724
]
ASF GitHub Bot commented on TINKERPOP-3088:
-------------------------------------------
spmallette opened a new pull request, #2827:
URL: https://github.com/apache/tinkerpop/pull/2827
https://issues.apache.org/jira/browse/TINKERPOP-3088
The multiplication of the traverser value by the bulk was promoting the type
to long so that even if the values were all int and fitting well within that
space you'd still end up with a long value. Old behavior:
```
gremlin> a = g.V().values('age').sum().next()
==>123
gremlin> a.class
==>class java.lang.Long
```
new behavior after change:
```
gremlin> a = g.V().values('age').sum().next()
==>123
gremlin> a.class
==>class java.lang.Integer
```
VOTE +1
> SumGlobalStep returns a long value even the highest common type's bit <= 32
> ---------------------------------------------------------------------------
>
> Key: TINKERPOP-3088
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3088
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.7.2
> Reporter: Norio Akagi
> Priority: Minor
>
> This happens because in
> {noformat}
> @Override
> public S projectTraverser(final Traverser.Admin<S> traverser) {
> return (S) mul(traverser.get(), traverser.bulk());
> }{noformat}
> It multiplies with bulk, which is Long type, so upcasted. This is at least
> not in semantics and unexpected behavior
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
