[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Q on XSLT number calculation precision
Subject: Re: [xsl] Q on XSLT number calculation precision From: Hermann Stamm-Wilbrandt <STAMMW@xxxxxxxxxx> Date: Sat, 19 Feb 2011 14:42:33 +0100 |
Thanks Michael, > Your question actually seems to be about XSLT 1.0. as of now, yes, no browser seems to support more than XSLT 1.0. > XSLT 1.0 requires use of IEEE double precision floating point. > But I suspect there's sufficient wriggle-room that two processors > can produce different results and still claim conformance. I am not sure about that, the smallest summation term 1 / (1012 choose 2) is not that small: 0.0000000000000000000000000004432025658327256 But as Michel mentioned XSLT processors might reorder computation execution and that may be the reason for the differences. Mit besten Gruessen / Best wishes, Hermann Stamm-Wilbrandt Developer, XML Compiler, L3 Fixpack team lead WebSphere DataPower SOA Appliances ---------------------------------------------------------------------- IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 From: Michael Kay <mike@xxxxxxxxxxxx> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Date: 02/18/2011 01:05 AM Subject: Re: [xsl] Q on XSLT number calculation precision On 17/02/2011 22:56, Hermann Stamm-Wilbrandt wrote: > Hello, > > are there any requirements on precision of number calculations for XSLT? Your question actually seems to be about XSLT 1.0. XSLT 1.0 requires use of IEEE double precision floating point. But I suspect there's sufficient wriggle-room that two processors can produce different results and still claim conformance. Michael Kay Saxonica > I wrote stylesheet [3] just summing the first 1000 (small) terms of this > nice identity on binomial coefficient reciprocals I proved 28 years ago: > > $$ \sum_{i=j+1}^{\infty}{}^1/_{i\choose j}={}^1/_{(j-1)} , ~ j\ge 2 $$ > > Pascal.xml [2] just starts the computation with jmax=12 and terms=1000. > > I opened Pascal.xml in the big five browsers, arranged them in order to > easily compare their results and took screenshot [3] from that. > > Not surprisingly the most left and most right column (Chrome and Safari) > are identical (same XSLT engine). > > Interestingly Firefox and Internet Explorer produce nearly identical > values. > > For j<=7 Opera is fine, but for j>=8 something goes really wrong. > The sum of the 1000 terms becomes bigger than then infinity sum :-) > > > [1] > http://stamm-wilbrandt.de/en/xsl-list/Chrome_FF_IE_Opera_Safari-XSLT_precision.gif > [2] http://stamm-wilbrandt.de/en/blog/Pascal.xml > [3] http://stamm-wilbrandt.de/en/blog/Pascal.xsl > > > Mit besten Gruessen / Best wishes, > > Hermann Stamm-Wilbrandt > Developer, XML Compiler, L3 > Fixpack team lead > WebSphere DataPower SOA Appliances > ---------------------------------------------------------------------- > IBM Deutschland Research& Development GmbH > Vorsitzender des Aufsichtsrats: Martin Jetter > Geschaeftsfuehrung: Dirk Wittkopp > Sitz der Gesellschaft: Boeblingen > Registergericht: Amtsgericht Stuttgart, HRB 243294
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Q on XSLT number calculat, Michel Hendriksen | Thread | [xsl] recursion, Szabo, Patrick \(LNG |
Re: [xsl] Bitwise Operations:More e, Eliot Kimber | Date | [xsl] libxslt 10124 detects a poten, spam . spam . spam . |
Month |