On Dec 30, 2009, at 4:38 PM, Dr. David Kirkby wrote:
> Robert Bradshaw wrote:
>>>>
>>>>>> **********************************************************************
>>>>>> 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
>
>> Yes, that could be the difference for exp. What's more worrisome is
>> that the C compiler incorrectly resolves the literal floating point
>> 2.7182818284590452354 .
>>
>> - Robert
>>
>
> Em, This is very odd. exp(1) gives a different result on SPARC if
> you build
> with gcc or Sun Studio. GCC is correct, and Sun Studio is wrong. Yet
> Sage on
> 't2' was build with gcc, not Sun Studio.
I was actually unable to start sage on t2, so my experience is just
with the plain system Python. (Do you know what that was built with?)
> On Open Solaris, using a Xeon processor, the two compilers give the
> same result.
>
> Here's a noddy C program:
>
> drkir...@kestrel:~$ cat exp.c
> #include <math.h>
> #include <stdio.h>
>
> int main() {
> printf("%.16lf\n",exp(1.0));
> }
>
> This data below is from a SPARC (sun4u architecture) of mine. I've
> tried on 't2'
> (sun4v) and get exactly the same results.
>
> drkir...@kestrel:~$ uname -a
> SunOS kestrel 5.10 Generic_141444-09 sun4u sparc SUNW,UltraAX-i2
> drkir...@kestrel:~$ cat exp.c
> #include <math.h>
> #include <stdio.h>
>
> int main() {
> printf("%.16lf\n",exp(1.0));
> }
>
> drkir...@kestrel:~$ gcc exp.c
> drkir...@kestrel:~$ ./a.out
> 2.7182818284590451
> drkir...@kestrel:~$ /opt/sunstudio12.1/bin/cc -lm exp.c
> drkir...@kestrel:~$ ./a.out
> 2.7182818284590455
>
> Now, when I do this on Open Solaris, I get the same result with each
> compiler.
>
> bash-3.2$ uname -a
> SunOS hawk 5.11 snv_111b i86pc i386 i86pc
> bash-3.2$ gcc exp.c
> bash-3.2$ ./a.out
> 2.7182818284590451
> bash-3.2$ /opt/sunstudio12.1/bin/cc -lm exp.c
> bash-3.2$ ./a.out
> 2.7182818284590451
>
> I also tried this on HP-UX, and get the same (correct) result with
> both the
> native HP compiler and with gcc.
>
> -bash-4.0$ uname -a
> HP-UX hpbox B.11.11 U 9000/785 2016698240 unlimited-user license
> -bash-4.0$ gcc exp.c
> -bash-4.0$ ./a.out
> 2.7182818284590451
> -bash-4.0$ cc -lm exp.c
> -bash-4.0$ ./a.out
> 2.7182818284590451
>
> IMHO, this should not be covered up by reducing the number of digits
> compared,
> but recorded as a failure. Many packages have 'expected failures'.
> It would be
> better if this was recorded as an 'expected failure'. I appreciate
> that might
> not be how the doctests work now.
Given the above, and the fact that we're looking at exp(1) and math.e,
I'm also starting to lean towards the fact that this should be correct
on every system, and we've uncovered a bug of some sort.
- 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
