[sage-release] Sage 4.4.alpha0 released

8 views
Skip to first unread message

John Palmieri

unread,
Apr 16, 2010, 11:44:22 PM4/16/10
to sage-r...@googlegroups.com, sage-...@googlegroups.com
This alpha release of Sage incorporates about 90 tickets fixed since
version 4.3.5.

Source tarball:

http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0.tar

sage.math binary:

http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0-sage.math.washington.edu-x86_64-Linux.tar.gz

Upgrade path:

http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0/

---------------------------

Known issues:

* There are a few warnings when building the reference manual. These
need to be fixed before the final version of 4.4 is released.

* I was unable to build this on t2.math (Solaris), but then I've never
successfully built Sage on any Solaris machine. I'd be happy to hear
any advice about that.

* All tests pass on several non-Solaris machines, though.

Please test and report all issues.

---------------------------

Closed tickets:

#5134: Polyhedron: conversion from V-form to H-form fails if no
extreme point is given
#6020: bug in delta_qexp over finite fields
#6917: Minkowsky sum should work with polyhedra and not only with polytopes

Merged in sagenb:

(nothing)

Merged in sage-4.4.alpha0:

#261: Mike Hansen: a new matrix constructor: add lambda support
[Reviewed by Alec Mihailovs]
#598: Mike Hansen: implement substitute for monoids [Reviewed by Paul
Zimmermann]
#3852: David Ackerman, William Stein: create or adapt or include a
units package [Reviewed by Dan Drake]
#3863: Golam Mortuza Hossain, Burcin Erocal: Have numerical evaluation
of unevaluated integrals call numerical integral [Reviewed by Dan
Drake]
#4509: Jason Grout: doctests for planarity code [Reviewed by Tom
Boothby, Minh Van Nguyen]
#4756: Rob Beezer: eigenmatrix_right totally broken [Reviewed by Alex Ghitza]
#5165: Alex Ghitza: make padded_list use prec by default [Reviewed by
David Loeffler]
#6214: Volker Braun: Polyhedra compute incorrect dimension when
defined through inequalities [Reviewed by Marshall Hampton]
#6390: John Cremona: Implement elliptic logarithms (complex case)
[Reviewed by Chris Wuthrich]
#6671: Martin Raum: Speed of Victor Miller basis [Reviewed by David Loeffler]
#6781: Nils Bruin: Library access to ecl [Reviewed by Burcin Erocal,
Karl-Dieter Crisman, Nils Bruin]
#6836: Lloyd Kilford, Alex Ghitza: The Sturm bound for modular forms
gives the wrong result sometimes [Reviewed by David Loeffler]
#6955: John Cremona: update simon denis pari-scripts [Reviewed by
Chris Wuthrich]
#7288: Nathann Cohen: Gomory-Hu Trees [Reviewed by Alexandre Blondin Massé]
#7311: Nathann Cohen: Improve the add_constraint method from
MixedIntegerLinearProgram [Reviewed by Alexandre Blondin Massé]
#7538: Florent Hivert, Nicolas Borie: equality of posets is broken !
[Reviewed by Andrey Novoseltsev]
#7549: Mitesh Patel: Reference manual: class hierarchy, inherited
members, underscore variables [Reviewed by John Palmieri]
#7555: Rob Beezer, Nicolas M. Thiéry: Fix Cayley tables, add operation
tables [Reviewed by Nicolas M. Thiéry, Jason Grout]
#7569: Nathann Cohen: random_vertex and random_edge functions
[Reviewed by Alexandre Blondin Massé]
#7661: Burcin Erocal: maxima interface gives precedence to function
dictionary instead of local variables [Reviewed by Robert Mařík]
#7748: Flavia Stan, Burcin Erocal: Make incomplete gamma function
symbolic [Reviewed by Paul Zimmermann]
#7805: Nathann Cohen: MixedIntegerLinearProgram.show should use the
constraints' names [Reviewed by David Joyner]
#7880: David Roe: Category of sets with partial maps. [Reviewed by
Robert Bradshaw, David Loeffler]
#7914: Jason Bandlow: Implementation of triangular morphisms for
modules with basis [Reviewed by Nicolas M. Thiéry]
#8018: Rob Beezer: Eigenvalues sorted, but not eigenvectors, in
modular/modform/numerical.py [Reviewed by Alex Ghitza]
#8071: Rob Beezer: Trivial kernel of a matrix over non-fields are
broken [Reviewed by Martin Albrecht]
#8133: Chris Wuthrich: changing the string representation of Dirichlet
charachters [Reviewed by John Cremona]
#8218: David Roe: Finite Field move [Reviewed by David Loeffler]
#8242: Marc Mezzarobba: Fix duplicate citation warnings when building
the French-language tutorial [Reviewed by Paul Zimmermann, Minh Van
Nguyen]
#8281: Alex Ghitza: bug in hecke_operator_on_basis over finite fields
[Reviewed by David Loeffler]
#8297: Burcin Erocal: extra parenthesis when typesetting QQ arguments
to symbolic functions [Reviewed by Håkan Granath]
#8300: Robert Bradshaw: native algdep with proof option [Reviewed by
John Cremona]
#8313: Florent Hivert: Misplaced "`" in linear code construction
documentation [Reviewed by Minh Van Nguyen]
#8329: Ryan Hinton: Missing copy() method in BipartiteGraph [Reviewed
by Robert Miller]
#8330: Ryan Hinton: BipartiteGraph needs to override methods to add
and delete vertices and edges [Reviewed by Nathann Cohen]
#8332: David Roe: Changes FiniteField_givaro to Python [Reviewed by
David Loeffler, John Cremona]
#8344: Dmitrii Pasechnik: Factor constant polynomials over QQbar
[Reviewed by Paul Zimmermann, John Cremona]
#8366: Jason Grout: make contour plot labels and linestyles work when
fill=True [Reviewed by Robert Mařík]
#8390: Robert Mařík: Find all roots of a trigonometric equation
[Reviewed by William Stein]
#8404: Nathann Cohen: Computing a H-minor [Reviewed by Dmitrii Pasechnik]
#8417: Yann Laigle-Chapuy: improve CubeGraph and HyperStarGraph
generation [Reviewed by Robert Miller]
#8420: Valentin Feray: new feature : class of perfect matching
[Reviewed by Florent Hivert]
#8421: Ryan Hinton: Change BipartiteGraph .left and .right to sets
[Reviewed by Robert Miller]
#8424: Jason Grout: bounding box calculation doesn't handle NaN or
infinity [Reviewed by Robert Mařík]
#8428: Charlie Turner: Problem with rational_points over plane curves
AND addition of rational_points_iterator function [Reviewed by David
Roe]
#8429: Sébastien Labbé: Split word.py file into 4 files [Reviewed by
Alexandre Blondin Massé]
#8438: Florent Hivert: Construction of a skew partition from its row
and column lengths [Reviewed by Nicolas Borie]
#8444: Gonzalo Tornaria: Memleak in conversion for univariate
polynomial rings [Reviewed by Paul Zimmermann]
#8476: Martin Albrecht: return the correct class instance in
MPolynomialSystem.__copy__ [Reviewed by Yann Laigle-Chapuy]
#8481: John Palmieri: lift doesn't work for vector space homomorphisms
[Reviewed by William Stein]
#8484: Robert Miller: incremental improvements to prove_BSD [Reviewed
by John Cremona]
#8486: Kwankyu Lee: Xelatex and Sage notebook [Reviewed by Dan Drake,
John Palmieri]
#8487: Robert Mařík: Use use_grobner in to_poly_solve [Reviewed by Alex Ghitza]
#8502: John Cremona: evaluating multivariate polynomials yields
non-constant [Reviewed by Alex Ghitza]
#8504: Robert Bradshaw: AbelianGroup.exponent() uses GAP (slow)
[Reviewed by Mike Hansen]
#8506: Robert Bradshaw: Inefficient hash for homsets [Reviewed by John Cremona]
#8509: David Kirkby, John Palmieri: Ilegal 'grep -o' causes problems
installing optional packages on Solaris [Reviewed by Dmitrii
Pasechnik]
#8513: Alexandre Blondin Massé, Nathann Cohen: Including documentation
in the reference manual for some files related to graph theory
[Reviewed by Minh Van Nguyen, John Palmieri]
#8519: Nicolas Borie: Add a factory of finite/infinite enumerated set
(with categories) defines by Range(begin, end, step) [Reviewed by
Florent Hivert]
#8536: John Cremona: Change SAGE" to "Sage" in output [Reviewed by Dan Drake]
#8541: David Loeffler: Cyclotomic matrix multiplication bug [Reviewed
by William Stein]
#8543: Florent Hivert: EmptySet is Back ! TestSuite should allows for
empty sets. [Reviewed by Nicolas Borie, Nicolas M. Thiéry]
#8547: William Stein: implement hidden markov models in Cython from
scratch (so can remove the GHMM standard package from Sage) [Reviewed
by Marshall Hampton, Tom Boothby, Jason Grout]
#8560: Kwankyu Lee: magma interface should be changed to use
sage-native-execute [Reviewed by William Stein]
#8572: Florent Hivert: Doc of poset appear as void if called from the
console. [Reviewed by John Palmieri]
#8576: Nicolas M. Thiéry: Categories for QQ, CC, RR and friends
[Reviewed by John Cremona]
#8579: Nicolas M. Thiéry: Add the categories of magmas and additive
magmas [Reviewed by Robert Beezer, Florent Hivert]
#8580: Martin Albrecht: bug in matrix_mod2_dense (m4ri wrapper?):
exhibited by bug in coercing into a 0-dimensional qotient vector space
[Reviewed by William Stein]
#8584: David Loeffler: implement latex'ing of Dirichlet characters
[Reviewed by Chris Wuthrich]
#8595: Sébastien Labbé: Fixed point of word morphism is broken on some
tuple input [Reviewed by Vincent Delecroix]
#8599: Sébastien Labbé: Allow size as an argument for point2d
[Reviewed by Jason Grout]
#8600: Harald Schilly, Yann Laigle-Chapuy: fibonacci tree [Reviewed by
Robert Miller]
#8602: Gonzalo Tornaria: Implement theta series of degree 2 [Reviewed
by Alex Ghitza]
#8609: Andrey Novoseltsev: Switch AmbientSpace and Scheme to Parent
[Reviewed by John Cremona]
#8610: William Stein: fix caching bug in modular/modsym/element.pyx
(very easy to review!) [Reviewed by Alex Ghitza]
#8618: Sébastien Labbé: Fix is_identity of WordMorphism to handle non
standard alphabet [Reviewed by Vincent Delecroix]
#8620: David Loeffler: Rogue minus sign in
sage.modular.modsym.ambient.diamond_bracket_operator [Reviewed by
William Stein]
#8630: David Loeffler: Cusp forms constructor ignores the character
and returns enormous space [Reviewed by William Stein]
#8633: John Palmieri: remove more instances of 'texttt' from jsmath
output [Reviewed by Andrey Novoseltsev]
#8635: Paul Zimmermann: Typos in DisjointUnionEnumeratedSets.
[Reviewed by Florent Hivert]
#8636: William Stein: iconv -- put the "do not build check" in the
right place [Reviewed by John Palmieri]
#8638: John Palmieri: iconv -- make with SAGE_CHECK="yes" fails on
iconv with x86_64 ubuntu [Reviewed by Dan Drake, William Stein]
#8639: Nathann Cohen: Bug when defining a MIPVariable's type
[Reviewed by David Joyner]
#8647: William Stein: bump maxima artificially so upgrades aren't
*all* broken [Reviewed by Robert Mařík]
#8650: Marshall Hampton: Extreme faces of Polyhedra are inconsistent
[Reviewed by Andrey Novoseltsev]
#8666: Craig Citro, Robert Bradshaw: Bug in cyclotomic linear algebra
[Reviewed by Robert Bradshaw]
#8676: Minh Van Nguyen: document breadth-first and depth-first search
methods of C graph [Reviewed by Nathann Cohen]
#8679: John Palmieri: conventions for spkg names, rewriting sage-spkg
[Reviewed by William Stein, Dan Drake]
#8683: John Palmieri, Minh Van Nguyen: add randstate to the reference
manual [Reviewed by Minh Van Nguyen, John Palmieri]

