[ https://issues.apache.org/jira/browse/XALANC-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145831#comment-13145831 ]
Steven J. Hathaway commented on XALANC-291: ------------------------------------------- The underlying issue relates to FLOAT rendering instead of DOUBLE rendering. XalanC stores numbers as type DOUBLE. The specs declare that 18 characters of precision be rendered and that DOUBLE should be supported. > Floating point output incorrect > ------------------------------- > > Key: XALANC-291 > URL: https://issues.apache.org/jira/browse/XALANC-291 > Project: XalanC > Issue Type: Bug > Components: XalanC > Affects Versions: 1.5 > Environment: Operating System: All > Platform: All > Reporter: Matt Hoyt > > Not sure if these should be logged as seperate bugs, but the source of the > errors has been traced to limitations of the sprintf/"format string lookup > table" of the DomStringHelper::DoubleToDOMString() method. > (1) From conformance test 'string134' (simplified, source xml is irrelevant): > <xsl:template match="/"> > <xsl:value-of select="987654321.012345"/> > </xsl:template> > Produces output: > 987654321.01234496 > Why? The result number is the full decimal value of the binary approximation. > In this case, the input's fraction only has 6 digits but the conversion > method > defaults to at least 10 digits of precision, resulting in the invalid output > of > extra values from the binary approximation. The output precision should be > the > same as the original value's. > (2) From conformance test 'string135' (simplified, source xml is irrelevant): > <xsl:template match="/"> > <xsl:value-of select=".000000000000000000000000000000000000123456789"/> > </xsl:template> > Produces output: > 0 > Why? The conversion method will output 0 for values < 1.0e-35. According to > the the XPath spec a number can be any double-precision 64-bit format IEEE > 754 > number. This all means values > 1.0e-323 should be displayed. Currently, > the > conversion function is limited to creating strings with numbers containing at > most 35 digits of precision. > XalanJ 2.5.1, Saxon 6.5.2 and MSXSL 3.0 behave correctly in these cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org For additional commands, e-mail: xalan-dev-h...@xml.apache.org