691
Comment: initial version: notes from recollection
|
9751
fix gnucrypot issue, spelling fixes, move things around
|
Deletions are marked like this. | Additions are marked like this. |
Line 6: | Line 6: |
* 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. }}} * sage-native-execute is using bashism == Doctest Failures == * coming soon - about 30 doctests failed, but about 15 to 20 are fixable with little effort |
* spkg-install in jmol is broken - a fix is coming == Fixes == === Upgrade gnucrypt to 1.4.3 release to fix entropy issue === gnucrypt 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. }}} === 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 === 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. == Doctest Failures/Leads for other Bugs == * 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(). == Other Annoyances == * -sdist as well as -bdist is seriously broken with BSD-ish shell utils installed in the default path on 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 broken - a fix is coming
Fixes
Upgrade gnucrypt to 1.4.3 release to fix entropy issue
gnucrypt 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.
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
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.
Doctest Failures/Leads for other Bugs
- 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().
Other Annoyances
- -sdist as well as -bdist is seriously broken with BSD-ish shell utils installed in the default path on Solaris