XSLT2.0 中的精度、舍入和数据类型
Precision, Rounding, and data types in XSLT2.0
这是一个关于精度、舍入、数据类型以及在 XSLT 2.0 中使用 xs:integer() 函数的问题。我们有以下代码行：
<xsl:value-of select="xs:integer(round(InvoiceAmount * 100))"/>
当来源XML中InvoiceAmount的值为-62.84时，value-of的结果为-6283，这是不正确的。我们已经找到了解决这个问题的方法，但我们真的需要知道这里发生了什么。
我们认为这是二进制乘法的一个错误，其中值偏离了一小部分，我们尝试了以下使用 format-number 到小数点后 32 位，但没有显示任何内容（返回 - 6284.0 0 到 32 位):
<xsl:value-of select="format-number(InvoiceAmount * 100,'0.00000000000000000000000000000000')"/>
此外，如果我们用硬编码的 -62.84 替换 XSL 中的 InvoiceAmount，它会给出正确的结果 (-6284)。如果我们不使用 xs:integer() 转换为整数，它也会给出正确的结果。如果我们使用 xs:decimal() 而不是 xs:integer() 它会起作用。如果我们立即将 XML 值转换为十进制（请参阅以下代码），它会起作用：
<xsl:value-of select="xs:integer(round(xs:decimal(InvoiceAmount) * 100))"/>
我不知道它默认使用什么数据类型，但是一旦它知道 InvoiceAmount 是小数就没问题了。因此，我们有解决该问题的方法，但我们想知道它假设 InvoiceAmount 的数据类型是什么，然后为什么乘以 100、舍入和转换为整数会导致问题。
谢谢，
史蒂夫
假设不涉及模式，元素 InvoiceAmount 的类型化值为 xs:untypedAtomic - 这实际上意味着一个字符串，但它会根据使用它的上下文进行调整。如果您显式转换为 xs:decimal，untypedAtomic 值“-62.84”将准确转换。如果不进行显式转换，那么当你乘以 100 时，该值将被视为 xs:double，并且没有 xs:double 值恰好是 -62.84，因此它必须找到最近的双。
可在此处找到从 xs:untypedAtomic 到 xs:string 的 XSLT 2.0 转换规则：
http://www.w3.org/TR/xpath-functions/#casting-from-strings
这又遵循 XML Schema 1.0 第 2 部分中的规则，可在此处找到：
http://www.w3.org/TR/xmlschema-2/#double
相关规则是
"A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· of double that is closest to d; if d is exactly halfway between two such values then the even value is chosen. This is the best approximation of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is more accurate than the mapping required by [IEEE 754-1985]."
现在，这给实现带来了一些问题。 Clinger 和 Gay 给出的用于查找最接近的 xs:double 值的算法非常复杂，许多产品可能通过调用它们方便的编程语言库提供的任何字符串到双精度转换来走捷径，这是可能更快但不太准确。
XSD 1.1 承认失败："Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·." 但是 post-日期 XSLT 2.0，因此严格符合 XSLT 2.0 处理器必须遵循 Clinger/Gay。
Saxon 通过 (a) 检查一些 Java 允许而 XPath 不允许的东西（例如十六进制数字），然后 (b) 调用 [=46] 来实现字符串到双精度的转换=]()。当应用于字符串“-62.84”时，其效果是生成一个双精度值，其精确数值为 -62.840000000000003410605131648480892181396484375。这是最接近 -62.84 的两倍吗？我在某个地方找到了一些工具来检查这个，但我认为它们不在我今天使用的机器上。
在双精度运算中将其乘以 100 得到的值恰好是 -6284。
由于 round() 舍入到最接近的整数，并且我们有一个值恰好等于整数或至少非常接近，所以我看不出任何一致的实现如何产生 -6283。这并不是说该值接近两个整数之间的中点，在更宽松的 XSD 1.1 规则下，一些变化是允许的。
这是一个关于精度、舍入、数据类型以及在 XSLT 2.0 中使用 xs:integer() 函数的问题。我们有以下代码行：
<xsl:value-of select="xs:integer(round(InvoiceAmount * 100))"/>
当来源XML中InvoiceAmount的值为-62.84时，value-of的结果为-6283，这是不正确的。我们已经找到了解决这个问题的方法，但我们真的需要知道这里发生了什么。
我们认为这是二进制乘法的一个错误，其中值偏离了一小部分，我们尝试了以下使用 format-number 到小数点后 32 位，但没有显示任何内容（返回 - 6284.0 0 到 32 位):
<xsl:value-of select="format-number(InvoiceAmount * 100,'0.00000000000000000000000000000000')"/>
此外，如果我们用硬编码的 -62.84 替换 XSL 中的 InvoiceAmount，它会给出正确的结果 (-6284)。如果我们不使用 xs:integer() 转换为整数，它也会给出正确的结果。如果我们使用 xs:decimal() 而不是 xs:integer() 它会起作用。如果我们立即将 XML 值转换为十进制（请参阅以下代码），它会起作用：
<xsl:value-of select="xs:integer(round(xs:decimal(InvoiceAmount) * 100))"/>
我不知道它默认使用什么数据类型，但是一旦它知道 InvoiceAmount 是小数就没问题了。因此，我们有解决该问题的方法，但我们想知道它假设 InvoiceAmount 的数据类型是什么，然后为什么乘以 100、舍入和转换为整数会导致问题。
谢谢，
史蒂夫
假设不涉及模式，元素 InvoiceAmount 的类型化值为 xs:untypedAtomic - 这实际上意味着一个字符串，但它会根据使用它的上下文进行调整。如果您显式转换为 xs:decimal，untypedAtomic 值“-62.84”将准确转换。如果不进行显式转换，那么当你乘以 100 时，该值将被视为 xs:double，并且没有 xs:double 值恰好是 -62.84，因此它必须找到最近的双。
可在此处找到从 xs:untypedAtomic 到 xs:string 的 XSLT 2.0 转换规则：
http://www.w3.org/TR/xpath-functions/#casting-from-strings
这又遵循 XML Schema 1.0 第 2 部分中的规则，可在此处找到：
http://www.w3.org/TR/xmlschema-2/#double
相关规则是
"A literal in the ·lexical space· representing a decimal number d maps to the normalized value in the ·value space· of double that is closest to d; if d is exactly halfway between two such values then the even value is chosen. This is the best approximation of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is more accurate than the mapping required by [IEEE 754-1985]."
现在，这给实现带来了一些问题。 Clinger 和 Gay 给出的用于查找最接近的 xs:double 值的算法非常复杂，许多产品可能通过调用它们方便的编程语言库提供的任何字符串到双精度转换来走捷径，这是可能更快但不太准确。
XSD 1.1 承认失败："Since IEEE allows some variation in rounding of values, processors conforming to this specification may exhibit some variation in their ·lexical mappings·." 但是 post-日期 XSLT 2.0，因此严格符合 XSLT 2.0 处理器必须遵循 Clinger/Gay。
Saxon 通过 (a) 检查一些 Java 允许而 XPath 不允许的东西（例如十六进制数字），然后 (b) 调用 [=46] 来实现字符串到双精度的转换=]()。当应用于字符串“-62.84”时，其效果是生成一个双精度值，其精确数值为 -62.840000000000003410605131648480892181396484375。这是最接近 -62.84 的两倍吗？我在某个地方找到了一些工具来检查这个，但我认为它们不在我今天使用的机器上。
在双精度运算中将其乘以 100 得到的值恰好是 -6284。
由于 round() 舍入到最接近的整数，并且我们有一个值恰好等于整数或至少非常接近，所以我看不出任何一致的实现如何产生 -6283。这并不是说该值接近两个整数之间的中点，在更宽松的 XSD 1.1 规则下，一些变化是允许的。