18447
Comment: add another patch
|
17200
Correct sympow problem due to manual installation
|
Deletions are marked like this. | Additions are marked like this. |
Line 192: | Line 192: |
* make x86 check independent of Linux * -O3 to -O1 seems to core dump on Solaris, -O0 seems to work * missing data are required - compare #4422 0 this is strange and might indicate a bug in sympow's data conversion routines: |
* make x86 check independent of Linux or add Solaris/x86 specific fpu.c section * -O3 to -O1 seems to core dump on Solaris/x86, -O0 seems to work |
Line 200: | Line 199: |
}}} Strangely I have [re?]create a lot of data to get the above doctests to pass: {{{ sympow -new_data 2 sympow -new_data 1d0 sympow -new_data 1d1 sympow -new_data 1d2 sympow -new_data 1d3 sympow -new_data 1d4 sympow -new_data 1d5 sympow -new_data 1d6 sympow -new_data 1d7 }}} One example error message: {{{ sage: sympow.analytic_rank(EllipticCurve([1, -1, 0, -79, 289])) sympow 1.018 RELEASE (c) Mark Watkins --- see README and COPYING for details Minimal model of curve is [1,-1,0,-79,289] At 2: Inertia Group is C1 MULTIPLICATIVE REDUCTION At 117223: Inertia Group is C1 MULTIPLICATIVE REDUCTION Conductor is 234446 sp 1: Conductor at 2 is 1+0, root number is 1 sp 1: Euler factor at 2 is 1+1*x sp 1: Conductor at 117223 is 1+0, root number is -1 sp 1: Euler factor at 117223 is 1-1*x 1st sym power conductor is 234446, global root number is 1 NT 1d0: 1064 Maximal number of terms is 1064 Done with small primes 1049 L(E,1) appears to be zero 8.96886e-13 NT 1d2: 702 Done with small primes 1049 L''(E,1) appears to be zero 6.26609e-14 **ERROR** P014 not found in param_data file It can be added with sympow('-new_data 1d4') |
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
- scipy's special functions like Ei(10) cause segfaults. This might also be Solaris vs. ATLAS related.
- spkg-install in jmol is broken - a fix is coming
Fixes
Here are some patches for the fixes below:
3.2.3.final-solaris-ell_rational_field.py-noise.patch (fixes the numerical noise issue)
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.
William commented in IRC:
[9:28pm] wstein: mabs -- that singular pexpect fix -- you should make it only happen on solaris. [9:28pm] mabs: yes [9:28pm] wstein: Since there could be a big performance impact on other systems. [9:28pm] wstein: I would do that by writing [9:28pm] wstein: eval_using_file_cutoff=None [9:28pm] mabs: I just put up dirty fixes on the wiki page [9:28pm] wstein: then in the first line of code set it. [9:28pm] wstein: Or use [9:28pm] wstein: eval_using_file_cutoff=100 if is_solaris else 1000 [9:29pm] wstein: where is_solaris is whatever code says it's solaris.
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. The complete list of fixes required:
- add i86pc
- make x86 check independent of Linux or add Solaris/x86 specific fpu.c section
- -O3 to -O1 seems to core dump on Solaris/x86, -O0 seems to work
This fixes two doctests:
sage -t "devel/sage/sage/modular/abvar/abvar.py" sage -t "devel/sage/sage/lfunctions/sympow.py"
Numerical Noise in point counting code (schemes/elliptic_curves/ell_rational_field.py)
The problem is that the inital bound is different:
< initial bound 2.62270974833656e117 --- > initial bound 2.62270974833657e117
In its full glory:
sage -t "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" ********************************************************************** File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py", line 4640: sage: a=E.S_integral_points(S=[2,3], mw_base=[P1,P2,P3], verbose=True);a Expected: max_S: 3 len_S: 3 len_tors: 1 lambda 0.485997517468... k1,k2,k3,k4 6.68597129142710e234 1.31952866480763 3.31908110593519e9 2.42767548272846e17 mw_base [(1 : -1 : 1), (2 : 0 : 1), (0 : -3 : 1)] mw_base_log [0.667789378224099, 0.552642660712417, 0.818477222895703] mp [5, 7] mw_base_p_log [[2^2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^14 + 2^15 + 2^18 + 2^19 + O(2^20), 2^2 + 2^3 + 2^5 + 2^6 + 2^9 + 2^11 + 2^12 + 2^14 + 2^15 + 2^16 + 2^18 + O(2^20), 2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^11 + 2^12 + 2^13 + 2^16 + 2^17 + 2^19 + O(2^20)], [2*3^2 + 2*3^5 + 2*3^6 + 2*3^7 + 3^8 + 3^9 + 2*3^10 + 3^12 + 2*3^14 + 3^15 + 3^17 + 2*3^19 + O(3^20), 2*3 + 2*3^2 + 2*3^3 + 2*3^4 + 2*3^6 + 2*3^7 + 2*3^8 + 3^10 + 2*3^12 + 3^13 + 2*3^14 + 3^15 + 3^18 + O(3^20), 3 + 3^2 + 2*3^3 + 3^6 + 2*3^7 + 2*3^8 + 3^9 + 2*3^11 + 2*3^12 + 2*3^13 + 3^15 + 2*3^16 + 3^18 + 2*3^19 + O(3^20)]] k5,k6,k7 0.321154513240... 1.55246328915... 0.161999172489... initial bound 2.62270974833657e117 bound_list [58, 58, 58] bound_list [8, 9, 9] bound_list [8, 7, 7] bound_list [8, 7, 7] starting search of points using coefficient bound 8 x-coords of S-integral points via linear combination of mw_base and torsion: [-3, -26/9, -8159/2916, -2759/1024, -151/64, -1343/576, -2, -7/4, -1, -47/256, 0, 1/4, 4/9, 9/16, 58/81, 7/9, 6169/6561, 1, 17/16, 2, 33/16, 172/81, 9/4, 25/9, 3, 31/9, 4, 25/4, 1793/256, 8, 625/64, 11, 14, 21, 37, 52, 6142/81, 93, 4537/36, 342, 406, 816, 207331217/4096] starting search of extra S-integer points with absolute value bounded by 3.89321964979420 x-coords of points with bounded absolute value [-3, -2, -1, 0, 1, 2] Total number of S-integral points: 43 [(-3 : 0 : 1), (-26/9 : 28/27 : 1), (-8159/2916 : 233461/157464 : 1), (-2759/1024 : 60819/32768 : 1), (-151/64 : 1333/512 : 1), (-1343/576 : 36575/13824 : 1), (-2 : 3 : 1), (-7/4 : 25/8 : 1), (-1 : 3 : 1), (-47/256 : 9191/4096 : 1), (0 : 2 : 1), (1/4 : 13/8 : 1), (4/9 : 35/27 : 1), (9/16 : 69/64 : 1), (58/81 : 559/729 : 1), (7/9 : 17/27 : 1), (6169/6561 : 109871/531441 : 1), (1 : 0 : 1), (17/16 : -25/64 : 1), (2 : 0 : 1), (33/16 : 17/64 : 1), (172/81 : 350/729 : 1), (9/4 : 7/8 : 1), (25/9 : 64/27 : 1), (3 : 3 : 1), (31/9 : 116/27 : 1), (4 : 6 : 1), (25/4 : 111/8 : 1), (1793/256 : 68991/4096 : 1), (8 : 21 : 1), (625/64 : 14839/512 : 1), (11 : 35 : 1), (14 : 51 : 1), (21 : 95 : 1), (37 : 224 : 1), (52 : 374 : 1), (6142/81 : 480700/729 : 1), (93 : 896 : 1), (4537/36 : 305425/216 : 1), (342 : 6324 : 1), (406 : 8180 : 1), (816 : 23309 : 1), (207331217/4096 : 2985362173625/262144 : 1)] Got: max_S: 3 len_S: 3 len_tors: 1 lambda 0.485997517468082 k1,k2,k3,k4 6.68597129142710e234 1.31952866480763 3.31908110593519e9 2.42767548272846e17 mw_base [(1 : -1 : 1), (2 : 0 : 1), (0 : -3 : 1)] mw_base_log [0.667789378224099, 0.552642660712417, 0.818477222895703] mp [5, 7] mw_base_p_log [[2^2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^14 + 2^15 + 2^18 + 2^19 + O(2^20), 2^2 + 2^3 + 2^5 + 2^6 + 2^9 + 2^11 + 2^12 + 2^14 + 2^15 + 2^16 + 2^18 + O(2^20), 2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^11 + 2^12 + 2^13 + 2^16 + 2^17 + 2^19 + O(2^20)], [2*3^2 + 2*3^5 + 2*3^6 + 2*3^7 + 3^8 + 3^9 + 2*3^10 + 3^12 + 2*3^14 + 3^15 + 3^17 + 2*3^19 + O(3^20), 2*3 + 2*3^2 + 2*3^3 + 2*3^4 + 2*3^6 + 2*3^7 + 2*3^8 + 3^10 + 2*3^12 + 3^13 + 2*3^14 + 3^15 + 3^18 + O(3^20), 3 + 3^2 + 2*3^3 + 3^6 + 2*3^7 + 2*3^8 + 3^9 + 2*3^11 + 2*3^12 + 2*3^13 + 3^15 + 2*3^16 + 3^18 + 2*3^19 + O(3^20)]] k5,k6,k7 0.321154513240167 1.55246328915541 0.161999172489361 initial bound 2.62270974833656e117 bound_list [58, 58, 58] bound_list [8, 9, 9] bound_list [8, 7, 7] bound_list [8, 7, 7] starting search of points using coefficient bound 8 x-coords of S-integral points via linear combination of mw_base and torsion: [-3, -26/9, -8159/2916, -2759/1024, -151/64, -1343/576, -2, -7/4, -1, -47/256, 0, 1/4, 4/9, 9/16, 58/81, 7/9, 6169/6561, 1, 17/16, 2, 33/16, 172/81, 9/4, 25/9, 3, 31/9, 4, 25/4, 1793/256, 8, 625/64, 11, 14, 21, 37, 52, 6142/81, 93, 4537/36, 342, 406, 816, 207331217/4096] starting search of extra S-integer points with absolute value bounded by 3.89321964979420 x-coords of points with bounded absolute value [-3, -2, -1, 0, 1, 2] Total number of S-integral points: 43 [(-3 : 0 : 1), (-26/9 : 28/27 : 1), (-8159/2916 : 233461/157464 : 1), (-2759/1024 : 60819/32768 : 1), (-151/64 : 1333/512 : 1), (-1343/576 : 36575/13824 : 1), (-2 : 3 : 1), (-7/4 : 25/8 : 1), (-1 : 3 : 1), (-47/256 : 9191/4096 : 1), (0 : 2 : 1), (1/4 : 13/8 : 1), (4/9 : 35/27 : 1), (9/16 : 69/64 : 1), (58/81 : 559/729 : 1), (7/9 : 17/27 : 1), (6169/6561 : 109871/531441 : 1), (1 : 0 : 1), (17/16 : -25/64 : 1), (2 : 0 : 1), (33/16 : 17/64 : 1), (172/81 : 350/729 : 1), (9/4 : 7/8 : 1), (25/9 : 64/27 : 1), (3 : 3 : 1), (31/9 : 116/27 : 1), (4 : 6 : 1), (25/4 : 111/8 : 1), (1793/256 : 68991/4096 : 1), (8 : 21 : 1), (625/64 : 14839/512 : 1), (11 : 35 : 1), (14 : 51 : 1), (21 : 95 : 1), (37 : 224 : 1), (52 : 374 : 1), (6142/81 : 480700/729 : 1), (93 : 896 : 1), (4537/36 : 305425/216 : 1), (342 : 6324 : 1), (406 : 8180 : 1), (816 : 23309 : 1), (207331217/4096 : 2985362173625/262144 : 1)] **********************************************************************
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 three doctest failures in
- sage -t "devel/sage/sage/symbolic/expression.pyx"
- 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