Project

Profile

Help

Bugs in format-number() with Saxon 8.x ?

Added by Anonymous over 18 years ago

Legacy ID: #3334666 Legacy Poster: Pierre-Yves (pbenzaken)

Hi XSLT experts, While testing our application with Saxon 8.5.1, we noticed following differences compared to Saxon 6.5.4: the function format-number produces different outputs. Case 1: Formatting of decimal number 2.195 ------------------------------------------ (A) <xsl:value-of select='format-number(2.19500000, "#0.00")'/> (B) <xsl:value-of select='format-number("2.19500000", "#0.00")'/> (C) <xsl:value-of select='format-number(number("2.19500000"), "#0.00")'/> While Saxon 6.5.4 returns "2.20" in all three cases, Saxon-B 8.5.1 returns "2.19" for (B) and (C), and "2.20" for (A). Why do Saxon 6.5 and Saxon 8.5.1 deliver different results? Why does Saxon 8.5.1 return different results in cases (A) and (B) although, according to the documentation, passing a string to format-number() triggers a call of number() and thus converts the string to a number? Case 2: Formatting of a decimal number with no decimal positions ---------------------------------------------------------------- Another test showed another difference, this time with the formatting of a decimal number, without any decimal position: (D) <xsl:value-of select='format-number(0, "#0.##")'/> (E) <xsl:value-of select='format-number(0.00, "#0.##")'/> (F) <xsl:value-of select='format-number("0.00", "#0.##")'/> (G) <xsl:value-of select='format-number("0", "#0.##")'/> All four calls return the value "0" with Saxon 6.5.4. But with Saxon 8.5.1, "0." is returned for (D). (E), (F) and (G) are correct though ("0"). Any idea, why does Saxon 8.5.1 show the decimal separator, even when no decimal position is present? Thanks for your help Pierre-Yves


Replies (5)

Please register to reply

RE: Bugs in format-number() with Saxon 8.x ? - Added by Anonymous over 18 years ago

Legacy ID: #3334739 Legacy Poster: Michael Kay (mhkay)

Thanks for this information, I will look into it. I assume you had version="1.0" set, otherwise example (B) would have produced an error: with version="2.0" you have to manually convert the string to a number. In case (A) you have supplied a decimal value, and Saxon 8.5.1 is correctly applying the "round half to even" rule. XSLT 1.0 didn't say explicitly how rounding was done, but products like Saxon that used the underlying code in the Java VM would have used this rounding algorithm; XSLT 2.0 makes this mandatory. In cases (B) and (C) the argument to the function is being supplied as a double. I suspect that the string-to-double conversion produces a double that is slightly less than 2.195 because doubles can't represent all decimal values exactly, and this is resulting in the value being rounded down. If that's the case, then I think this is correct according to the spec. This rounding problem doesn't apply when the value supplied is a decimal rather than a double. Case (D) looks like a simple bug. Michael Kay

RE: Bugs in format-number() with Saxon 8.x ? - Added by Anonymous over 18 years ago

Legacy ID: #3334776 Legacy Poster: Michael Kay (mhkay)

Yes, D is a simple bug and I've logged it in the bugs section. Case C/D is more subtle. It is a rounding error, as I suspected, but it's not happening on the initial decimal-to-double conversion, rather within the Saxon format-number code, which starts by multiplying the supplied number by 100 and gets the answer 219.49999999997. I'll have to do some thinking to see how to get around that. MK

RE: Bugs in format-number() with Saxon 8.x ? - Added by Anonymous over 18 years ago

Legacy ID: #3336079 Legacy Poster: Pierre-Yves (pbenzaken)

Good morning Michael, Thanks a lot for your quick and precise answers! Now, the last and less funny question: I guess these bugs will be fixed in the next release of Saxon (8.5.2?). Any idea when this will come out? We need to know, whether we should wait for a fixed version of Saxon 8.x or roll back to Saxon 6.5.4 for our next deployment... :D Thanks again for the good work. Saxon is really a great product! Pierre-Yves

RE: Bugs in format-number() with Saxon 8.x ? - Added by Anonymous over 18 years ago

Legacy ID: #3336160 Legacy Poster: Michael Kay (mhkay)

Saxon 8.5.1 is actually proving to be one of the most reliable releases for a while - the bugs that have been found (like this one) are all ones that I would class as being rather minor (meaning they won't affect many people, and there's an easy workaround). I think it's unlikely there will be an 8.5.2 release - I generally only produce a maintenance release if there are (a) some really bad bugs, or (b) a large number of small bugs. So the next one is likely to be 8.6, and the chances are that this will be less reliable than 8.5.1. because it will have some new optimizations, and new optimizations always introduce bugs. (The nice thing about open source software is you can afford to be honest with people.) I never publish planned dates; it's part of my philosophy to release when the software is ready, not when a particular date arrives. Holding to dates when software isn't ready is in my view a major source of unreliability. There will always be bugs, I'm afraid. There are still occasional bugs in 6.5.4. My aim is a steady reduction in the number of them; and once the 2.0 specs are finished, I hope to produce a "gold" release which will be stabilised by fixing bugs and not making any other changes. For the time being, you can work around these bugs by converting the argument to format-number to xs:decimal, and I would suggest that is what you do. Michael Kay

RE: Bugs in format-number() with Saxon 8.x ? - Added by Anonymous over 18 years ago

Legacy ID: #3336459 Legacy Poster: Pierre-Yves (pbenzaken)

> (The nice thing about open source software is you can afford to be honest with people.) :-D Ok, thanks for your answer. We'll follow your advice! Cheers Pierre-Yves

    (1-5/5)

    Please register to reply