Re: [xslt] XPath number formatting

[Vincent Lefevre <vincent+gnome vinc17 org>]

On 2006-04-10 11:20:18 +0200, Bjorn Reese wrote:
> In the following I will try to elaborate on the reasoning behind the
> cited discussion. Although the discussion was only addressing decimal
> point numbers, I believe that the basic rationale can be extended to
> integer numbers as well.
> 
> By "9.9 floating point notation" I was referring to the notation without
> an exponent (e.g. the %f specifier for printf). This makes my above
> statement is trivially true: with at most 17 digits available in IEEE
> 754, we cannot accurately represent numbers with 18 digits or more.
> 
> There tends to be two diverging points of view about how to regard the
> digits beyond 17 (called excessive digits in the following), depending
> on what you want to use the number for.

This reasoning should be done when standardizing the spec, not
when implementing the spec! You must not forget that XML is also
a data interchange format and people may need to read it again
with a different XML/XPath/XSLT implementation.

> People who need to convert numbers into strings and back without loss
> of precision want to use the excessive digits to convey as much
> information as possible to be able to round numbers correctly when
> they are converted back from strings to numbers.

And *being able* to do that is very important.

> People who need to convert numbers into strings to be presented to
> users want to avoid that users believe that the excessive digits convey
> accurate information. An example of this point of view is expressed in
> the design rule "Never give an answer with more precision than is
> warranted." See:
> 
>   http://catless.ncl.ac.uk/Risks/24.17.html#subj1

This may be a reasonable point of view for final results given to
the end user, but not for internal/basic conversions.

Also, you mix up precision and accuracy. One has here a 17-digit
precision (for XPath numbers), but the accuracy may be lower (e.g.
due to rounding errors or inputs with a low accuracy such as those
coming from physical measurements) or higher (e.g. if one knows
that the computations have been performed exactly, such as some
computations on integers). So, the accuracy depends very much on
the application. Therefore the only good solution is to let the
author decide the string format (the number of output digits),
and this is the goal of the XSLT format-number function (other
languages with XPath access can do the same thing, e.g. get the
full-precision number with XPath and use some function of the
language, such as printf in C and Perl).

> If you belong to the first group of people, then the excessive
> digits are important and certainly not to be regarded as garbage. If
> you belong to the second group of people then the excessive digits
> are garbage, and potentially harmful (see above link).

Getting the full-precision number in the number -> string conversion
allows to satisfy both groups (see above). Moreover, it is the only
way to conform to the XPath spec.

[...]
> I did not write the integer part of the formatting code, nor do I use
> it, so I have no objections against extending the range to 53-bit
> numbers.
> 
> However, we must decide how to handle both decimal and integer numbers
> outside the legal range.

In XPath 1.0, there are only IEEE-754 double-precision numbers (which
may be integers or not). Why not follow the XPath 1.0 spec?

> My preference is to use scientific notations, since this is also the
> solution chosen by later versions of the specs.

The latest version of XPath 1.0 chose a fixed-point notation (i.e.
without an exponent). If you speak about XPath 2.0, then as I've
said in a previous message, XPath 2.0 still allows to use the
fixed-point notation, with another method (by using xs:decimal).
If you want to go in this direction, then libxml2 should implement
XPath 2.0 completely, since XPath 1.0 and XPath 2.0 are not
compatible.

-- 
Vincent Lefèvre <vincent vinc17 org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA