This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: format-number() causing problems to non-java implementators
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] format-number() causing problems to non-java implementators
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Wed, 24 Jan 2001 22:11:08 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> 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@fourthought.com +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