Bug #6363
closed
Incorrect result comparing untypedAtomic value to NaN
100%
Description
- I have updated Saxon from version9.1 to version10.6. But for the same Xsl code getting different result. In Saxon10 by default its considering input parameter as string, But in Saxon9 its considering input parameter as number value. This is the expected behavior or something is wrong with input?
- Input data fetched from database using query and whatever data is coming from database its converted into XML format and passed to Xpath function.
- By default its considering input value as String that's why its returning NaN and same time some how its matching to the given condition then its returning true. but actual expectation here is its should return false for that condition.
<xsl:output method="xml" encoding="UTF-8"/>
<xsl:param name="var.variable1"/>
<xsl:template match="/">
<result>
<xsl:choose>
<xsl:when test="(/TestData/amount < number($var.variable1) or /TestData/amount = number($var.variable1))"> <CompValue>true</CompValue>
</xsl:when>
<xsl:otherwise>
<CompValue>false</CompValue>
</xsl:otherwise>
</xsl:choose>
<amount>
<xsl:value-of select="/TestData/amount/text()"/>
</amount>
<var1>
<xsl:value-of select="number($var.variable1)"/>
</var1>
</result>
</xsl:template>
</xsl:stylesheet>
** Input data:**
<?xml version="1.0" encoding="UTF-8"?>
<TestData><amount>555</amount></TestData>
** Saxon 9.1 Output:**
<?xml version="1.0" encoding="UTF-8"?>
<result><CompValue>false</CompValue><amount>555</amount><var1>NaN</var1></result>
Saxon 10.6 Output:
<?xml version="1.0" encoding="UTF-8"?>
<result><CompValue>true</CompValue><amount>555</amount><var1>NaN</var1></result>
** Note:** Here I'm using Saxon 10.6 and Xpath 3.0
Updated by Michael Kay 8 months ago
As I said when you posted the question on StackOverflow, we need to know what value your are supplying for the parameter, and how you are supplying it. Are you using the command line or the Java API? In the latter case, what API are you using and what is the exact call you are making.
You have also left out the xsl:stylesheet element and its version attribute. That information is relevant because the comparison might work differently in XPath 1.0 compatibility mode.
I'm interested in investigating this because I cannot think of any possible scenario that causes the output you are reporting. But to investigate it we need to be able to reproduce it, and in particular, to reproduce the way you are invoking the transformation.
Updated by Michael Kay 8 months ago
I have reproduced the problem (well, it might be the same problem..) by setting the missing xsl:stylesheet/@version attribute to 3.0 and running the transformation from the command line with the parameter var.variable1=abc. Variables supplied on the command line are treated as being of type xs:untypedAtomic, which means they adapt themselves to the way the variable is used.
The comparison /TestData/amount < number($var.variable1) is wrongly returning true. The LH operand is untypedAtomic, the RH operand is the xs:double value NaN. The spec says that the untypedAtomic value should be converted to a number (xs:double(555)) and compared with the other operand numerically. Saxon has a fast path to avoid doing the full conversion: it first does a a quick check of whether the comparison could possibly be true. For example untypedAtomic('5000') eq 42 can be quickly ruled out because no 4-digit number starting with 5 is going to be equal to 42. This optimized path is failing to check whether the numeric argument is NaN.
Updated by Michael Kay 8 months ago
In fact, Saxon is missing a more powerful optimization here. The expression /x/y = $var.variable1 is a many-to-one comparison which is true if any node in /x/y, after atomization, is equal to the value of the variable. But if the variable is NaN, then nothing in /x/y can ever be equal to it, so we can return false without evaluating the path expression at all.
Updated by Michael Kay 8 months ago
- Subject changed from Saxon 10 by default considering given input parameter as a string to Incorrect result comparing untypedAtomic value to NaN
- Category set to XPath conformance
- Status changed from New to In Progress
- Assignee set to Michael Kay
- Applies to branch 10, 11, 12, trunk added
- Platforms .NET, Java added
Updated by Michael Kay 8 months ago
- Status changed from In Progress to Resolved
- Fix Committed on Branch 10, 11, 12, trunk added
I've commited the fix to UntypedNumericComparer.quickCompare() to the 10, 11, 12, and 13 branches, and the new optimisation to the 12 and 13 branches only.
Note that there's no certainty there will ever be any new maintenance releases on the 10 and 11 branches but I put the patch in anyway.
Updated by Manikandan S 8 months ago
Please let me know once you released the patch for 10.6. Thanks.
Updated by Manikandan S 4 months ago
HI @Michael Kay, Can you please confirm the fix version for this fix. Thanks, Manikandan
Updated by Michael Kay 4 months ago
If you are "watching" the issue in PlanIO, then you will be notified of any status changes. We're working on final testing of a 12.5 maintenance release at the moment.
Updated by O'Neil Delpratt 4 months ago
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.5 added
Bug fix applied in the Saxon 12.5 Maintenance release. Not marking this closed until patched in older releases (i.e 11.x).
Please register to edit this issue
.