[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

*Subject*: **[OASIS Issue Tracker] (ODATA-771) Exponential notation for Edm.Decimal values in JSON payloads**

*From*:**OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>***To*: odata@lists.oasis-open.org*Date*: Tue, 17 Feb 2015 03:50:23 +0000 (UTC)

[ https://issues.oasis-open.org/browse/ODATA-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58140#comment-58140 ] Evan Ireland commented on ODATA-771: ------------------------------------ If we consider allowing exponential representation for decimal values in URL Conventions, then... Consider this filter expression: 9223372036854775809 gt 9223372036854775808 With the current ABNF, both values (too big to be valid int64Value) match decimalValue, doubleValue and singleValue. The expression is true only if we consider that non-exponential literals (too big for byteValue/sbyteValue/int16Value/int32Value/int64Value) will match decimalValue. Otherwise, we get an anomalous false value. The current situation is that at least we have a reasonable interepretation that non-exponential values are decimals, and exponential values are doubles. (With that interpretation, there are no singleValue literals). If the ABNF is changed to permit 'e' notation for decimal values, then any number that doesn't match byteValue/sbyteValue/int16Value/int32Value/int64Value will be even more ambiguous, as it will match decimalValue, doubleValue and singleValue. Consider this filter expression: 9223372036854775809e0 gt 9223372036854775808e0 If we interpret those as decimal values, the expression is still true. Otherwise (evaluated using IEEE double precision arithmetic) it is false. That suggests that we must use the decimalValue interpretation in such cases to avoid anomalies. In which case, there is no literal form that matches singleValue or doubleValue. This may result in inefficient implementations, as decimal arithmetic can be expensive (e.g. in Java with BigDecimal). There is no "right answer" to the interpretation of large or exponential numeric literals in URLs. * Treating all large or exponential numeric literals as decimals may be inefficient (it also may cause issues of representation of values with large exponents). * Treating all large or exponential numeric literals as doubles may cause loss of precision, as in the above example. Perhaps we need explicit suffixes (m/M, d/D, f/F) for these types after all? > Exponential notation for Edm.Decimal values in JSON payloads > ------------------------------------------------------------ > > Key: ODATA-771 > URL: https://issues.oasis-open.org/browse/ODATA-771 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Improvement > Components: OData JSON Format > Affects Versions: V4.0_ERRATA02 > Environment: [Proposed] > Reporter: Ralf Handl > Fix For: V4.0_ERRATA03 > > > IEEE754 defines the DECFLOAT data type for high-precision decimal arithmetic. They have 16 or 34 decimal digit mantissas and exponents between -383 and +384 or -6143 and +6144. > The correct, lossless representation of DECFLOAT values is an Edm.Decimal with unspecified precision and variable scale. > The OData JSON Format represents Edm.Decimal values as JSON numbers, and JSON numbers allow exponential notation, so > "VeryLittle":1.4e-6143 > should be valid in JSON payloads. -- This message was sent by Atlassian JIRA (v6.2.2#6258)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]