8 views

Skip to first unread message

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.

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

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?

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

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.

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

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

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.

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

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.

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

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

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

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

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

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

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.

>

>

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

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.

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"

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

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.

>

>

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

-------

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

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

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

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