Share and Enjoy.

--
You received this message because you are subscribed to the Google Groups "sage-release" group.
To post to this group, send email to sage-r...@googlegroups.com.
To unsubscribe from this group, send email to sage-release...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.

William Stein

unread,
Apr 17, 2010, 2:42:05 AM4/17/10
to sage-r...@googlegroups.com
On Fri, Apr 16, 2010 at 8:44 PM, John Palmieri <jhpalm...@gmail.com> wrote:
> This alpha release of Sage incorporates about 90 tickets fixed since
> version 4.3.5.
>
> Source tarball:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0.tar
>
> sage.math binary:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0-sage.math.washington.edu-x86_64-Linux.tar.gz
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4.alpha0/
>
> ---------------------------
>
> Known issues:
>
> * There are a few warnings when building the reference manual.  These
> need to be fixed before the final version of 4.4 is released.
>
> * I was unable to build this on t2.math (Solaris), but then I've never
> successfully built Sage on any Solaris machine.  I'd be happy to hear
> any advice about that.
>
> * All tests pass on several non-Solaris machines, though.
>
> Please test and report all issues.

I started trying to build on Solaris 10 x86_64 (fulvia), since it's a
Solaris 10 box and it's *FAST* (unlike T2). I ran into a failure
with libpng, which I haven't resolved yet. But when doing that, I
noticed that the libpng spkg is messed up -- there is an accidental
extra copy of libpng in there! Please see:

http://trac.sagemath.org/sage_trac/ticket/8700

It would be good to get this reviewed and in 4.4.

William


--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

davidloeffler

unread,
Apr 17, 2010, 10:47:13 AM4/17/10
to sage-release
Building the new alpha from scratch worked fine and all tests passed
(including long) on Ubuntu x86_64.

I also tried upgrading from 4.3.5, but that didn't work so well: the
Maxima build process halts and prompts me for various input, and
whatever I tell it to do it seems to fail shortly afterwards. Relevant
portion of the install.log below. Presumably this is related to

> #8647: William Stein: bump maxima artificially so upgrades aren't
> *all* broken [Reviewed by Robert Mařík]

...
config.status: creating demo/
Makefile
config.status: creating plotting/
Makefile
config.status: creating locale/
Makefile

Summary:
ECL enabled. Executable name: "ecl"
default lisp: ecl
wish executable name: "wish"
make[2]: Entering directory `/storage/masiao/sage-4.3.5/spkg/build/
maxima-5.20.1.p0/src'
Making all in
src
make[3]: Entering directory `/storage/masiao/sage-4.3.5/spkg/build/
maxima-5.20.1.p0/src/src'
test -d binary-ecl || mkdir binary-
ecl
ecl -norc -eval '(progn (load "../lisp-utils/defsystem.lisp") (funcall
(intern (symbol-name :operate-on-system) :mk)
"maxima" :compile :verbose t) (build-maxima-lib))' -eval
'(ext:quit)'
;;; Loading "/storage/masiao/sage-4.3.5/spkg/build/maxima-5.20.1.p0/
src/src/../lisp-utils/defsystem.lisp"
;;; Loading #P"/home/masiao/storage/sage-4.3.5/local/lib/ecl/
cmp.fas"
;;; Loading #P"/home/masiao/storage/sage-4.3.5/local/lib/ecl/
sysfun.lsp"
;;; Loading "/storage/masiao/sage-4.3.5/spkg/build/maxima-5.20.1.p0/
src/src/maxima.system"

; - Compiling defsystem "maxima"
; - Compiling module "package"
; - Compiling source file
; "/storage/masiao/sage-4.3.5/spkg/build/maxima-5.20.1.p0/src/
src/maxima-package.lisp"
;;; Compiling /storage/masiao/sage-4.3.5/spkg/build/maxima-5.20.1.p0/
src/src/maxima-package.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3,
Debug=2
;;; End of Pass
1.
;;; Note: Creating tag: "_eclFGkv5HJdeKquW_YXWo6Hz" for #P"binary-ecl/
maxima-package.o"
;;; Internal error: Unable to find include
directory
; - Binary file binary-ecl/maxima-package.fas is old or does not
exist.
; Compile (and load) source file /storage/masiao/sage-4.3.5/
spkg/build/maxima-5.20.1.p0/src/src/maxima-package.lisp instead?

