Re: [xsl] format-number() causing problems to non-java implementators

> At 10:05 AM -0800 1/17/01, Joe English wrote:
> 
> >>  BTW: Are there more functions causing problems for non Java
> >>  implementators?
> >
> >The requirement that numbers are represented as per IEEE 754
> >is troublesome.  There's no portable way to deal with NaNs
> >and infinities in C, C++, or most other languages (C9X makes
> >things a little easier, but implementations aren't widely available
> >yet.)
> >
> >The 'string()' function is astonishingly difficult to implement
> >correctly without native language support, specifically clause 2,
> >subclause 7, XPATH section 4.2: "there must be as many, but only
> >as many, more digits as are needed to uniquely distinguish the
> >number from all other IEEE 754 numeric values."
> >
> 
> This isn't a Java issue though. Pretty much all modern, 
> general-purpose CPUs that implement floating point use IEEE 754. As 
> well as Java, so do many C, C++, and Fortran compilers. The decision 
> was to go with an existing, well-known, well-understood, 
> well-supported, true standard. Failure of some languages, compilers, 
> and libraries to properly implement that standard is a very different 
> issue than tying XSLT to a non-standard, proprietary API.

I can buy this, even though I find rather naive the belief that it is 
straightforward for any platform, library or language to implement IEEE 754 
consistently.  (Just bringing up 754 on lists where brilliant numericists hang 
out is an invitation to open flame war).

However, can anyone even offer an honest defense of format-number()?


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list