*From*: Thomas Broyer <tbroyer ltgt net>*To*: xml gnome org*Subject*: Re: [xml] core dump buglet in libxml2 when setting new prop*Date*: Tue, 24 Apr 2001 16:05:41 +0200

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 garbage.

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. Tom. P.S.: sorry for breaking threads, balsa crashed and I lost some mails, I just cut&pasted from on-line archives.

**Follow-Ups**:**Re: [xml] XPath numbers and exponential notation***From:*Bjorn Reese

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