John H Palmieri

unread,
Apr 17, 2010, 11:01:03 AM4/17/10
to sage-release
On Apr 16, 8:44 pm, John Palmieri <jhpalmier...@gmail.com> wrote:
> This alpha release of Sage incorporates about 90 tickets fixed since
> version 4.3.5.

On all of the linux skynet machines, this version built. Two machines
had doctest failures:

-------------------------------------------

cleo: (Red Hat itanium?)
Linux cleo 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:57:09 EST 2009 ia64
ia64 ia64 GNU/Linux

sage -t -long "devel/sage/sage/geometry/polyhedra.py"
**********************************************************************
File "/home/palmieri/cleo/sage-4.4.alpha0/devel/sage/sage/geometry/
polyhedra.py", line 3147:
sage: for lset in
polytopes.cross_polytope(2).face_lattice().level_sets(): print lset[0]
Expected:
(None, (0, 1, 2, 3))
((1,), (2, 3))
((1, 2), (3,))
((0, 1, 2, 3), None)
Got:
(None, (0, 1, 2, 3))
((0,), (1, 2))
((1, 2), (3,))
((0, 1, 2, 3), None)
**********************************************************************
1 items had failures:
1 of 7 in __main__.example_133
***Test Failed*** 1 failures.

-------------------------------------------

sextus: (Fedora)
Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux

sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
**********************************************************************
File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
matrix_double_dense.pyx", line 639:
sage: spectrum[0]
Expected:
(2.0, Vector space of degree 4 and dimension 1 over Real Double
Field
User basis matrix:
[0.5 0.5 0.5 0.5])
Got:
(2.0, Vector space of degree 4 and dimension 1 over Real Double
Field
User basis matrix:
[-0.5 -0.5 -0.5 -0.5])
**********************************************************************
File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
matrix_double_dense.pyx", line 794:
sage: spectrum[0]
Expected:
(2.0, [(0.5, 0.5, 0.5, 0.5)], 1)
Got:
(2.0, [(-0.5, -0.5, -0.5, -0.5)], 1)
**********************************************************************
File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
matrix_double_dense.pyx", line 796:
sage: spectrum[1]
Expected:
(1.0, [(-0.615457454897, -0.492365963917, -0.492365963917,
-0.369274472938)], 1)
Got:
(1.0, [(0.615457454897, 0.492365963917, 0.492365963917,
0.369274472938)], 1)
**********************************************************************
File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
matrix_double_dense.pyx", line 798:
sage: spectrum[2]
Expected:
(-2.0, [(-0.800640769025, -0.32025630761, -0.480384461415,
-0.160128153805)], 1)
Got:
(-2.0, [(0.800640769025, 0.32025630761, 0.480384461415,
0.160128153805)], 1)
**********************************************************************
2 items had failures:
1 of 10 in __main__.example_18
3 of 9 in __main__.example_21
***Test Failed*** 4 failures.
For whitespace errors, see the file /home/palmieri/.sage//
tmp/.doctest_matrix_double_dense.py
[4.8 s]

--
John

Rob Beezer

unread,
Apr 17, 2010, 1:42:57 PM4/17/10
to sage-release
On Apr 17, 7:47 am, davidloeffler <dave.loeff...@gmail.com> wrote:
> Building the new alpha from scratch worked fine and all tests passed
> (including long) on Ubuntu x86_64.

Sane here, but did not include long tests.

Tim Joseph Dumol

unread,
Apr 17, 2010, 1:54:28 PM4/17/10
to sage-r...@googlegroups.com
Same here (with long tests) for Arch x86_64
--
Tim Joseph Dumol <tim (at) timdumol (dot) com>
http://timdumol.com

Rob Beezer

unread,
Apr 17, 2010, 2:13:34 PM4/17/10
to sage-release
The doctest failures in {{{sage/matrix/matrix_double_dense.pyx}}}}
can be traced to the patch at #4756. They seem to be trivial in the
sense that the eigenvectors computed are just the negative of what the
test expects. Since tests are passing elsewhere, is this a Fedora
idiosyncrasy?

I've looked back over the patch and its purpose was to change how
results were packaged, to make the output more consistent with other
similar routines. The actual computations are done with
{{{scipy.linalg.eig()}}} and I don't believe any of that has changed.

Can anybody remind me quickly how to use a Fedora virtual machine on
boxen, or elsewhere? I could experiment further that way.

Rob

William Stein

unread,
Apr 17, 2010, 3:29:57 PM4/17/10
to sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 11:13 AM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> The doctest failures in  {{{sage/matrix/matrix_double_dense.pyx}}}}
> can be traced to the patch at #4756.  They seem to be trivial in the
> sense that the eigenvectors computed are just the negative of what the
> test expects.  Since tests are passing elsewhere, is this a Fedora
> idiosyncrasy?
>
> I've looked back over the patch and its purpose was to change how
> results were packaged, to make the output more consistent with other
> similar routines.  The actual computations are done with
> {{{scipy.linalg.eig()}}} and I don't believe any of that has changed.
>
> Can anybody remind me quickly how to use a Fedora virtual machine on
> boxen, or elsewhere?  I could experiment further that way.

