[OASIS Issue Tracker] (ODATA-785) Numeric promotion (on overflow) across "number type families" is undesirable.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/ODATA-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58653#comment-58653 ] 

Evan Ireland commented on ODATA-785:
------------------------------------

We have mixed two types of numeric promotion in one requirement.

* Numeric promotion due to mismatched operand types. The user may reasonably expect this based on understanding of the property types / lteral values that have been used in a filter.

* Numeric promotion due to overflow, which is generally *unexpected* by the user. Can they predict (based on property types / literal values) whether a given subexpression will be true, false, or cause their request to fail entirely? How can they write their query so as to be certain to prevent request failure (as opposed to finding that some rows are excluded from the result set).

Or, the user might prefer to get request failure when integer overflow occurs, since integer arithmetic is exact (except when overflowing, and noting the implicit rounding during division), but once promoted (though decimal) into Single, they are now working unexpectedly with approximations.

Also, a lot of unexpected fun is lurking here for server implementors:

http://stackoverflow.com/questions/12226634/how-to-prevent-integer-overflow-in-java-code

Perhaps we could note that numeric overflow across number type factories may be revisited in future, rather than setting it in stone. (Or remove the requirement or lessen it to a requirement for promotion between integral types only), making promotion on overflow unspecified for the more general case, leaving implementations free to still implement according to the removed requirement, but not requiring it).


> Numeric promotion (on overflow) across "number type families" is undesirable.
> -----------------------------------------------------------------------------
>
>                 Key: ODATA-785
>                 URL: https://issues.oasis-open.org/browse/ODATA-785
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData URL Conventions
>    Affects Versions: V4.0_OS
>            Reporter: Evan Ireland
>            Priority: Minor
>             Fix For: V4.0_ERRATA03
>
>
> URL Conventions spec section 5.1.1.10 "Numeric Promotion" states:
>   "If the result of an arithmetic operation does not fit into the type determined by the above rules, the next-wider type is used in the above order, with Edm.Double considered widest."
> We may group OData numeric types into three families:
>   integer types: Byte, SByte, Int16, Int32, Int64
>   decimal types: Decimal
>   floating types: Single, Double
> Numeric promotion as a result of overflow is undesirable when it results in promotion between number type families. The semantics of arithmetic operators can therefore not be determined by static analysis. For example:
> First issue:
> ----------------
> If A, B and C integer values, then "(A add B) div C" is an integer unless "A add B" overflows Int64, in which case "(A add B) div C" will be decimal.
> Now consider "((A add B) div C) mod D". If "(A add B) div C" is decimal due to overflow, then "((A add B) div C) mod D" is an invalid expression since the "mod" operator is only defined for integral types.
> Second issue:
> ----------------
> Now consider that X and Y are decimal values. If (X add Y) overflows the range for decimal values, then according to the spec, (X add Y) is promoted to type Single. Two issues then arise:
> (1) Type Single has much less precision than either Decimal or Double. The implicit promotion on overflow should (if we permit promotion across number type familes) arguably be to type Double, to avoid unnecessary loss of precision.
> (2) "(X add Y)" div 0 is an error if "X add Y" does not overflow, but is positive or negative infinity if "X add Y" overflows and is promoted to a floating type. So the semantics of division are not statically determinable.
> Third issue:
> ----------------
> Consider (E add F) where E and F are type Single.
> Promotion of the result from Single to Double (on overflow, say if the result exponent is outside the range of type Single) is not in accordance with IEEE floating point rules, which specify positive or negative infinity in this case.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)