Sage 3.2.3 on Solaris x86 build notes

Build Issues

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]
         """

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

axes.py: name 'NaN' is not defined

We are seeing two doctest failures in

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