It's very likely not fedora-specific but specific to the very new
hardware in sextus (the computer John P. used). You need an account
on skynet to get access (if you don't have one, write to me offlist).

The test should be rewritten in a way to allow for either sign, since
either is correct... or we should re-normalize all the numerical
eigenvectors so the first nonzero entry is 1. I like the idea to
normalize.
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

William Stein

unread,
Apr 17, 2010, 6:54:41 PM4/17/10
to sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 7:47 AM, davidloeffler <dave.l...@gmail.com> wrote:
> Building the new alpha from scratch worked fine and all tests passed
> (including long) on Ubuntu x86_64.
>
> I also tried upgrading from 4.3.5, but that didn't work so well: the
> Maxima build process halts and prompts me for various input, and


Hi,

I've created a system for automatically testing upgrades from most
previous 4.x series upgrades to sage-4.4.alpha0. I'll report on the
results later. Here it is in case anybody is curious:

http://sage.math.washington.edu/home/wstein/build/upgrade_test/

It's really just the file

http://sage.math.washington.edu/home/wstein/build/upgrade_test/tester.sage

Running this will henceforth be a standard part of release management.
This will hopefully improve
the reliability of source-based upgrades.

-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

John H Palmieri

unread,
Apr 17, 2010, 7:13:21 PM4/17/10
to sage-release
On Apr 17, 12:29 pm, William Stein <wst...@gmail.com> wrote:
> On Sat, Apr 17, 2010 at 11:13 AM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > The doctest failures in  {{{sage/matrix/matrix_double_dense.pyx}}}}
> > can be traced to the patch at #4756.  They seem to be trivial in the
> > sense that the eigenvectors computed are just the negative of what the
> > test expects.  Since tests are passing elsewhere, is this a Fedora
> > idiosyncrasy?
>
> > I've looked back over the patch and its purpose was to change how
> > results were packaged, to make the output more consistent with other
> > similar routines.  The actual computations are done with
> > {{{scipy.linalg.eig()}}} and I don't believe any of that has changed.
>
> > Can anybody remind me quickly how to use a Fedora virtual machine on
> > boxen, or elsewhere?  I could experiment further that way.
>
> It's very likely not fedora-specific but specific to the very new
> hardware in sextus (the computer John P. used).  You need an account
> on skynet to get access (if you don't have one, write to me offlist).

Yes, sorry, I wasn't as specific as I could have been. Doctests
passed completely on these skynet machines:

eno: (Fedora)
Linux eno 2.6.32.10-90.fc12.x86_64 #1 SMP Tue Mar 23 09:47:08 UTC 2010
x86_64 x86_64 x86_64 GNU/Linux

lena: (Fedora)
Linux lena 2.6.31.12-174.2.19.fc12.x86_64 #1 SMP Thu Feb 11 07:07:16
UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

menas: (Suse)
Linux menas 2.6.27.39-0.2-default #1 SMP 2009-11-23 12:57:38 +0100
x86_64 x86_64 x86_64 GNU/Linux

taurus: (Fedora)
Linux taurus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
2010 x86_64 x86_64 x86_64 GNU/Linux

cicero: (Fedora)
Linux cicero 2.6.32.10-90.fc12.i686.PAE #1 SMP Tue Mar 23 10:04:28 UTC
2010 i686 i686 i386 GNU/Linux

iras: (Suse)
Linux iras 2.6.16.46-0.12-default #1 SMP Thu May 17 14:00:09 UTC 2007
ia64 ia64 ia64 GNU/Linux

(The only failures were the two that I reported, which makes me pretty
happy. I'm checking whether the failure on cleo is new or whether it
was there with 4.3.5 -- I don't know if we've done any testing on that
machine for any recent Sage releases.)

In particular, the failure doesn't occur with all Fedora boxes -- it's
particular to whatever hardware sextus is running.

Florent Hivert

unread,
Apr 17, 2010, 7:24:09 PM4/17/10
to sage-r...@googlegroups.com
Hi John,

> Yes, sorry, I wasn't as specific as I could have been. Doctests
> passed completely on these skynet machines:

Just to report that I also got a doctest complete pass on

massena-~ $ uname -a
Linux massena 2.6.23-gentoo-r6 #1 SMP Wed Feb 6 21:49:58 CET 2008 x86_64 Intel(R) Xeon(R) CPU X5365 @ 3.00GHz GenuineIntel GNU/Linux

Cheers,

Florent

David Joyner

unread,
Apr 17, 2010, 7:46:46 PM4/17/10
to sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 6:54 PM, William Stein <wst...@gmail.com> wrote:
> On Sat, Apr 17, 2010 at 7:47 AM, davidloeffler <dave.l...@gmail.com> wrote:
>> Building the new alpha from scratch worked fine and all tests passed
>> (including long) on Ubuntu x86_64.
>>
>> I also tried upgrading from 4.3.5, but that didn't work so well: the
>> Maxima build process halts and prompts me for various input, and
>
>
> Hi,
>
> I've created a system for automatically testing upgrades from most
> previous 4.x series upgrades to sage-4.4.alpha0.   I'll report on the
> results later.  Here it is in case anybody is curious:
>
> http://sage.math.washington.edu/home/wstein/build/upgrade_test/
>
> It's really just the file
>
>  http://sage.math.washington.edu/home/wstein/build/upgrade_test/tester.sage


IMHO this is a really nice addition to the overall structure of Sage
maintenance.
Message has been deleted

William Stein

unread,
Apr 17, 2010, 7:58:19 PM4/17/10
to Minh Nguyen, sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 4:55 PM, Minh Nguyen <nguye...@gmail.com> wrote:
> Hi William,
>
> On Sun, Apr 18, 2010 at 8:54 AM, William Stein <wst...@gmail.com> wrote:
>
> <SNIP>
>
>> I've created a system for automatically testing upgrades from most
>> previous 4.x series upgrades to sage-4.4.alpha0.
>
> I'm rather ashamed about this because as you recall, I promised to
> write such a script for testing upgrades.

No worries -- I had totally forgot you were going to do it, and it
only took me a little while (the entire thing is < 30 lines).

-- William

Nick Alexander

unread,
Apr 17, 2010, 8:58:13 PM4/17/10
to sage-r...@googlegroups.com
> The test should be rewritten in a way to allow for either sign, since
> either is correct... or we should re-normalize all the numerical
> eigenvectors so the first nonzero entry is 1. I like the idea to
> normalize.

This is hard to do. How do you uniformly normalize these vectors, and
other similar permutations?

(1e-100, 1)
(1e-10, 1)
(1e-1, 1)
(1e-100, 1e100)
(1e-10, 1e100)
(1e-1, 1e100)

Nick

William Stein

unread,
Apr 17, 2010, 9:11:08 PM4/17/10
to sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 5:58 PM, Nick Alexander <ncale...@gmail.com> wrote:
>> The test should be rewritten in a way to allow for either sign, since
>> either is correct... or we should re-normalize all the numerical
>> eigenvectors so the first nonzero entry is 1.  I like the idea to
>> normalize.
>
> This is hard to do.  How do you uniformly normalize these vectors, and other
> similar permutations?
>
> (1e-100, 1)

sage: a = vector(RDF,[1e-100, 1])
sage: a
(1e-100, 1.0)
sage: a/a[0]
(1.0, 1e+100)


> (1e-10, 1)
> (1e-1, 1)
> (1e-100, 1e100)

sage: a = vector(RDF,[1e-100, 1e100])
sage: a/a[0]
(1.0, 1e+200)

Etc.

> (1e-10, 1e100)
> (1e-1, 1e100)

This one would be bad though:

sage: a = vector(RDF,[1e-309, 1]); a
(1e-309, 1.0)
sage: a[0] != 0
True
sage: a/a[0]
(+infinity, +infinity)

I don't know if numpy produces numerical eigenvectors that look like
the above... But as a compromise we could at least adjust the
eigenvector so the first nonzero entry is positive, which would I
presume deal with the current issue.

-- William

Nick Alexander

unread,
Apr 17, 2010, 9:30:17 PM4/17/10
to sage-r...@googlegroups.com
It must produce such eigenvectors. There's no way to distinguish
"small" from "zero", numerically.

> But as a compromise we could at least adjust the
> eigenvector so the first nonzero entry is positive, which would I
> presume deal with the current issue.

I don't think this makes sense. If the first entry should really be
zero, the error is presumably randomly distributed around 0. So
sometimes you get

(1e-100, 1)

and sometimes you get

(-1e-100, 1)

and those two things will be normalized differently, although they
both "should" be (0, 1).

Nick

William Stein

unread,
Apr 17, 2010, 9:54:22 PM4/17/10
to sage-r...@googlegroups.com
If by "make sense" you mean "is canonical", then of course it isn't canonical.
Recall that the entire point of this discussion is to come up with some way of
dealing with this doctests:

sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
**********************************************************************
File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
matrix_double_dense.pyx", line 639:
sage: spectrum[0]
Expected:
(2.0, Vector space of degree 4 and dimension 1 over Real Double
Field
User basis matrix:
[0.5 0.5 0.5 0.5])
Got:
(2.0, Vector space of degree 4 and dimension 1 over Real Double
Field
User basis matrix:
[-0.5 -0.5 -0.5 -0.5])

> If the first entry should really be zero,
> the error is presumably randomly distributed around 0.  So sometimes you get
>
> (1e-100, 1)
>
> and sometimes you get
>
> (-1e-100, 1)
>
> and those two things will be normalized differently, although they both
> "should" be (0, 1).


>
> Nick
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-release...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-release?hl=en.
>
>



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Nick Alexander

unread,
Apr 17, 2010, 10:00:26 PM4/17/10
to sage-r...@googlegroups.com
And I'm saying that normalizing the first entry to be positive will
not accomplish that goal. If the first entry is tiny, then I assume
different architectures will return differently signed first entries,
and the normalization will fail.

In my own code, I have a "cap" function that sets to 0 tiny entries,
and then does the natural thing; for any particular test, it works
well. But I know no general solution.

Nick

> sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
> **********************************************************************
> File "/home/palmieri/sextus/sage-4.4.alpha0/devel/sage/sage/matrix/
> matrix_double_dense.pyx", line 639:
> sage: spectrum[0]
> Expected:
> (2.0, Vector space of degree 4 and dimension 1 over Real Double
> Field
> User basis matrix:
> [0.5 0.5 0.5 0.5])
> Got:
> (2.0, Vector space of degree 4 and dimension 1 over Real Double
> Field
> User basis matrix:
> [-0.5 -0.5 -0.5 -0.5])


Dima Pasechnik

unread,
Apr 17, 2010, 10:50:14 PM4/17/10
to sage-release


On Apr 18, 3:29 am, William Stein <wst...@gmail.com> wrote:
> On Sat, Apr 17, 2010 at 11:13 AM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > The doctest failures in  {{{sage/matrix/matrix_double_dense.pyx}}}}
> > can be traced to the patch at #4756.  They seem to be trivial in the
> > sense that the eigenvectors computed are just the negative of what the
> > test expects.  Since tests are passing elsewhere, is this a Fedora
> > idiosyncrasy?
>
> > I've looked back over the patch and its purpose was to change how
> > results were packaged, to make the output more consistent with other
> > similar routines.  The actual computations are done with
> > {{{scipy.linalg.eig()}}} and I don't believe any of that has changed.
>
> > Can anybody remind me quickly how to use a Fedora virtual machine on
> > boxen, or elsewhere?  I could experiment further that way.
>
> It's very likely not fedora-specific but specific to the very new
> hardware in sextus (the computer John P. used).  You need an account
> on skynet to get access (if you don't have one, write to me offlist).
>
> The test should be rewritten in a way to allow for either sign, since
> either is correct... or we should re-normalize all the numerical
> eigenvectors so the first nonzero entry is 1.  I like the idea to
> normalize.

no, this is a recipe for disaster. If the 1st nonzero entry is close
to 0, the division by it will
blow the big entries off.
Renormalize to have the 1st non-0 entry positive, OK. But no division,
please, unless really necessary.

Dima
> > For more options, visit this group athttp://groups.google.com/group/sage-release?hl=en.
>
> --
> William Stein
> Professor of Mathematics
> University of Washingtonhttp://wstein.org
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.

John H Palmieri

unread,
Apr 17, 2010, 11:09:40 PM4/17/10
to sage-release
On Apr 17, 8:01 am, John H Palmieri <jhpalmier...@gmail.com> wrote:
> On Apr 16, 8:44 pm, John Palmieri <jhpalmier...@gmail.com> wrote:
>
> > This alpha release of Sage incorporates about 90 tickets fixed since
> > version 4.3.5.
>
> On all of the linux skynet machines, this version built.  Two machines
> had doctest failures:
>
> -------------------------------------------
>
> cleo: (Red Hat itanium?)
> Linux cleo 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:57:09 EST 2009 ia64
> ia64 ia64 GNU/Linux
>
> sage -t -long "devel/sage/sage/geometry/polyhedra.py"

I opened ticket #8709 for this. (I don't know how to fix it, but I
cc'ed the people whose patch led to this.)

> sextus: (Fedora)
> Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
> 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"

Can someone open up a ticket for this one (and also fix it)?

Rob Beezer

unread,
Apr 17, 2010, 11:35:37 PM4/17/10
to sage-release
On Apr 17, 8:09 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
> > sextus: (Fedora)
> > Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
> > 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> > sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
>
> Can someone open up a ticket for this one (and also fix it)?

This is reported now at http://trac.sagemath.org/sage_trac/ticket/8710

Since I introduced these doctests, I feel some responsibility (just a
little bit), but am out of my league somewhat on these numerical
issues. So I really appreciate the discussion above that has happened
while I was out for a while, since I was ready to ask exactly these
same questions. ;-) So nobody should feel bashful at all about
taking this one on if interested.

