[sage-release] Sage 4.4.alpha0 released
8 views
Skip to first unread message
John Palmieri
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.
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
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
> 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.
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
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?
(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
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
> This alpha release of Sage incorporates about 90 tickets fixed since
> version 4.3.5.
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
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.
> Building the new alpha from scratch worked fine and all tests passed
> (including long) on Ubuntu x86_64.
Tim Joseph Dumol
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
Tim Joseph Dumol <tim (at) timdumol (dot) com>
http://timdumol.com
Rob Beezer
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
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
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
> 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.
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
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,
> 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
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
John H Palmieri
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
> 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).
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
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
> Yes, sorry, I wasn't as specific as I could have been. Doctests
> passed completely on these skynet machines:
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
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
> 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
maintenance.
Message has been deleted
William Stein
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>
> 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
> 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
>> I've created a system for automatically testing upgrades from most
>> previous 4.x series upgrades to sage-4.4.alpha0.
>
> 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
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
> 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.
other similar permutations?
(1e-100, 1)
(1e-10, 1)
(1e-1, 1)
(1e-100, 1e100)
(1e-10, 1e100)
(1e-1, 1e100)
Nick
William Stein
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])
>> 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
(1e-100, 1.0)
sage: a/a[0]
(1.0, 1e+100)
> (1e-10, 1)
> (1e-1, 1)
> (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
Apr 17, 2010, 9:30:17 PM4/17/10
to sage-r...@googlegroups.com
"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.
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
Apr 17, 2010, 9:54:22 PM4/17/10
to sage-r...@googlegroups.com
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.
>
>
> 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.
>
>
Nick Alexander
Apr 17, 2010, 10:00:26 PM4/17/10
to sage-r...@googlegroups.com
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
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.
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
>
> --
> William Stein
> Professor of Mathematics
> University of Washingtonhttp://wstein.org
> --
> William Stein
> Professor of Mathematics
>
> --
> 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.
> --
> 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
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
>
> > 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"
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"
Rob Beezer
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
> > 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)?
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
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
> 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.
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.
>
>
Dan Drake
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.
> 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
-------
William Stein
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
> 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.
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
> -------
>
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvKetcACgkQr4V8SljC5Lq3+wCgyBiDnF5i7AZfMIaOb1e0NxFq
> UVcAoMbL7/T9UW3iirAyXKBC+fHOah+D
> =2sUr
> -----END PGP SIGNATURE-----
Robert Bradshaw
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
> 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.
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
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
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
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
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.
>
>
> 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