Robert Bradshaw wrote: > 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?)
There's a semi-stable release of Sage at: /rootpool2/local/kirkby/sage-4.3 ) I call it semi-stable, as I do occasionally make changes that might break it temporarily, but I always put it back to a working Sage. However, there is also http://t2nb.math.washington.edu:8000/ which has Sage 4.3. That is a Solaris zone on the host t2. If you want your own copy on 't2' which you can recompile easily, I could give you one. I have a tar file on the zone 't2nb' which has both the source and binaries of a complete stable version. I could copy that somewhere and make it available if you want. (It's the tarball I used to copy Sage into the zone). >> 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 What I find odd is the fact that gcc gets it right with my noddy C program. But when that gcc is used to build Sage, we find that Sage gets the same answer as Sun Studio. One might suggest a different library might be used, but both gcc and Sun Studio link against the same 3 libraries. ir...@t2:[~] $ /opt/SUNWspro/bin/cc -lm exp.c kir...@t2:[~] $ ldd a.out libm.so.2 => /lib/libm.so.2 libc.so.1 => /lib/libc.so.1 /platform/SUNW,T5240/lib/libc_psr.so.1 kir...@t2:[~] $ gcc exp.c kir...@t2:[~] $ ldd a.out libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,T5240/lib/libc_psr.so.1 kir...@t2:[~] $ I do not know if there is any significance in the fact that ldd shows libm before libc when built with the Sun compiler but swaps them when built with gcc. There's no implementation of 'exp' in libc, as the following shows. kir...@t2:[~] $ /opt/SUNWspro/bin/cc exp.c Undefined first referenced symbol in file exp exp.o ld: fatal: Symbol referencing errors. No output written to a.out I'm certainly against coving this up just now at least. Dave -- 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