I have a request in for an account on Skynet, and am curious to see
exactly what the behavior is for scipy there, so I may not do anything
until I've done those experiments.

Rob

William Stein

unread,
Apr 17, 2010, 11:48:50 PM4/17/10
to sage-r...@googlegroups.com
On Saturday, April 17, 2010, Rob Beezer <goo...@beezer.cotse.net> wrote:
> On Apr 17, 8:09 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
>> > sextus: (Fedora)
>> > Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
>> > 2010 x86_64 x86_64 x86_64 GNU/Linux
>>
>> > sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
>>
>> Can someone open up a ticket for this one (and also fix it)?
>
> This is reported now at http://trac.sagemath.org/sage_trac/ticket/8710
>
> Since I introduced these doctests, I feel some responsibility (just a
> little bit), but am out of my league somewhat on these numerical
> issues.  So I really appreciate the discussion above that has happened
> while I was out for a while, since I was ready to ask exactly these
> same questions.  ;-)  So nobody should feel bashful at all about
> taking this one on if interested.
>
> I have a request in for an account on Skynet, and am curious to see
> exactly what the behavior is for scipy there, so I may not do anything
> until I've done those experiments.

It could take week(s) to get that account, so these tests may have to
be removed for sage-4.4, which will be released this week.

>
> Rob
>
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>
>

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Dan Drake

unread,
Apr 17, 2010, 11:21:59 PM4/17/10
to sage-r...@googlegroups.com
On Sat, 17 Apr 2010 at 07:50PM -0700, Dima Pasechnik wrote:
> On Apr 18, 3:29 am, William Stein <wst...@gmail.com> wrote:
> > The test should be rewritten in a way to allow for either sign, since
> > either is correct... or we should re-normalize all the numerical
> > eigenvectors so the first nonzero entry is 1.  I like the idea to
> > normalize.
>
> no, this is a recipe for disaster. If the 1st nonzero entry is close
> to 0, the division by it will blow the big entries off. Renormalize
> to have the 1st non-0 entry positive, OK. But no division, please,
> unless really necessary.

I'm not necessarily arguing for normalization, but I recall that Matlab
normalizes eigenvectors to have length 1. It seems like that kind of
normalization won't behave badly when an entry is very tiny, since the
difference in length is correspondingly tiny.

Also, Matlab is very widely used for numerical mathematics, and has been
for a long time. If that kind of normalization was unstable, it's
probably unlikely that it would continue to be used. (Although IANANAE
-- I am not a numerical analysis expert.)

(I find it amusing that IANANAE contains "NAN"...)

Also, this discussion probably belongs on sage-devel, as it directly
concerns, well, development. :)

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

signature.asc

Dan Drake

unread,
Apr 17, 2010, 11:27:44 PM4/17/10
to sage-r...@googlegroups.com
With 4.4.alpha0, build succeeds with SAGE_CHECK=yes and all long tests
pass on 64-bit Ubuntu 9.04 and 9.10.
signature.asc

William Stein

unread,
Apr 18, 2010, 12:16:46 AM4/18/10
to sage-r...@googlegroups.com
On Sat, Apr 17, 2010 at 8:21 PM, Dan Drake <dr...@kaist.edu> wrote:
> On Sat, 17 Apr 2010 at 07:50PM -0700, Dima Pasechnik wrote:
>> On Apr 18, 3:29 am, William Stein <wst...@gmail.com> wrote:
>> > The test should be rewritten in a way to allow for either sign, since
>> > either is correct... or we should re-normalize all the numerical
>> > eigenvectors so the first nonzero entry is 1.  I like the idea to
>> > normalize.
>>
>> no, this is a recipe for disaster. If the 1st nonzero entry is close
>> to 0, the division by it  will blow the big entries off. Renormalize
>> to have the 1st non-0 entry positive, OK. But no division, please,
>> unless really necessary.
>
> I'm not necessarily arguing for normalization, but I recall that Matlab
> normalizes eigenvectors to have length 1. It seems like that kind of
> normalization won't behave badly when an entry is very tiny, since the
> difference in length is correspondingly tiny.

That's very interesting. Normalizing the length certainly makes more sense
than the normalization I proposed.

-- William

>
> Also, Matlab is very widely used for numerical mathematics, and has been
> for a long time. If that kind of normalization was unstable, it's
> probably unlikely that it would continue to be used. (Although IANANAE
> -- I am not a numerical analysis expert.)
>
> (I find it amusing that IANANAE contains "NAN"...)
>
> Also, this discussion probably belongs on sage-devel, as it directly
> concerns, well, development. :)
>
> Dan
>
> --
> ---  Dan Drake
> -----  http://mathsci.kaist.ac.kr/~drake
> -------
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvKetcACgkQr4V8SljC5Lq3+wCgyBiDnF5i7AZfMIaOb1e0NxFq
> UVcAoMbL7/T9UW3iirAyXKBC+fHOah+D
> =2sUr
> -----END PGP SIGNATURE-----

Robert Bradshaw

unread,
Apr 18, 2010, 12:20:16 AM4/18/10
to sage-r...@googlegroups.com
On Apr 17, 2010, at 8:35 PM, Rob Beezer wrote:

