Differences between revisions 11 and 12
Revision 11 as of 2009-01-11 05:05:59
Size: 9220
Comment: Add comment about potential work around for pow()
Revision 12 as of 2009-01-11 06:47:24
Size: 9665
Comment: 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