[
https://issues.apache.org/jira/browse/TINKERPOP-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16103247#comment-16103247
]
ASF GitHub Bot commented on TINKERPOP-1736:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/682
This all goes back to typing numbers based on storage size is dumb. Most
modern, high-level languages have arbitrary precision on integer and decimal
values. Languages that have strongly typed numbers, e.g. Java, should have to
adapt accordingly, not the other way around. Gremlin should be a higher-order
language. Thus, the graphson types should be at lowest-level `g:integer`,
`g:double`, or preferably, like json/javascript with just `number`. Further
more, numbers in gremlin should seamlessly be able to be manipulated and
compared to other numbers even of different java types, i.e. storage size
agnostic, language agnostic. :cow2:
> Sack step evaluated by groovy interprets numbers in an unexpected way
> ---------------------------------------------------------------------
>
> Key: TINKERPOP-1736
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1736
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.2.5
> Reporter: stephen mallette
> Assignee: Daniel Kuppitz
> Fix For: 3.3.0, 3.1.8, 3.2.6
>
>
> The issue is discussed to some detail on the dev mailing list:
> https://lists.apache.org/thread.html/6b8060c89f5b3744e7a9d1e421b9de980a3e24eb50563423c7690893@%3Cdev.tinkerpop.apache.org%3E
> but basically, this fails:
> {code}
> gremlin> g.withSack(2).V().sack(div).by(constant(3.0)).sack()
> Non-terminating decimal expansion; no exact representable decimal result.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
