Uploaded image for project: 'OASIS Open Data Protocol (OData) TC'
  1. OASIS Open Data Protocol (OData) TC
  2. ODATA-785

Numeric promotion (on overflow) across "number type families" is undesirable.

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: V4.0_OS
    • Fix Version/s: V4.0_ERRATA03
    • Component/s: URL Conventions
    • Labels:
      None
    • Environment:

      Applied

    • Proposal:
      Hide

      In errata 3:
      1) specify that, within comparison expressions, services should promote as necessary to perform comparison operations – should not be unnecessarily restricted by types of operands. (expressions may be calculated and compared using more precision than the operands)

      Open issues for 4.01:
      1) Add divideby that always results in a decimal (as if both operands were promoted to decimal)
      2) Specify the result type for each operation based on operator types
      a) Don't promote outside of type families
      b) Do not promote Single->Double
      3) Specify overflow of int (would need to add +inf/-inf/nan to int)
      a) Push for, in JSON Schema 5, that the strings "-inf", "+inf", "nan" are valid for numbers

      [original:
      -Expressly disallow numeric promotion (on overflow) across number type families.
      -Expressly disallow numeric promotion (on overflow) between Single and Double.
      -The remaining legal option would be numeric promotion on overflow only for integer types.]

      Show
      In errata 3: 1) specify that, within comparison expressions, services should promote as necessary to perform comparison operations – should not be unnecessarily restricted by types of operands. (expressions may be calculated and compared using more precision than the operands) Open issues for 4.01: 1) Add divideby that always results in a decimal (as if both operands were promoted to decimal) 2) Specify the result type for each operation based on operator types a) Don't promote outside of type families b) Do not promote Single->Double 3) Specify overflow of int (would need to add +inf/-inf/nan to int) a) Push for, in JSON Schema 5, that the strings "-inf", "+inf", "nan" are valid for numbers [original: -Expressly disallow numeric promotion (on overflow) across number type families. -Expressly disallow numeric promotion (on overflow) between Single and Double. -The remaining legal option would be numeric promotion on overflow only for integer types.]
    • Resolution:
      Show
      https://www.oasis-open.org/committees/download.php/57687/odata-v4.0-wd08-part2-url-conventions-2016-03-03.docx

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              mikep Michael Pizzo
              Reporter:
              evan.ireland.2 Evan Ireland
            • Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: