9220
Comment: Add comment about potential work around for pow()
|
9665
add fix for Sympow on Solaris x86 and amd64
|
Deletions are marked like this. | Additions are marked like this. |
Line 214: | Line 214: |
=== sympow FPU 53 bit control word setup === Sympow only works when the FPU control word is set to 53 bit rounding precision. The following code is a x86 compatible version of fpu.c of Sympow: {{{ void fpu_53bits() { printf("Setting cpu control word\n"); unsigned short _ncw = (0x027f); __asm__ __volatile__ ("fldcw %0" : : "m" (*&_ncw)); } }}} Note that this needs to be guarded by the usual flags for x86 and amd64 Solaris. |
Sage 3.2.3 on Solaris x86 build notes
Build Issues
- numpy's root finding code segfaults when linked against ATLAS - no solution yet, but as a workaround build numpy without ATLAS support
- spkg-install in jmol is borken - a fix is coming
- gnucrypot 1.4.0 needs too much entropy at startup - an upgrade to 1.4.3 fixes that. From the release notes of version 1.4.1 (2008-04-25):
* Fixed a bug introduced by 1.3.1 which led to the comsumption of far too much entropy for the intial seeding.
Fixes
sage-native-execute is using bashism
diff -r 396119818b99 sage-native-execute --- a/sage-native-execute Fri Jan 02 14:18:47 2009 -0800 +++ b/sage-native-execute Thu Jan 08 03:15:44 2009 -0500 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/usr/bin/env bash export LD_LIBRARY_PATH=$SAGE_ORIG_LD_LIBRARY_PATH if [ `uname` = 'Darwin' ]; then
interface/singular.py pexpect hangs
Singular seems to be limited to about 180 characters via the pexpect interface. Applying this patch works around that limitation by using the file interface:
diff -r e69ceb84399b sage/interfaces/singular.py --- a/sage/interfaces/singular.py Fri Jan 02 23:01:05 2009 -0500 +++ b/sage/interfaces/singular.py Sat Jan 10 13:29:09 2009 -0500 @@ -316,7 +316,7 @@ restart_on_ctrlc = True, verbose_start = False, logfile = logfile, - eval_using_file_cutoff=1000) + eval_using_file_cutoff=100) self.__libs = [] self._prompt_wait = prompt self.__to_clear = [] # list of variable names that need to be cleared.
NaN vs. nan and Infinity vs. inf in real_double.pyx
********************************************************************** File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/real_double.pyx", line 1311: sage: RDF(0).log() Expected: -inf Got: -Infinity ********************************************************************** File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/real_double.pyx", line 1313: sage: RDF(-1).log() Expected: nan Got: -NaN
This is fixed by the following patch since we now rely on GSL again instead of the underlying libc representation:
diff -r e69ceb84399b sage/rings/real_double.pyx --- a/sage/rings/real_double.pyx Fri Jan 02 23:01:05 2009 -0500 +++ b/sage/rings/real_double.pyx Sat Jan 10 19:05:27 2009 -0500 @@ -1283,9 +1283,9 @@ cdef _log_base(self, double log_of_base): if self._value < 2: if self._value == 0: - return -1./0 + return RDF(-1)/RDF(0) if self._value < 0: - return 0./0 + return RDF(0)/RDF(0) _sig_on a = self._new_c(gsl_sf_log_1plusx(self._value - 1) / log_of_base) _sig_off
nan vs. NaN in complex_double.pyx
********************************************************************** File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/complex_double.pyx", line 895: sage: ~(0*CDF(0,1)) Expected: nan + nan*I Got: -NaN + NaN*I **********************************************************************
The following terrible hack fixes that problem:
diff -r e69ceb84399b sage/rings/complex_double.pyx --- a/sage/rings/complex_double.pyx Fri Jan 02 23:01:05 2009 -0500 +++ b/sage/rings/complex_double.pyx Sat Jan 10 19:30:41 2009 -0500 @@ -789,7 +789,8 @@ s = s+"%s*I"%y if len(s) == 0: s = "0" - return s + s_clean=s.replace("NaN","nan").replace("-nan","nan") + return s_clean def _latex_(self): """
Numerical noise in sage/rings/qqbar.py
[4:36pm] mabs: cwitty: I have another interesting bug for you: [4:36pm] mabs: File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/qqbar.py", line 3826: [4:36pm] mabs: sage: cp.complex_roots(30, 1) [4:36pm] mabs: Expected: [4:36pm] mabs: [1.189207115002721?, [4:36pm] mabs: -1.189207115002721?, [4:36pm] mabs: 1.189207115002721?*I, [4:36pm] mabs: -1.189207115002721?*I] [4:36pm] mabs: Got: [4:36pm] mabs: [1.189207115002721?, -1.189207115002722?, 1.189207115002721?*I, -1.189207115002721?*I] [4:37pm] mabs: Notice that the second and third entries are different? [4:37pm] mabs: Ehh, the second only [4:38pm] cwitty: Yes. It's probably not a bug; complex_roots doesn't guarantee to find the tightest possible interval, and it depends on ATLAS which doesn't guarantee identical results. [4:38pm] mabs: ok [4:38pm] mabs: Should I use "..." then? [4:38pm] cwitty: Yes.
Here is a patch for the qqbar.py issue with a little explanation:
diff -r e69ceb84399b sage/rings/qqbar.py --- a/sage/rings/qqbar.py Fri Jan 02 23:01:05 2009 -0500 +++ b/sage/rings/qqbar.py Sat Jan 10 19:47:10 2009 -0500 @@ -3823,9 +3823,13 @@ EXAMPLES: sage: x = polygen(ZZ) sage: cp = AA.common_polynomial(x^4 - 2) + + Note that the precision is not guaraneteed to find the tightest possible interval + since complex_roots() depends on the underlying BLAS implementation. + sage: cp.complex_roots(30, 1) [1.189207115002721?, - -1.189207115002721?, + -1.18920711500272...?, 1.189207115002721?*I, -1.189207115002721?*I] """
- Other fixes to the Sage library: 3.2.3.final-solaris-fixes.patch, 3.2.3.final-solaris-getrusage-.patch
Doctest Failures
- More details coming soon - about 30 doctests failed, but about 15 to 20 are fixable with little effort
axes.py: name 'NaN' is not defined
We are seeing two doctest failures in
- sage -t "devel/sage/sage/coding/code_bounds.py"
- sage -t "devel/sage/sage/plot/plot.py"
File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/plot/plot.py", line 1557: sage: plot(x^(1/3), (x,-1,1)) Exception raised: Traceback (most recent call last): File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/ncadoctest.py", line 1231, in run_one_test self.run_one_example(test, example, filename, compileflags) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/sagedoctest.py", line 38, in run_one_example OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/ncadoctest.py", line 1172, in run_one_example compileflags, 1) in test.globs File "<doctest __main__.example_36[33]>", line 1, in <module> plot(x**(Integer(1)/Integer(3)), (x,-Integer(1),Integer(1)))###line 1557: sage: plot(x^(1/3), (x,-1,1)) File "sage_object.pyx", line 92, in sage.structure.sage_object.SageObject.__repr__ (sage/structure/sage_object.c:1082) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 712, in _repr_ self.show() File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 1066, in show hgridlinesstyle=hgridlinesstyle) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 1317, in save xmin, xmax, ymin, ymax = sage_axes.add_xy_axes(subplot, xmin, xmax, ymin, ymax) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 325, in add_xy_axes x_axis_ypos, ystep, ytslminor, ytslmajor = self._find_axes(ymin, ymax) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 241, in _find_axes tslmajor, oppaxis, step = self._tasteful_ticks(minval, maxval) File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 131, in _tasteful_ticks d0 = eval(sl[0]) File "<string>", line 1, in <module> NameError: name 'NaN' is not defined
The following code snippet illustrates the problem:
#include "stdio.h" #include "math.h" int main () { printf("pow: %d\n",pow(-0.5, 0.33333)); }
It returns 1 on Linux, 0 on Solaris - see "man pow" on Solaris 10:
These functions compute the value of x raised to the power y, x**y. If x is negative, y must be an integer value.
Thanks to Carl Witty for helping this track down.
Note that a potential solution to this problem is to check out what python does for pow().
sympow FPU 53 bit control word setup
Sympow only works when the FPU control word is set to 53 bit rounding precision. The following code is a x86 compatible version of fpu.c of Sympow:
void fpu_53bits() { printf("Setting cpu control word\n"); unsigned short _ncw = (0x027f); __asm__ __volatile__ ("fldcw %0" : : "m" (*&_ncw)); }
Note that this needs to be guarded by the usual flags for x86 and amd64 Solaris.
Other Annoyances
- -sdist as well as -bdist is seriously broken with BSD-ish shell utils installed in the default path on Solaris