On Tue, Mar 15, 2011 at 12:55 PM, David Kirkby <david.kir...@onetel.net> wrote: > On 15 March 2011 17:05, Julien PUYDT <julien.pu...@laposte.net> wrote: >> Le 14/03/2011 20:00, Robert Bradshaw a écrit : >>> >>> In the case of the OP's failures, that processor (or libm, libc, >>> whatever) is giving us less accurate answers than anything else we've >>> tested on, and I think it's worth looking into fixing the problem, or >>> even adding an # optional, or as an expected failure on this platform, >>> rather than weakening the examples and tests for all other platforms. >> >> Well, according to the debian developper I pushed the problem to, on such a >> system, "long double" and "double" are the same. > > By "system" I assume you mean operating system and compiler. I believe > the "long double" needs to be supported on the compiler, and is not in > the ARM processor. > > The x86 CPU has an 80-bits, which is used for long-double on some > systems. But not all systems have this (SPARC does not), but the > compiler still supports a long double, where the number of bits is > greater than on the double. > > I may be wrong, but I think that gcc does not handle it any different > to double - which is permitted by the C standard. Although the "long > double" is defined, there's no need for "long double" to use any more > bits than "double". > > You could submit a request for enhancement to the gcc developers for > long double to have more bits than double. They do it for the SPARC > processor, and many other processors. In fact, on some CPUs it is > actually. > >> And the result is then accurate enough, since we see 13 decimal digits after >> the point, and there are 3 before ; that makes 16 good decimal digits. >> >> According to http://en.wikipedia.org/wiki/IEEE_754-2008, double precision >> gives 15.95 decimal digits... > > Yes, its > > sage: log(2^53,10).n() > 15.9545897701910 > > as there are 53 bits in the significand > >>> It reminds me a bit of all the correction we had to do because the >>> literal floating point value for e is not correctly compiled on >>> Solaris. It's one thing to have "numerical noise" in a lengthy >>> computation involving lots of floating point arithmetic, it's another >>> to give non-integral values for gamma(n) for small, integral n. >> >> Well, as far as I know, the result of computing $\Gamma(n)$ for a small >> integral $n$ is mathematically an integer, > > It's true for any positive integer. > >> but the computer function does >> get to the value by a lengthy computation involving lots of floating point >> arithmetic... so the issue isn't that clear! > > True. I don't think there's a lot we can do
We can, for example, call gsl rather than libc. Or we can special case this processor and/or set of values. Whatever process is used to compute the value, the fact is that the result has *no* rounding error on all other platforms. This platform produces inferior results, and I'd call it a bug. Let's fix/work around it, not mask it. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