> On Apr 17, 8:09 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
>>> sextus: (Fedora)
>>> Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
>>> 2010 x86_64 x86_64 x86_64 GNU/Linux
>>
>>> sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
>>
>> Can someone open up a ticket for this one (and also fix it)?
>
> This is reported now at http://trac.sagemath.org/sage_trac/ticket/8710
>
> Since I introduced these doctests, I feel some responsibility (just a
> little bit), but am out of my league somewhat on these numerical
> issues. So I really appreciate the discussion above that has happened
> while I was out for a while, since I was ready to ask exactly these
> same questions. ;-) So nobody should feel bashful at all about
> taking this one on if interested.
>
> I have a request in for an account on Skynet, and am curious to see
> exactly what the behavior is for scipy there, so I may not do anything
> until I've done those experiments.

I'm jumping into this thread late, but it seems that for all the
examples it's just a difference of sign. How about just normalizing
the sign of the first (non-zero?) entry to be non-negative? That's
cheap and doesn't involve division, though of course non-canonical.

- Robert

Rob Beezer

unread,
Apr 18, 2010, 2:41:13 AM4/18/10
to sage-release
Based on the output from the failing tests, it seems these
eigenvectors have been scaled to length 1 already, which is a common
form for eigenvectors.

A thought about regularizing the output for the doctests. Put the
eigenvector into a matrix and ask for its echelon form. This would of
course be equivalent to William's suggestion that the leading non-zero
entry be a 1. But presumably, all the well-founded objections raised
by Nick and Dima would be handled carefully in the code for computing
echelon form.

I'm only proposing this for the doctests, not the code itself.
Correct me if I'm wrong, but maybe SciPy would desire standardized
output across architectures, and maybe the cause of the failures on
sextus at Skynet should be fixed upstream?

Rob

Kiran Kedlaya

unread,
Apr 18, 2010, 3:55:50 PM4/18/10
to sage-release
I still can't build cddlib on my mixed-platform Fedora 10 machine (64-
bit machine in a 32-bit NFS environment). Specifically, I hit this
error:

/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -L/usr/local/lib
-L/scratch/sage-4.4.alpha0/local/lib -o scdd_gmp simplecdd.o ../lib-
src-gmp/libcddgmp.la -lgmp
libtool: link: gcc -g -O2 -o .libs/scdd_gmp simplecdd.o -L/usr/local/
lib -L/scratch/sage-4.4.alpha0/local/lib ../lib-src-gmp/.libs/
libcddgmp.so /scratch/sage-4.4.alpha0/local/lib/libgmp.so /usr/local/
pkg/gmp-4.2.4/lib/libgmp.so -Wl,-rpath
-Wl,/scratch/sage-4.4.alpha0/local/lib -Wl,-rpath -Wl,/usr/local/pkg/
gmp-4.2.4/lib
/usr/local/pkg/gmp-4.2.4/lib/libgmp.so: could not read symbols: File
in wrong format

Can anyone explain why /usr/local/lib is in there? On this system,
that points to an NFS folder with 32-bit libraries. I have
LD_LIBRARY_PATH set globally to the correct value (/usr/lib:/usr/
lib64) but apparently libtool hasn't gotten the message.

