On Dec 29, 2009, at 9:59 PM, Peter Jeremy wrote:
> On 2009-Dec-29 23:29:42 +0000, "Dr. David Kirkby" <[email protected]
> > wrote:
>> There are a few failures, but these couple just came up, and look
>> rather odd, as this is only an error in the last decimal place, and
>> so will be subject to rounding errors with different floating point
>> processors. They do not really seem failures to me.
>
> One of the claims for IEEE-754 arithmetic is that basic arithmetic
> operations (+, -, *, /, sqrt) will give bit-for-bit identical
> results on different implementations.
I would have expected t2 to be IEEE-754 compliant, but maybe it isn't.
>> **********************************************************************
>> File "/rootpool2/local/kirkby/sage-4.3/devel/sage/sage/symbolic/
>> pynac.pyx", line
>> 1276:
>> sage: py_exp(float(1))
>> Expected:
>> 2.7182818284590451
>> Got:
>> 2.7182818284590455
>> **********************************************************************
>
> As a correctly rounded IEEE-754 double precision constant,
> e=0x4005BF0A8B145769 (0x2.B7E1 5162 8AED 2), this should convert
> to 2.7182818284590451 (rounded to "sufficient" accuracy).
>
> 2.7182818284590455 is 1ULP high - this may reflect a rounding error
> in either the exp() or double_to_ascii() implementation.
It's probably not double_to_ascii, as (on t2)
>>> float("2.7182818284590452353602874713526625")
2.7182818284590451
I bet Solaris has a completely different (and unfortunately not as
accurate) implementation of exp in its libm. It could also be a bug in
the compiler, as math.e is defined as
src/Include/pymath.h:#define Py_MATH_E 2.7182818284590452354
which has much less than 1 ulp accuracy. In any case, the correct fix
is as William mentioned to do place ...'s for the last digit.
- Robert
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
