On 2011-12-21 05:35:53 +0100, Segher Boessenkool wrote: > ...And then, of course, I discover the program does not calculate > f**(2*S) but f**(2*S-1). Which makes my "correct" results not so > very correct. Ouch. > > >It outputs: > > > >nearest = 0.36787944637187158792 > >down = 0.36787944526181193261 > > > >while we have > > correct = 0.36787944576993540330 > > so both rounding modes are about equal. > > >Now you can say that this is because x already is rounded from the > >true value, > > ... and this is indeed ... > > >the case: taking S=2**25, we get > > > >nearest = 0.36787944391225085860 > >down = 0.36787944204965455918 > > > >with > > correct = 0.36787944391235777181 > > so in that case round towards zero gets twice as many bits > wrong as round to nearest, just as a naive analysis would show. and ideally, you should test programs on many inputs, and also prove error bounds (which will probably be pessimistic, but guaranteed). Now, what I wanted to say is that in general, leaving the rounding to nearest and setting FTZ would be much better than changing the rounding mode globally. Another drawback of changing the rounding mode globally is that some libraries may not support it; this is the case of the math library from the glibc on x86_64 (and other processors for which the same code is used): http://sourceware.org/bugzilla/show_bug.cgi?id=3976 -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