If it helps, I suppose I could ask my sysadmin to add a link to libgmp
in /usr/lib (right now it's in /usr/lib64), but that hardly seems like
the most robust solution for this issue.

Kiran

On Apr 16, 11:44 pm, John Palmieri <jhpalmier...@gmail.com> wrote:
> This alpha release of Sage incorporates about 90 tickets fixed since
> version 4.3.5.
>
> Source tarball:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4...
>
> sage.math binary:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4...
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.4.alpha0/sage-4.4...
>
> ---------------------------
>
> Known issues:
>
> * There are a few warnings when building the reference manual.  These
> need to be fixed before the final version of 4.4 is released.
>
> * I was unable to build this on t2.math (Solaris), but then I've never
> successfully built Sage on any Solaris machine.  I'd be happy to hear
> any advice about that.
>
> * All tests pass on several non-Solaris machines, though.
>
> Please test and report all issues.
>
> ---------------------------
>
> Closed tickets:
>
> #5134: Polyhedron: conversion from V-form to H-form fails if no
> extreme point is given
> #6020: bug in delta_qexp over finite fields
> #6917: Minkowsky sum should work with polyhedra and not only with polytopes
>
> Merged in sagenb:
>
> (nothing)
>
> Merged in sage-4.4.alpha0:
>
> #261: Mike Hansen: a new matrix constructor: add lambda support
> [Reviewed by Alec Mihailovs]
> #598: Mike Hansen: implement substitute for monoids [Reviewed by Paul
> Zimmermann]
> #3852: David Ackerman, William Stein: create or adapt or include a
> units package [Reviewed by Dan Drake]
> #3863: Golam Mortuza Hossain, Burcin Erocal: Have numerical evaluation
> of unevaluated integrals call numerical integral [Reviewed by Dan
> Drake]
> #4509: Jason Grout: doctests for planarity code [Reviewed by Tom
> Boothby, Minh Van Nguyen]
> #4756: Rob Beezer: eigenmatrix_right totally broken [Reviewed by Alex Ghitza]
> #5165: Alex Ghitza: make padded_list use prec by default [Reviewed by
> David Loeffler]
> #6214: Volker Braun: Polyhedra compute incorrect dimension when
> defined through inequalities [Reviewed by Marshall Hampton]
> #6390: John Cremona: Implement elliptic logarithms (complex case)
> [Reviewed by Chris Wuthrich]
> #6671: Martin Raum: Speed of Victor Miller basis [Reviewed by David Loeffler]
> #6781: Nils Bruin: Library access to ecl [Reviewed by Burcin Erocal,
> Karl-Dieter Crisman, Nils Bruin]
> #6836: Lloyd Kilford, Alex Ghitza: The Sturm bound for modular forms
> gives the wrong result sometimes [Reviewed by David Loeffler]
> #6955: John Cremona: update simon denis pari-scripts [Reviewed by
> Chris Wuthrich]
> #7288: Nathann Cohen: Gomory-Hu Trees [Reviewed by Alexandre Blondin Massé]
> #7311: Nathann Cohen: Improve the add_constraint method from
> MixedIntegerLinearProgram [Reviewed by Alexandre Blondin Massé]
> #7538: Florent Hivert, Nicolas Borie: equality of posets is broken !
> [Reviewed by Andrey Novoseltsev]
> #7549: Mitesh Patel: Reference manual: class hierarchy, inherited
> members, underscore variables [Reviewed by John Palmieri]
> #7555: Rob Beezer, Nicolas M. Thiéry: Fix Cayley tables, add operation
> tables [Reviewed by Nicolas M. Thiéry, Jason Grout]
> #7569: Nathann Cohen: random_vertex and random_edge functions
> [Reviewed by Alexandre Blondin Massé]
> #7661: Burcin Erocal: maxima interface gives precedence to function
> dictionary instead of local variables [Reviewed by Robert Mařík]
> #7748: Flavia Stan, Burcin Erocal: Make incomplete gamma function
> symbolic [Reviewed by Paul Zimmermann]
> #7805: Nathann Cohen: MixedIntegerLinearProgram.show should use the
> constraints' names [Reviewed by David Joyner]
> #7880: David Roe: Category of sets with partial maps. [Reviewed by
> Robert Bradshaw, David Loeffler]
> #7914: Jason Bandlow: Implementation of triangular morphisms for
> modules with basis [Reviewed by Nicolas M. Thiéry]
> #8018: Rob Beezer: Eigenvalues sorted, but not eigenvectors, in
> modular/modform/numerical.py [Reviewed by Alex Ghitza]
> #8071: Rob Beezer: Trivial kernel of a matrix over non-fields are
> broken [Reviewed by Martin Albrecht]
> #8133: Chris Wuthrich: changing the string representation of Dirichlet
> charachters [Reviewed by John Cremona]
> #8218: David Roe: Finite Field move [Reviewed by David Loeffler]
> #8242: Marc Mezzarobba: Fix duplicate citation warnings when building
> the French-language tutorial [Reviewed by Paul Zimmermann, Minh Van
> Nguyen]
> #8281: Alex Ghitza: bug in hecke_operator_on_basis over finite fields
> [Reviewed by David Loeffler]
> #8297: Burcin Erocal: extra parenthesis when typesetting QQ arguments
> to symbolic functions [Reviewed by Håkan Granath]
> #8300: Robert Bradshaw: native algdep with proof option [Reviewed by
> John Cremona]
> #8313: Florent Hivert: Misplaced "`" in linear code construction
> documentation [Reviewed by Minh Van Nguyen]
> #8329: Ryan Hinton: Missing copy() method in BipartiteGraph [Reviewed
> by Robert Miller]
> #8330: Ryan Hinton: BipartiteGraph needs to override methods to add
> and delete vertices and edges [Reviewed by Nathann Cohen]
> #8332: David Roe: Changes FiniteField_givaro to Python [Reviewed by
> David Loeffler, John Cremona]
> #8344: Dmitrii Pasechnik: Factor constant polynomials over QQbar
> [Reviewed by Paul Zimmermann, John Cremona]
> #8366: Jason Grout: make contour plot labels and linestyles work when
> fill=True [Reviewed by Robert Mařík]
> #8390: Robert Mařík: Find all roots of a trigonometric equation
> [Reviewed by William Stein]
> #8404: Nathann Cohen: Computing a H-minor [Reviewed by Dmitrii Pasechnik]
> #8417: Yann Laigle-Chapuy: improve CubeGraph and HyperStarGraph
> generation [Reviewed by Robert Miller]
> #8420: Valentin Feray: new feature : class of perfect matching
> [Reviewed by Florent Hivert]
> #8421: Ryan Hinton: Change BipartiteGraph .left and .right to sets
> [Reviewed by Robert Miller]
> #8424: Jason Grout: bounding box calculation doesn't handle NaN or
> infinity [Reviewed by Robert Mařík]
> #8428: Charlie Turner: Problem with rational_points over plane curves
> AND addition of rational_points_iterator function [Reviewed by David
> Roe]
> #8429: Sébastien Labbé: Split word.py file into 4 files [Reviewed by
> Alexandre Blondin Massé]
> #8438: Florent Hivert: Construction of a skew partition from its row
> and column lengths [Reviewed by Nicolas Borie]
> #8444: Gonzalo Tornaria: Memleak in conversion for univariate
> polynomial rings [Reviewed by Paul Zimmermann]
> #8476: Martin Albrecht: return the correct class instance in
> MPolynomialSystem.__copy__ [Reviewed by Yann Laigle-Chapuy]
> #8481: John Palmieri: lift doesn't work for vector space homomorphisms
> [Reviewed by William Stein]
> #8484: Robert Miller: incremental improvements to prove_BSD [Reviewed
> by John Cremona]
> #8486: Kwankyu Lee: Xelatex and Sage notebook [Reviewed by Dan Drake,
> John Palmieri]
> #8487: Robert Mařík: Use use_grobner in to_poly_solve [Reviewed by Alex Ghitza]
> #8502: John Cremona: evaluating multivariate polynomials yields
> non-constant [Reviewed by Alex Ghitza]
> #8504: Robert Bradshaw: AbelianGroup.exponent() uses GAP (slow)
> [Reviewed by Mike Hansen]
> #8506: Robert Bradshaw: Inefficient hash for homsets [Reviewed by John Cremona]
> #8509: David Kirkby, John Palmieri: Ilegal 'grep -o' causes problems
> installing optional packages on Solaris [Reviewed by Dmitrii
> Pasechnik]
> #8513: Alexandre Blondin Massé, Nathann Cohen: Including documentation
> in the reference manual for some files related to graph theory
> [Reviewed by Minh Van Nguyen, John Palmieri]
> #8519: Nicolas Borie: Add a factory of finite/infinite enumerated set
> (with categories) defines by Range(begin, end, step) [Reviewed by
> Florent Hivert]
> #8536: John Cremona: Change SAGE" to "Sage" in output [Reviewed by Dan Drake]
> #8541: David Loeffler: Cyclotomic matrix multiplication bug [Reviewed
> by William Stein]
> #8543: Florent Hivert: EmptySet is Back ! TestSuite should allows for
> empty sets. [Reviewed by Nicolas Borie, Nicolas M. Thiéry]
> #8547: William Stein: implement hidden markov models in Cython from
> scratch (so can remove the GHMM standard package from Sage) [Reviewed
> by Marshall Hampton, Tom Boothby, Jason Grout]
> #8560: Kwankyu Lee: magma interface should be changed to use
> sage-native-execute [Reviewed by William Stein]
> #8572: Florent Hivert: Doc of poset appear as void if called from the
> console. [Reviewed by John Palmieri]
> #8576: Nicolas M. Thiéry: Categories for QQ, CC, RR and friends
> [Reviewed by John Cremona]
> #8579: Nicolas M. Thiéry: Add the categories of magmas and additive
> magmas [Reviewed by Robert Beezer, Florent Hivert]
> #8580: Martin Albrecht: bug in matrix_mod2_dense (m4ri wrapper?):
> exhibited by bug in coercing into a 0-dimensional qotient vector space
> [Reviewed by William Stein]
> #8584: David Loeffler: implement latex'ing of Dirichlet characters
> [Reviewed by Chris Wuthrich]
> #8595: Sébastien Labbé: Fixed point of word morphism is broken on some
> tuple input [Reviewed by Vincent Delecroix]
> #8599: Sébastien Labbé: Allow size as an argument for point2d
> [Reviewed by Jason Grout]
> #8600: Harald Schilly, Yann Laigle-Chapuy: fibonacci tree [Reviewed by
> Robert Miller]
> #8602: Gonzalo Tornaria: Implement theta series of degree 2 [Reviewed
> by Alex Ghitza]
> #8609: Andrey Novoseltsev: Switch AmbientSpace and Scheme to Parent
> [Reviewed by John Cremona]
> #8610: William Stein: fix caching bug in modular/modsym/element.pyx
> (very easy to review!) [Reviewed by Alex Ghitza]
> #8618: Sébastien Labbé: Fix is_identity of WordMorphism to handle non
> standard alphabet [Reviewed by Vincent Delecroix]
> #8620: David Loeffler: Rogue minus sign in
> sage.modular.modsym.ambient.diamond_bracket_operator [Reviewed by
> William Stein]
> #8630: David Loeffler: Cusp forms constructor ignores the character
> and returns enormous space [Reviewed by William Stein]
> #8633: John Palmieri: remove more instances of 'texttt' from jsmath
> output [Reviewed by Andrey Novoseltsev]
> #8635: Paul Zimmermann: Typos in DisjointUnionEnumeratedSets.
> [Reviewed by Florent Hivert]
> #8636: William Stein: iconv -- put the "do ...
>
> read more »

Rob Beezer

unread,
Apr 19, 2010, 12:56:12 AM4/19/10
to sage-release
On Apr 17, 8:09 pm, John H Palmieri <jhpalmier...@gmail.com> wrote:
> > sextus: (Fedora)
> > Linux sextus 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC
> > 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> > sage -t -long "devel/sage/sage/matrix/matrix_double_dense.pyx"
>
> Can someone open up a ticket for this one (and also fix it)?

There is a patch fixing the doctests (hopefully), now up at
http://trac.sagemath.org/sage_trac/ticket/8710

Rob

Jason Grout

unread,
Apr 19, 2010, 8:06:33 AM4/19/10
to sage-r...@googlegroups.com
On 04/18/2010 01:41 AM, Rob Beezer wrote:
Based on the output from the failing tests, it seems these
eigenvectors have been scaled to length 1 already, which is a common
form for eigenvectors.

  

That's right.  From the scipy documentation (http://docs.scipy.org/doc/scipy/reference/tutorial/linalg.html#eigenvalues-and-eigenvectors):

By definition, eigenvectors are only defined up to a constant scale factor. In SciPy, the scaling factor for the eigenvectors is chosen so that \left\Vert \mathbf{v}\right\Vert
^{2}=\sum_{i}v_{i}^{2}=1.



