Re: [xml] core dump buglet in libxml2 when setting new prop

Thomas Broyer wrote: 
Since then, illegal expressions such as "75.2E-12" became legal in
libxml view and some expressions don't produce expected result anymore
(the above example is converted to the string "7.52e-11" whereas
"0.0000000000752" is expected)

Any explaination about the why and the goal of such a transformation? 

Very simple. XPath uses ANSI/IEEE Std 754 (1985) for floating point
numbers. This standard uses a fixed numbers of digits (bits, actually) to
represent numbers, which means that it cannot accurately represent, say,
the number pi as it would require an infinite number of digits.

The XPath spec states (4.2 String Functions, string()) that a float should
be represented with "as many, but only as many, [] digits as are needed to
uniquely distinguish the number from all other IEEE 754 numeric values."

It also means that big numbers cannot be represented accurately with the
regular 9.9 floating point notation.

What's this notation?

If we were going to try this, the least significant digit would be

See above.

Notice that the XPath spec also have a note saying that "the string
function is not intended for converting numbers into strings for
presentation to users." Thus, whether the output has some garbage isn't
really annoying.

Anybody who disagrees are welcome to contribute a patch.

I'm feeling like Daniel and would prefer an extension function or at least
a flag (similar to SAX properties) to switch between XPath 1.0 and partial
XPath 2.0 conformance.

P.S.: sorry for breaking threads, balsa crashed and I lost some mails, I
just cut&pasted from on-line archives.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]