objectDivDecimal extends NumericOp with Product with Serializable
Division with rounding for decimals
About the rounding.
Without rounding specified here, you can get an java arithmetic exception
Specifically:
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
What's questionable here, is to what number of fraction digits it will round.
That can be specified also as an argument to divide(), but we have no
information here (or anywhere really) about what precision is desired.
So we're omitting that and just saying "round it".
Really, there's no rounding scale/precision until we're ready to represent
the number in a string. In this case we're not. We're in the middle of an
expression, just happen to have two BigDecimal operands, and we're dividing
them, which should produce a BigDecimal result.
For xs:decimal values, let N be the number of digits of precision
supported by the implementation, and let M (M <= N) be the minimum
limit on the number of digits required for conformance (18 digits
for XSD 1.0, 16 digits for XSD 1.1). Then for addition, subtraction,
and multiplication operations, the returned result should be accurate
to N digits of precision, and for division and modulus operations,
the returned result should be accurate to at least M digits of precision.
The actual precision is ·implementation-defined·. If the number of digits
in the mathematical result exceeds the number of digits that the
implementation retains for that operation, the result is truncated
or rounded in an ·implementation-defined· manner
In our case, the implementation does what the JVM and java libraries do when
divide() is called with two arguments the second of which specifies
to round half-up.
Linear Supertypes
Serializable, Serializable, Product, Equals, NumericOp, AnyRef, Any
Division with rounding for decimals
About the rounding.
Without rounding specified here, you can get an java arithmetic exception Specifically:
What's questionable here, is to what number of fraction digits it will round. That can be specified also as an argument to divide(), but we have no information here (or anywhere really) about what precision is desired. So we're omitting that and just saying "round it".
Really, there's no rounding scale/precision until we're ready to represent the number in a string. In this case we're not. We're in the middle of an expression, just happen to have two BigDecimal operands, and we're dividing them, which should produce a BigDecimal result.
DFDL expressions are supposed to be consistent with XPath, so we look there for suggestions. The XPath spec https://www.w3.org/TR/xpath-functions-3/#op.numeric says it is implementation defined.
For xs:decimal values, let N be the number of digits of precision supported by the implementation, and let M (M <= N) be the minimum limit on the number of digits required for conformance (18 digits for XSD 1.0, 16 digits for XSD 1.1). Then for addition, subtraction, and multiplication operations, the returned result should be accurate to N digits of precision, and for division and modulus operations, the returned result should be accurate to at least M digits of precision. The actual precision is ·implementation-defined·. If the number of digits in the mathematical result exceeds the number of digits that the implementation retains for that operation, the result is truncated or rounded in an ·implementation-defined· manner
In our case, the implementation does what the JVM and java libraries do when divide() is called with two arguments the second of which specifies to round half-up.