A thought about regularizing the output for the doctests.  Put the
eigenvector into a matrix and ask for its echelon form.  This would of
course be equivalent to William's suggestion that the leading non-zero
entry be a 1.  But presumably, all the well-founded objections raised
by Nick and Dima would be handled carefully in the code for computing
echelon form.

  

Another idea: multiply the matrix with the vectors to check the definition of an eigenvalue/eigenvector pair.

Another idea: scale so that the largest entry (in absolute value) is positive.  This still probably would run into numerical issues, but seems a little less likely if the first element is close to zero, at least to me (IANANAE too :).

I think I like the clipping idea the best---set entries very close to zero to actually be equal to (positive) zero.

Thanks,

Jason

da91896622b13bd903c21fd33683a7fd341d2842.png

Nick Alexander

unread,
Apr 19, 2010, 9:03:01 AM4/19/10
to sage-r...@googlegroups.com
> I think I like the clipping idea the best---set entries very close
> to zero to actually be equal to (positive) zero.

I like this best too, but I doubt it will work well in practice. Too
hard to determine what "close to zero" means.

Nick

Jason Grout

unread,
Apr 19, 2010, 2:19:06 PM4/19/10
to sage-r...@googlegroups.com
On 04/19/2010 08:03 AM, Nick Alexander wrote:
>> I think I like the clipping idea the best---set entries very close to
>> zero to actually be equal to (positive) zero.
>
> I like this best too, but I doubt it will work well in practice. Too
> hard to determine what "close to zero" means.

Yes. Since we are dealing with double precision in these calculations,
though, a small multiple of machine epsilon might be a good estimate.

sage: import numpy
sage: numpy.finfo(numpy.double).eps
2.2204460492503131e-16

or

sage: RR(1).nextabove()-RR(1)
2.22044604925031e-16

Thanks,

Jason

gsw

unread,
Apr 19, 2010, 3:36:27 PM4/19/10
to sage-release
On 18 Apr., 21:55, Kiran Kedlaya <ksk...@gmail.com> wrote:
> I still can't build cddlib on my mixed-platform Fedora 10 machine (64-
> bit machine in a 32-bit NFS environment). Specifically, I hit this
> error:
>
> /bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2 -L/usr/local/lib
> -L/scratch/sage-4.4.alpha0/local/lib  -o scdd_gmp simplecdd.o ../lib-
> src-gmp/libcddgmp.la -lgmp
> libtool: link: gcc -g -O2 -o .libs/scdd_gmp simplecdd.o  -L/usr/local/
> lib -L/scratch/sage-4.4.alpha0/local/lib ../lib-src-gmp/.libs/
> libcddgmp.so /scratch/sage-4.4.alpha0/local/lib/libgmp.so /usr/local/
> pkg/gmp-4.2.4/lib/libgmp.so -Wl,-rpath
> -Wl,/scratch/sage-4.4.alpha0/local/lib -Wl,-rpath -Wl,/usr/local/pkg/
> gmp-4.2.4/lib
> /usr/local/pkg/gmp-4.2.4/lib/libgmp.so: could not read symbols: File
> in wrong format
>
> Can anyone explain why /usr/local/lib is in there? On this system,
> that points to an NFS folder with 32-bit libraries. I have
> LD_LIBRARY_PATH set globally to the correct value (/usr/lib:/usr/
> lib64) but apparently libtool hasn't gotten the message.
>
> If it helps, I suppose I could ask my sysadmin to add a link to libgmp
> in /usr/lib (right now it's in /usr/lib64), but that hardly seems like
> the most robust solution for this issue.
>
> Kiran
>

Hi Kiran,

sorry, is there already a ticket for this issue? If so, the following
should be posted there.

> Can anyone explain why /usr/local/lib is in there?

Probably it's in there, because in the corresponding "configure.ac"
nothing is explicitly said about "AC_PREFIX_DEFAULT()", so in
"configure", line 733 reads: "ac_default_prefix=/usr/local" (which is
the default). To override this default, giving the command line option
"---prefix=..." is not sufficient in all cases, e.g. for libraries to
be used, it seems one also has to set "--exec-prefix=..."

Now if you want to give one quick try to "heal" a Sage make run of
yours broken as above, you should have under its "$SAGE_ROOT/spkg/
build/" still some subdirectory "cddlib-094f.p5/". Open a shell, cd to
this directory, there is a bash-script "spkg-install". Change its line
64 :

./configure --prefix=$SAGE_LOCAL

to

./configure --prefix=$SAGE_LOCAL --exec-prefix=$SAGE_LOCAL

Now run this modified script (via "./spkg-install"). That's pretty
much a shot in the dark. But if it works, I promise I'm going to
create a ticket (if that does not exist already), and an updated spkg.


Cheers,
Georg

John H Palmieri

unread,
Apr 19, 2010, 5:23:15 PM4/19/10
to sage-release
I'm having what looks like a very similar problem building cddlib on
t2.math (a Solaris box), and setting exec-prefix didn't help,
unfortunately. When I look at config.log, I see:

configure:2856: gcc -v >&5
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.1/configure --prefix=/usr/local/gcc-4.4.1-
sun-linke\
r/ --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/
ld --witho\
ut-gnu-ld --enable-languages=c,c++,fortran --with-mpfr-include=/usr/
local/inclu\
de --with-mpfr-lib=/usr/local/lib --with-gmp-include=/usr/local/
include --with-\
gmp-lib=/usr/local/lib CC=/usr/sfw/bin/gcc CXX=/usr/sfw/bin/g++

So I wonder if it's getting /usr/local/lib from how gcc was configured
when it was built? I don't see any options for "configure" (for
cddlib) which allow me to set gmp-lib or mpfr-lib.

--
John

Dima Pasechnik

unread,
Apr 20, 2010, 7:37:36 AM4/20/10
to sage-release, sage-devel
Dan,

indeed, it's not too bad to normalize to norm 1, say, but it is quite
bad to normalize a given coordinate to 1.
I cc this to sage-devel

Best,
Dima
>  signature.asc
> < 1KViewDownload

Dima Pasechnik

unread,
Apr 20, 2010, 8:17:50 AM4/20/10
to sage-release
John,
you need to change patches/Makefile.am
so that line 7 of this file becomes

export gmpdir := $(SAGE_LOCAL)

Otherwise gmpdir remains fixed to /usr/local, against all the
configure options, IMHO...

I'll try this on t2 right now.

Dima

Dima Pasechnik

unread,
Apr 20, 2010, 8:24:30 AM4/20/10
to sage-release
oops, sorry, I am sure that this is the root of the problem, but I am
no autoconf guru an I do not know
where exactly this change must go, and how exactly push it onto the
right place.
(after this change I still see "--with-gmp-lib=/usr/local/lib" in the
configure report, so apparently some black magic is still needed)

Dima

gsw

unread,
Apr 20, 2010, 2:37:00 PM4/20/10
to sage-release


On 20 Apr., 14:17, Dima Pasechnik <dimp...@gmail.com> wrote:
> John,
> you need to change patches/Makefile.am
> so that line 7 of this file becomes
>
> export gmpdir := $(SAGE_LOCAL)
>
> Otherwise gmpdir remains fixed to /usr/local, against all the
> configure options, IMHO...
>

Whoa, evil!

But "Makefile.am" is only an autotools input file, so I think either
you have to "autogenerate" anew the whole stuff under the directory of
the same name, or edit manually the corresponding line 705 in patches/
autogenerated/Makefile.in (with exactly the change you proposed).


Cheers,
Georg

John H Palmieri

unread,
Apr 20, 2010, 5:47:42 PM4/20/10
to sage-release
Kiran,

Can you try the spkg at <http://trac.sagemath.org/sage_trac/ticket/
8730>, to see if that fixes the problem?


On Apr 18, 12:55 pm, Kiran Kedlaya <ksk...@gmail.com> wrote:
> I still can't build cddlib on my mixed-platform Fedora 10 machine (64-
> bit machine in a 32-bit NFS environment). Specifically, I hit this
> error:

--
John

Kiran Kedlaya

unread,
Apr 21, 2010, 2:42:21 PM4/21/10
to sage-release
It does fix the problem (I posted this news to the ticket also).
Excellent!

Kiran
Reply all
Reply to author
Forward
0 new messages