On Wed, Mar 16, 2011 at 4:58 AM, Julien PUYDT <julien.pu...@laposte.net> wrote: > Le 16/03/2011 08:55, Robert Bradshaw a écrit : >> >> 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. > > Sorry to tell it so bluntly, but what you say doesn't make that much sense : > the result isn't inferior.
It has higher absolute error. It has higher relative error. It's a non-integral result for what should be mathematically an integer and is representable exactly. Just because two things are within tolerance doesn't mean one can't be more accurate. > Sage is asked a result with a "long double" > precision, and it gives back a result with a "long double" precision. > The expectation that "long double" is *strictly* better better than "double" > is wrong. Python floats (the input and output here) are normal doubles, whether long doubles are used is an implementation detail. The result is off by (at least) 1 standard double ulp. Accurate to a double, in my book, means within .5 upl. As I said, maybe it's just a shortcoming in the platform. > See also my other mail where I give the results of other computations and > suggest looking at how correct the result is depending on its type. Yep, MPFR and MPZ are correct on all platforms (i.e. they return the answer to within .5 ulp). - 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
