Bug #2882: QuickCompare for numerics fails if whitespace is present - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2882

closed

QuickCompare for numerics fails if whitespace is present

Added by Michael Kay over 7 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

XPath conformance

Sprint/Milestone:

Start date:

2016-08-17

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7, trunk

Fix Committed on Branch:

9.7, trunk

Fixed in Maintenance Release:

9.7.0.8

Platforms:

Description

Reported by Wolfgang May on the saxon-help list at SourceForge:

I have an XML case where numeric values are not always perfectly formatted.

As far as I understand, numeric comparisons in XPath filters should nevertheless

work - but they don't (saxon 9.7.0.7).

Small Example:

let $ex :=
 <bla><n>10</n>
      <n>123</n>
      <n> 1234 </n>
      <n>
         1234
      </n>
      <n>12345</n>
 </bla>
return
$ex[n>1000]

Actions

Copy link

Updated by Michael Kay over 7 years ago

Status changed from New to In Progress
Applies to branch 9.8 added
Fix Committed on Branch 9.7, 9.8 added

I have committed a fix on the 9.7 and 9.8 branches that fixes the problem.

The strategy being used is to avoid converting the string to a number if possible. Assuming positive numbers without leading zeroes:

(a) if the numbers are unequal lengths then the shorter one is smaller

(b) if the first digit differs then this determines the comparison

If the numbers are the same length and share the same first digit, then the code reverts to the "slow path" of converting the string to a number; and if there is no decimal point then this fails in the event that the string contains spaces.

Actions

Copy link

Updated by Michael Kay over 7 years ago

While looking at this I noticed that the quick-compare code is used for generalComparisons but not for valueComparisons, which is unfortunate since many generalComparisons are optimized into a valueComparison. So I'll leave the bug open as a reminder to take a look at this.

Actions

Copy link

Updated by Michael Kay over 7 years ago

Status changed from In Progress to Resolved

On the 9.8 branch I have made further changes so that the quickCompare optimization is now used for ValueComparisons as well as GeneralComparisons, if sufficient type information is available statically to determine that this is appropriate.

Actions

Copy link