Sage 4.7.2.alpha3 released

[leif]

Dear Sage lovers,

we're releasing Sage 4.7.2.alpha3.

Source archive:

http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-4.7.2.alpha3.tar

md5sum: d079f6ebf9fc234d1816aeffe71b6fe8

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-4.7.2.alpha3/

(Note that upgrading *from* a previous *development* release is "broken
by [the current] design"^TM; upgrading from e.g. Sage 4.7.1 works.)

The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):

http://www.sagemath.org/download-latest.html

Please build, test, and report! We'd love to hear about your
experiences with this release.

Note that race conditions in parallel doctesting should be an issue of
the past, thanks to John Palmieri (cf. #9739).
At least Dave Kirkby will appreciate that... ;-)

We fixed all doctests failing due to numerical noise on a couple of
systems; special thanks go to Rob Beezer for interrupting his Sage
vacation for this.

The known build errors (Singular and Symmetrica) on the not-yet-released
Ubuntu 11.10 Oneiric Ocelot will be fixed in the next alpha or release
candidate for the final Sage 4.7.2, such that these should no longer be
an issue when the final of the new Ubuntu gets released in a few weeks.

My apologies to the folks at Sage Days 34 (the Sage / Singular Days),
since I originally planned to release before that event, in order to let
them base their work on this development release, which includes a lot
of tickets and hence many changes to the code, which means that patches
based on the previous release are quite likely to need rebasing.

-leif

Wed Sep 28 18:07:18 UTC 2011

== Tickets ==

* We closed 219 tickets in this release. For details, see

http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/tickets.html

Closed tickets:

#748: [waiting on upstream] update iml to the 1.0.3 release + our
patches [Reviewed by Leif Leonhardy]
#1904: elliptic curves -- some period lattice functions are not
implemented [Reviewed by John Cremona, David Loeffler, Paul Zimmermann]
#2110: Cython annotation should be available more easily [Reviewed by
Robert Bradshaw]
#8085: 1d line plot [Reviewed by Karl-Dieter Crisman]
#8217: Marshall Hampton: make 4ti2 an optional package [Reviewed by
David Perkinson]
#10152: bug in integral_points (for elliptic curves over Q) [Reviewed by
William Stein]
#10252: ecm does not compile on some 32-bit Linux systems [Reviewed by
Leif Leonhardy]
#11242: python spkg build fails on Ubuntu 11.04 [Reviewed by Jan
Groenewald, Leif Leonhardy]
#11405: magma interface needs work in presence of newlines [Reviewed by
William Stein]
#11421: Mariah Lenox: upgrade optional package NZMATH to version 1.1.0
[Reviewed by William Stein]
#11427: optional spkg database_gap-4.4.12.p0.spkg fails test on
sage-4.7.1.alpha1 [Reviewed by William Stein]
#11504: Karl-Dieter Crisman: Tachyon fails to build on Cygwin - again
[Reviewed by Reg Burgess, Leif Leonhardy]
#11723: Implement completion: LaurentPolynomialRing -> LaurentSeriesRing
[Reviewed by Tom Boothby]
#11728: Multiplication(?) buggy in AA [Reviewed by William Stein]
#11733: do not load sagenb.misc.misc on startup [Reviewed by Julian Rueth]
#11746: Unify the definition of "monomial", introduce "term" [Reviewed
by William Stein]
#11833: Class for ternary quadratic forms [Reviewed by Leif Leonhardy]
#11834: Gustavo Rama: Class for ternary quadratic forms [Reviewed by
Leif Leonhardy]

Merged in sage-4.7.2.alpha3:

#813: Simon King: forced coercion vs. automatic coercion [Reviewed by
Julian Rueth]
#3052: Keshav Kini: mercurial --> plain text --> mercurial [Reviewed by
Volker Braun]
#5847: Mike Hansen, Leif Leonhardy, Jeroen Demeyer: Update GMP-ECM to
6.3 [Reviewed by Leif Leonhardy, Dmitrii Pasechnik, Mariah Lenox,
Maarten Derickx]
#6315: Mariah Lenox, William Stein: optional doctest failure -- caused
by mistakes in lectures on number theory rst book [Reviewed by Marco Streng]
#6329: Mariah Lenox, William Stein: optional doctest failure --
breakage in the sage<-->magma interface [Reviewed by Mike Hansen]
#7714: Martin Albrecht: bug in matrix pivots over multivariate
polynomial ring [Reviewed by Luis Felipe Tabera Alonso]
#7852: Rob Beezer, Leif Leonhardy: solve_left for RDF matrices is WRONG
[Reviewed by Martin Raum, Leif Leonhardy, Rob Beezer]
#7879: Robert Bradshaw: Remove unnecessary signal handling for low prec
mpfr operations. [Reviewed by Alex Ghitza, Mariah Lenox, William Stein]
#8094: Harald Schilly, Jason Grout, Martin Raum: shortcuts properties
for matrix transpose, complex conjugate, conjugate transpose, and
inverse [Reviewed by Rob Beezer, Martin Raum]
#8469: Minh Van Nguyen: add "Number Theory and the RSA Public Key
Cryptosystem" to "Thematic Tutorials" [Reviewed by Pablo Angulo, Rob
Beezer, Martin Albrecht]
#8664: Mike Hansen, Leif Leonhardy: Upgrade Sage's MPIR spkg to version
2.1.3 [Reviewed by Leif Leonhardy, Dmitrii Pasechnik]
#9138: Simon King: Categories for all rings [Reviewed by Volker Braun]
#9739: Mitesh Patel, John Palmieri: Handle duplicate file basenames when
testing multiple files in parallel [Reviewed by Robert Bradshaw, Leif
Leonhardy]
#10335: Mike Hansen, Jason Hill, David Loeffler: Add domains for
permutation groups [Reviewed by Robert Miller, Rob Beezer, Nicolas
Borie, Nicolas M. Thiï¿œry]
#10453: David Loeffler: Problem with old submodule [Reviewed by Johan
Bosman]
#10464: Katherine Stange: m-th power residue symbol [Reviewed by Francis
Clarke, David Loeffler]
#10635: Christopher Hall: refactor polynomial_element.pyx factor
function [Reviewed by Mariah Lenox, William Stein, Simon Spicer]
#10801: William Stein, Keshav Kini: Create a new option: "sage -strip"
which deletes things that aren't needed for a binary distribution of
sage, or for people that will never develop or upgrade [Reviewed by
Benjamin Jones, Keshav Kini]
#10850: Francis Clarke: composition and comparison of number-field
homomorphisms [Reviewed by David Loeffler]
#10952: Robert Bradshaw, Rob Beezer: better numerical accuracy testing
[Reviewed by Jason Grout, Mariah Lenox, William Stein, John Palmieri]
#10975: William Stein: creation of certain prime finite fields is double
dog slow (compared to Magma) [Reviewed by David Roe, Tom Boothby]
#10981: William Stein: algebraic real field
partial_fraction_decomposition bug [Reviewed by Simon Spicer, Leif
Leonhardy]
#11036: Douglas McNeil, Maarten Derickx: improve solve_mod performance
[Reviewed by John Cremona, Simon Spicer]
#11120: Keshav Kini, John Palmieri: Autodetect installed 3-way merge
programs (invalidates #4434) [Reviewed by John Palmieri, Keshav Kini]
#11142: John Palmieri: clean up sage/misc/hg.py [Reviewed by Karl-Dieter
Crisman, Keshav Kini]
#11259: Rob Beezer: LU decomposition for matrices with exact base rings
[Reviewed by Martin Raum]
#11342: Simon King, Volker Braun: Make getattr faster on parents and
elements [Reviewed by Jeroen Demeyer, Volker Braun, Simon King]
#11351: Mariah Lenox: make flintqs-20070817 spkg build with -m64 rather
than -march=opteron [Reviewed by Martin Albrecht]
#11354: Mariah Lenox: remove dist directory from eclib spkg [Reviewed by
William Stein]
#11385: Volker Braun, Andrey Novoseltsev: Orbit closure as toric variety
[Reviewed by Andrey Novoseltsev, Volker Braun]
#11401: Nils Bruin: magma mode in 4.7 notebook broken [Reviewed by Marco
Streng]
#11422: Vincent Delecroix: modular subgroups [Reviewed by David Loeffler]
#11431: Simon King: Conversion from Singular to Sage [Reviewed by Martin
Albrecht]
#11460: Franï¿œois Bissey, John Palmieri: upgrade ipython to 0.10.2
[Reviewed by Franï¿œois Bissey, John Palmieri]
#11544: Rob Beezer: Viewing matrices of algebraic numbers can take a
long time [Reviewed by Martin Raum]
#11553: Rob Beezer: Matrix morphism additions [Reviewed by Martin Raum]
#11574: Martin Albrecht: update M4RI to newest upstream release
[Reviewed by Simon King, Alexander Dreyer]
#11580: Nils Bruin: Magma interface cannot convert multivariate
polynomials back to Sage [Reviewed by William Stein, Marco Streng]
#11587: R. Andrew Ohana: update Cremona's tables for Sage [Reviewed by
John Cremona, Tom Boothby]
#11588: Nathann Cohen: copying a linear program crashes Sage [Reviewed
by John Perry]
#11595: Rob Beezer: Update exact eigenspace routines [Reviewed by Martin
Raum, Leif Leonhardy]
#11598: David Loeffler: Congruence testing for odd modular subgroups
[Reviewed by Vincent Delecroix]
#11627: Andrey Novoseltsev: Turn Fan(discard_warning) into an error
[Reviewed by Volker Braun]
#11640: R. Andrew Ohana: Remove DB_HOME in preference of SAGE_DATA
[Reviewed by Tom Boothby]
#11642: R. Andrew Ohana: Rewrite/improve/fix SQLDatabase and SQLQuery
objects [Reviewed by Tom Boothby]
#11657: William Stein, Rob Beezer: the vector(...) function is extremely
slow [Reviewed by Rob Beezer, William Stein]
#11680: Martin Albrecht: support extra_compile_args (e.g., C99) when
loading/attaching .pyx (cython) files, and when using %cython in the
notebook [Reviewed by William Stein, Leif Leonhardy]
#11682: David Perkinson: Thematic Tutorial on Sandpiles [Reviewed by Rob
Beezer, John Palmieri]
#11684: Johan Bosman, Simon King: Obtaining coefficients of polynomials
over finite fields is extremely slow [Reviewed by Simon King, Johan Bosman]
#11685: Johan Bosman, Jeroen Demeyer: Pari finite field extension:
element created by list not recognised as zero [Reviewed by Simon King,
Johan Bosman, Peter Bruin]
#11690: Martin Albrecht: fix AES equation systems when star=True
[Reviewed by David Montminy]
#11691: Ivan Andrus: scaling_term only appears in documentation
[Reviewed by Nathann Cohen]
#11692: Ivan Andrus: Creating a multiedged graph gives wrong error
[Reviewed by Nathann Cohen]
#11700: Anne Schilling: Methods concerning cores in Partitions [Reviewed
by Mike Zabrocki]
#11703: Frï¿œdï¿œric Chapoton: another example of simplicial complex : the
K3 surface [Reviewed by John Palmieri]
#11706: William Stein, Leif Leonhardy: tachyon-0.98.9.p3 fails to build
on ppc64 SUSE Linux power 7 (silius on skynet) [Reviewed by Leif
Leonhardy, Karl-Dieter Crisman, Mike Hansen]
#11709: Hartmut Monien: FareySymbol [Reviewed by Martin Raum, Leif
Leonhardy]
#11711: Rob Beezer: Add charpoly as an alias for graph characteristic
polynomials [Reviewed by Nathann Cohen]
#11712: Martin Albrecht: Make it so typing `cython?` results in one
seeing documentation for all pragmas for %cython mode and load/attach
.pyx file [Reviewed by Mike Hansen]
#11714: William Stein, Julian Rueth: ensure that numpy is not imported
on startup [Reviewed by William Stein]
#11716: Julian Rueth: Remove twisted.persisted.styles import [Reviewed
by Mike Hansen]
#11722: Maarten Derickx: document the SAGE_PARALLEL_SPKG_BUILD
environment variable [Reviewed by Simon Spicer, John Palmieri]
#11725: Rob Beezer: Generate random elements of the algebraic field
[Reviewed by Simon Spicer, Leif Leonhardy]
#11727: Karl-Dieter Crisman, Dmitrii Pasechnik: Even more minor Cygwin
fixes for FLINT [Reviewed by Dmitrii Pasechnik, Karl-Dieter Crisman]
#11732: Julian Rueth: faster import of sage.interacts.all [Reviewed by
William Stein]
#11734: Julian Rueth: sage_wraps should only read the sources of wrapped
functions when needed. [Reviewed by Simon King]
#11738: Diego de Estrada: Various issues in is_interval and is_chordal
[Reviewed by Nathann Cohen]
#11741: R. Andrew Ohana: pari.init_primes() can segfault for large input
on many platforms [Reviewed by Aly Deines]
#11744: Karl-Dieter Crisman: Add library gmp needed for real interval
absolute [Reviewed by Mike Hansen]
#11747: William Stein: is_monomial and is_term [Reviewed by Mike Hansen]
#11749: Robert Bradshaw: Remove unneeded imports [Reviewed by Keshav
Kini, Leif Leonhardy]
#11750: Maarten Derickx: CRT_list not working for non-coprime moduli
[Reviewed by Luis Felipe Tabera Alonso, Wai Yan Pong, Leif Leonhardy]
#11751: Maarten Derickx, Julian Rueth: make free_module_generic_pid also
work for pid's other than integers [Reviewed by Julian Rueth, Maarten
Derickx]
#11752: Paulo Cï¿œsar Pereira de Andrade: ecl.pyx should not touch SIGPWR
neither SIGXCPU when initializing ecl [Reviewed by Nils Bruin]
#11753: Punarbasu Purkayastha: Fix step=0 in (x)srange [Reviewed by
Dmitrii Pasechnik]
#11756: Alexander Dreyer: PolyBoRi 0.7.1 needs to activate -msse2
[Reviewed by Martin Albrecht]
#11767: Paul Zimmermann: elliptic_logarithm of high precision points
often hangs forever [Reviewed by John Cremona, Leif Leonhardy, William
Stein]
#11778: Johan Bosman: p_iter_fork doesn't flush stdout properly
[Reviewed by Leif Leonhardy]
#11779: Dmitrii Pasechnik: python ints vs sage ints with respect to
powers weirdness [Reviewed by William Stein]
#11798: Paul Zimmermann: typo in the documentation of weierstrass_points
[Reviewed by Luca De Feo]
#11801: Jean-Pierre Flori: Ill-formed documentation of
HilbertClassPolynomialDatabase [Reviewed by Paul Zimmermann]
#11810: Nicolas Estibals: Formatting issue in documentation of
divisor_group method [Reviewed by Jean-Pierre Flori]
#11815: Simon King: Embedding information in doc strings must not be
formatted [Reviewed by Volker Braun]
#11816: Julian Rueth: Typo in the developer's guide [Reviewed by Leif
Leonhardy]
#11818: John Palmieri: sage <script> does not run sage-cleaner [Reviewed
by Volker Braun]
#11820: Andrￜ Apitzsch: Undo #4777: Remove PARI bug work-around in
is_prime_power() [Reviewed by Leif Leonhardy, Jeroen Demeyer]
#11824: David Loeffler: Bug in ring_generators for relative orders
[Reviewed by Francis Clarke]
#11829: Martin Albrecht: multivariate factorization over finite fields
[Reviewed by Paul Zimmermann]
#11830: Jeroen Demeyer: Problems with Mercurial and utf-8 data in files
[Reviewed by Leif Leonhardy]
#11848: Rob Beezer: zero_at() method for RDF/CDF vectors [Reviewed by
Leif Leonhardy]
#11849: Volker Braun: cddlib test in ppl.pyx takes a very long time
[Reviewed by Jeroen Demeyer]

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email

[John Cremona]

Question about #11587: the elliptic curve datavase structure has
changed incompatibly, so as well as the standard spkg being different
in this release, the optional spkg (which used to be
database_cremona_ellcurve-20071019.spkg) has also changed. So for a
while after 4.7.2 is released we'll need to have two version of the
optional spkg around, one for use by 4.7.1 and earlier releases, one
for 4.7.2 and later. How is it proposed that this is managed? It
could be managed in the install script in both version of the optional
spkgs, which could check the version number and abort if not right.

John

On Thu, Sep 29, 2011 at 2:36 PM, leif <not.r...@online.de> wrote:
> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.
>
>

...

> #11587: R. Andrew Ohana: update Cremona's tables for Sage [Reviewed by
> John Cremona, Tom Boothby]

...

[leif]

John Cremona wrote:
> Question about #11587: the elliptic curve datavase structure has
> changed incompatibly, so as well as the standard spkg being different
> in this release, the optional spkg (which used to be
> database_cremona_ellcurve-20071019.spkg) has also changed. So for a
> while after 4.7.2 is released we'll need to have two version of the
> optional spkg around, one for use by 4.7.1 and earlier releases, one
> for 4.7.2 and later.

Well, as is, users will *always* get the newer optional spkg (currently
or temporarily in
http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/optional_spkgs/
) as soon as we put it into the proper place
(http://sagemath.org/packages/optional/ ), unless we don't delete the
old one *and* they specify the exact version in 'sage -i ...'.

> How is it proposed that this is managed? It
> could be managed in the install script in both version of the optional
> spkgs, which could check the version number and abort if not right.

No idea. ;-)

Since it shouldn't take long until 4.7.2 final gets out, users of older
Sage versions suddenly realizing that they need the larger database
would have to (or should) switch to a newer Sage version, e.g. by
running 'sage -upgrade'.

We could in principle try to convert the new database into the old
format in the new optional spkg's spkg-install if the Sage installation
it is to be installed upon uses the old format.

I don't think we'd have to support the opposite case. Although Andrew
could of course implement that, too.

2 ct,

-leif

[John Cremona]

Thanks for the useful clarification. Since the only problem case is a
user of <=4.7.1 trying to install the optional spkg and failing, which
will probably cause them to ask on sage-support or similar, we can
live with that. We could even add an answer to the FAQ.

John

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

[leif]

John Cremona wrote:
> Thanks for the useful clarification. Since the only problem case is a
> user of <=4.7.1 trying to install the optional spkg and failing, which
> will probably cause them to ask on sage-support or similar, we can
> live with that. We could even add an answer to the FAQ.

> On Thu, Sep 29, 2011 at 3:37 PM, leif <not.r...@online.de> wrote:
>> We could in principle try to convert the new database into the old
>> format in the new optional spkg's spkg-install if the Sage installation
>> it is to be installed upon uses the old format.

We could even simply recursively call 'sage -i <URL_of_old_database>' in
that case.

[John Cremona]

Successfully built and ran make ptestlong on 64-bit ubuntu.

I also succesfully added the optional spkg (91MB):

sage -i http://wstein.org/home/ohanar/cremona-database/database_cremona_ellcurve-20110915.spkg

It looks fine (and as I hoped the largest conductor is now 189999
though the trac ticket still says 179999); I am running a complete
test just to make sure and will report back.

John

[davidloeffler]

I tried building this (on 64-bit Linux) with "SAGE_CHECK" set. The
python spkg failed tests, but it always has done for me. What's new is
that testing Flint also failed: it wouldn't build the Flint test suite
(let alone run it). I've done this in the past without failures, so it
must be something fishy in the Flint 1.5.0.p9 spkg. The relevant
install.log snippet is below -- I can post the whole install.log if
necessary. Is this a known failure, or shall I open a new trac ticket?

David

g++ -I/storage/masiao/sage-4.7.2.alpha3/local/include/ -I/storage/
masiao/sage-4.7.2.alpha3/local/include -mtune=opteron -march=opteron -
fPIC -funroll-loops -O2 fmpz-test.o test-support.o -o fmpz-test
zn_mod.o misc.o mul_ks.o pack.o mul.o mulmid.o mulmid_ks.o
ks_support.o mpn_mulmid.o nuss.o pmf.o pmfvec_fft.o tuning.o mul_fft.o
mul_fft_dft.o array.o invert.o mpn_extras.o mpz_extras.o memory-
manager.o ZmodF.o ZmodF_mul.o ZmodF_mul-tuning.o fmpz.o fmpz_poly.o
mpz_poly-tuning.o mpz_poly.o ZmodF_poly.o long_extras.o zmod_poly.o
theta.o zmod_mat.o F_mpz.o tinyQS.o factor_base.o poly.o sieve.o
linear_algebra.o block_lanczos.o NTL-interface.o -L/storage/masiao/
sage-4.7.2.alpha3/local/lib/ -L/storage/masiao/sage-4.7.2.alpha3/local/
lib/ -lgmp -lpthread -lntl -lm
fmpz-test.o: In function `test___fmpz_normalise':
fmpz-test.c:(.text+0x24ed): undefined reference to `mpz_random'
collect2: ld returned 1 exit status
make: *** [fmpz-test] Error 1
Error building the test suite for FLINT
*************************************
Error testing package ** flint-1.5.0.p9 **
*************************************

On Sep 29, 2:36 pm, leif <not.rea...@online.de> wrote:
> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.
>
> Source archive:
>

> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-...
>
> md5sum: d079f6ebf9fc234d1816aeffe71b6fe8
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-...

> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/ticke...

> K3 surface [Reviewed ...
>
> read more »

[Bill Hart]

Flint 1.5 has been in sage forever so this is very fishy.

[Bill Hart]

When I do a search for mpz_random in my email I find:

"Sure. We announced a list of deprecated symbols on sage-devel and
mpir-devel. Then we permanently removed mpz_random and mpz_random2
*only* , the worst offenders."

I assume that MPIR has been updated in Sage, but the patches to
support the latest MPIR are not in flint-1.5.0.

The solution is to replace the couple of references to mpz_random in
flint with the new random functions as documented in the MPIR
documentation. The old ones were not threadsafe and absolutely had to
be deprecated in MPIR.

Beware that you cannot simply define mpz_random to initialise a random
state and call the new MPIR random function otherwise you will get the
same random number every time you call mpz_random.

Alternatively Sage could update to FLINT 1.5.2 which was issued to
specifically fix this issue. From the CHANGES.txt file:

v 1.5.2 -- 08-Apr-10

* Added some defines for MPIR 1.3 support (use of deprecated functions)

Bill.

[leif]

davidloeffler wrote:
> I tried building this (on 64-bit Linux) with "SAGE_CHECK" set. The
> python spkg failed tests, but it always has done for me. What's new is
> that testing Flint also failed: it wouldn't build the Flint test suite
> (let alone run it). I've done this in the past without failures, so it
> must be something fishy in the Flint 1.5.0.p9 spkg. The relevant
> install.log snippet is below -- I can post the whole install.log if
> necessary. Is this a known failure, or shall I open a new trac ticket?

This is a (unfortunately) very well-known issue, at least to me. ;-)

See http://trac.sagemath.org/sage_trac/ticket/9858

I haven't had the time to provide a FLINT 1.5.2 (or 1.6) spkg yet, i.e.
still have to rebase my changes on those others made to the 1.5.0 spkg
inbetween.

This will certainly be fixed in the final 4.7.2.

-leif

[Bill Hart]

This is probably the wrong place to discuss the details of that
ticket, but we are now aiming to have polynomial factoring over Z in
flint 2.4 by Christmas. Whether we succeed remains to be seen, however
some or all of that functionality will be required by Singular,
Macaulay 2 and ECPP all of which want to use flint2 and so far we are
on target (Fredrik has already got factoring over Z/nZ working, which
is a first step).

Basically what I am saying is there is now little risk to Sage in
updating all the way to flint 1.6 if that is convenient. I am also
currently porting my quadratic sieve to flint2 so even that will be
available in flint 2.3 shortly.

There were also some comments about the NTL interface being "totally
odd". I am unsure if the FLINT-NTL interface is being described as odd
or whether Sage building a monolithic FLINT library is odd. Given that
the FLINT-NTL interface only exists at the request of the Sage project
it can hardly be that which is "totally odd". It's designed to make
interface with NTL extremely fast. We have not implemented this in the
flint2 series yet and I'd be happy to leave it out if it is no longer
needed. Perhaps someone can let me know.

There is the comment "There's much wrong with this spkg (including
upstream)". Hmm. Very hard to replicate that bug. Nonetheless I agree,
hence the total rewrite of flint from scratch.

Ah I see there is an ARM issue and a Cygwin issue. But I see people
have patched those. Neither should be a problem in flint 2 series so
we didn't do anything about this upstream. Both will need to be
applied to flint 1.5.2 and at least the ARM patch will need to be
applied to flint 1.6.

From the flint 1.6 CHANGES.txt:

"v 1.6.0 -- 24-Dec-10

Bugs:
====

* Fixed a memory leak in mpz_poly_to_string_pretty
* Fixed a bug inherited from an old version of fpLLL
* Makefile to respect CC and CXX
* Fixed bug in F_mpz_set_si
* Fixed bug in F_mpz_equal
* Most for loops to C90 standard (for easier MSVC porting)
* Better Cygwin support
* Fixed a bug in zmod_poly_resultant
* Fixed bug in F_mpz_mul_KS/2
* Fixed bug in tinyQS
* Worked around some known bugs in older GMP/MPIR's"

A few hundred more issues were fixed in the flint 2 series I'm sure.

Bill.

[davidloeffler]

For what it's worth, all other spkg test suites and the Sage tests
(including long) pass.

David

On Sep 29, 7:51 pm, leif <not.rea...@online.de> wrote:
> davidloeffler wrote:
> > I tried building this (on 64-bit Linux) with "SAGE_CHECK" set. The
> > python spkg failed tests, but it always has done for me. What's new is
> > that testing Flint also failed: it wouldn't build the Flint test suite
> > (let alone run it). I've done this in the past without failures, so it
> > must be something fishy in the Flint 1.5.0.p9 spkg. The relevant
> > install.log snippet is below -- I can post the whole install.log if
> > necessary. Is this a known failure, or shall I open a new trac ticket?
>
> This is a (unfortunately) very well-known issue, at least to me. ;-)
>

> Seehttp://trac.sagemath.org/sage_trac/ticket/9858

[Jeroen Demeyer]

On 2011-09-29 15:36, leif wrote:
> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.

Highly important question: who is going to do:
* the next sage-4.7.2 series development release
* the sage-4.7.3 series
?

[leif]

Well, I thought you'd dedicate the last and relatively quick alpha
(alpha4) to #11130 and related tickets, as well as at least those that
are blockers or can be considered very important for a final release.

As mentioned, I was expecting 4.7.2 to be released before Ubuntu 11.10
final comes out.

I'm not sure whether things like the Singular upgrade will be ready in
time for that, so would otherwise reluctantly defer them to 4.7.3.

-leif

[Johan Bosman]

I'm experiencing the same problems with matplotlib-1.0.1.p0 as with
alpha2 (see http://groups.google.com/group/sage-release/browse_thread/thread/6daea0d0dfef0562).
I'm trying matplotlib-1.0.1.p1 now.

[David Joyner]

On Thu, Sep 29, 2011 at 9:36 AM, leif <not.r...@online.de> wrote:
> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.
>
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-4.7.2.alpha3.tar
>

...

>
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

Built and tested fine on a 10.6.8 mac.

[Benjamin Jones]

On Thu, Sep 29, 2011 at 8:36 AM, leif <not.r...@online.de> wrote:
> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.
>
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-4.7.2.alpha3.tar
>

Built and tested using `export MAKE="make -j4"`. Ran `make ptestlong`
with no errors.

All tests passed!
Total time for all tests: 1584.7 seconds
bael@kimchi:~/sage/sage-4.7.2.alpha3$ uname -a
Linux kimchi 2.6.32-5-amd64 #1 SMP Wed Aug 31 16:50:35 UTC 2011 x86_64 GNU/Linux

--
Benjamin Jones

[Johan Bosman]

With matplotlib-1.0.1.p1 everything built and tested fine!

On Sep 30, 11:19 am, Johan Bosman <johan.g.bos...@gmail.com> wrote:
> I'm experiencing the same problems with matplotlib-1.0.1.p0 as with

> alpha2 (seehttp://groups.google.com/group/sage-release/browse_thread/thread/6dae...).

[Johan Bosman]

On Sep 30, 3:46 pm, Johan Bosman <johan.g.bos...@gmail.com> wrote:
> With matplotlib-1.0.1.p1 everything built and tested fine!
>

On Mac OS 10.6.8 that is.

[leif]

Johan Bosman wrote:
> I'm experiencing the same problems with matplotlib-1.0.1.p0 as with
> alpha2 (see http://groups.google.com/group/sage-release/browse_thread/thread/6daea0d0dfef0562).

Well, that's due to your broken 'pkg-config'. ;-)

> I'm trying matplotlib-1.0.1.p1 now.

I'll see if I find the time to bring my p1 spkg into a mergeable state...

-leif

[Justin C. Walker]

On Sep 29, 2011, at 06:36 , leif wrote:

> Dear Sage lovers,
>
> we're releasing Sage 4.7.2.alpha3.
>
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.2.alpha3/sage-4.7.2.alpha3.tar

Built from scratch on Mac OS X 10.6.8 (Dual 6-core Xeon), w/o problems. All tests (ptestlong) passed!

Justin

--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
-----------
Nobody knows the trouble I've been
-----------

[Dima Pasechnik]

builds and tests fine on Debian x86_64.

[Keshav Kini]

Great! BTW, there seem to be some loose files in devel/sage (check `hg status`).

-Keshav

[leif]

Keshav Kini wrote:
> Great! BTW, there seem to be some loose files in devel/sage (check `hg
> status`).

And what do you get?

I occasionally get some left-around temporary *_pyx.html files, but
apparently not reproducibly (e.g. not right after the build), nor does
this seem to be a new (Cython) feature...

-leif

[Volker Braun]

If a doctest for a cython file fails in alpha3 then I get a leftover sage/misc/__homedir_hostname_nn_pyx.html file. Is that what you are talking about?

[leif]

Volker Braun wrote:
> On Saturday, October 1, 2011 3:05:29 PM UTC+2, leif wrote:
>
> I occasionally get some left-around temporary *_pyx.html files, but
> apparently not reproducibly (e.g. not right after the build), nor does
> this seem to be a new (Cython) feature...
>
> If a doctest for a cython file fails in alpha3 then I get a leftover
> sage/misc/__homedir_hostname_nn_pyx.html file. Is that what you are
> talking about?

I've seen such files there (don't recall whether only there), although
no doctests failed.

There are sometimes(?) also just their C counterparts, which are ignored
by Mercurial, so you usually won't see them.

But anyway, no doctest should write into that directory.

[John H Palmieri]

They seem to arise from doctesting sage/misc/cython.py, or at least that is the case for the files that I see.  I wonder if it's related to http://trac.sagemath.org/sage_trac/ticket/9739 somehow.

--
John

[John H Palmieri]

I don't know why these files would start popping up in this release.  I feel like the issue is the use of os.curdir in the following code from cython.py:

    if create_local_c_file:
        target_c = '%s/_%s.c'%(os.path.abspath(os.curdir), base)
        if language == 'c++':
            target_c = target_c + "pp"
        cmd += " && cp '%s.c' '%s'"%(name, target_c)
        if annotate:
            target_html = '%s/_%s.html'%(os.path.abspath(os.curdir), base)
            cmd += " && cp '%s.html' '%s'"%(name, target_html)
       
If we make the following change to cython.py, the problems seem to go away for me, but I don't know if it's the right thing to do:

diff --git a/sage/misc/cython.py b/sage/misc/cython.py
--- a/sage/misc/cython.py
+++ b/sage/misc/cython.py
@@ -17,7 +17,7 @@ AUTHORS:
 
 import os, sys, platform
 
-from misc import SPYX_TMP, SAGE_ROOT, SAGE_LOCAL
+from misc import SPYX_TMP, SAGE_ROOT, SAGE_LOCAL, SAGE_TMP
 from sage.misc.misc import UNAME
 
 def cblas():
@@ -627,6 +627,7 @@ def compile_and_load(code):
     file = tmp_filename() + ".pyx"
     open(file,'w').write(code)
     from sage.server.support import cython_import
+    os.chdir(SAGE_TMP)
     return cython_import(file)
 
--
John

[John H Palmieri]

On Saturday, October 1, 2011 10:15:25 AM UTC-7, John H Palmieri wrote:

On Saturday, October 1, 2011 9:43:13 AM UTC-7, John H Palmieri wrote:

On Saturday, October 1, 2011 6:30:06 AM UTC-7, leif wrote:

Volker Braun wrote:
> On Saturday, October 1, 2011 3:05:29 PM UTC+2, leif wrote:
>
>      I occasionally get some left-around temporary *_pyx.html files, but
>     apparently not reproducibly (e.g. not right after the build), nor does
>     this seem to be a new (Cython) feature...
>
> If a doctest for a cython file fails in alpha3 then I get a leftover
> sage/misc/__homedir_hostname_nn_pyx.html file. Is that what you are
> talking about?

I've seen such files there (don't recall whether only there), although
no doctests failed.

There are sometimes(?) also just their C counterparts, which are ignored
by Mercurial, so you usually won't see them.

But anyway, no doctest should write into that directory.

They seem to arise from doctesting sage/misc/cython.py, or at least that is the case for the files that I see.  I wonder if it's related to http://trac.sagemath.org/sage_trac/ticket/9739 somehow.

I don't know why these files would start popping up in this release.

I've changed my mind: I'm pretty sure that this is due to <http://trac.sagemath.org/sage_trac/ticket/11680>.

--
John

[Keshav Kini]

I get nothing after a build from source on my own machine. However, on sage.math and with the sage.math-specific binary, I get this:

keshav@sage ~/tmp/sage-4.7.2.alpha3-sage.math.washington.edu-x86_64-Linux $ ~/check_queues.sh
Assuming SAGE_ROOT=/home/keshav/tmp/sage-4.7.2.alpha3-sage.math.washington.edu-x86_64-Linux
Queue in ./data/extcode:
Current status in ./data/extcode:
Queue in ./local/bin:
Current status in ./local/bin:
Queue in ./devel/sagenb-main:
Current status in ./devel/sagenb-main:
Queue in ./devel/sage-main:
Current status in ./devel/sage-main:
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_0_pyx.html
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_1_pyx.html
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_2_pyx.html
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_0_pyx.html
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_1_pyx.html
? sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_2_pyx.html
Queue in ./examples:
Current status in ./examples:
Queue in .:
Current status in .:
keshav@sage ~/tmp/sage-4.7.2.alpha3-sage.math.washington.edu-x86_64-Linux $

-Keshav

[leif]

Keshav Kini wrote:
> I get nothing after a build from source on my own machine. However, on
> sage.math and with the sage.math-specific binary, I get this:
>

> Current status in ./devel/sage-main:
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_0_pyx.html
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_1_pyx.html
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_2_pyx.html
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_0_pyx.html
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_1_pyx.html
> ?
> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_2_pyx.html

Yep, John Palmieri found the culprit.

This is easily fixed by a half-line patch to sage/misc/cython.py, for
which I'll open a follow-up ticket (to #11680, see comments there).

Thanks for bringing this up, I missed that in the "final" alpha3 (as
there were previously other left-around files I fixed)... ;-)

[leif]

leif wrote:
> Keshav Kini wrote:
>> I get nothing after a build from source on my own machine. However, on
>> sage.math and with the sage.math-specific binary, I get this:
>>
>> Current status in ./devel/sage-main:
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_0_pyx.html
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_1_pyx.html
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_10769_tmp_2_pyx.html
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_0_pyx.html
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_1_pyx.html
>> ?
>> sage/misc/__scratch_leif_merger_sage_4_7_2_alpha3_home__sage_temp_sage_math_washington_edu_28366_tmp_2_pyx.html
>
> Yep, John Palmieri found the culprit.
>
> This is easily fixed by a half-line patch to sage/misc/cython.py, for
> which I'll open a follow-up ticket (to #11680, see comments there).

This is now #11887 [1].

-leif

[1] http://trac.sagemath.org/sage_trac/ticket/11887

[Dima Pasechnik]

yes, that's what we get:

$ hg stat? sage/misc/__home_dima__sage_temp_spms_banana_3139_tmp_0_pyx.html

? sage/misc/__home_dima__sage_temp_spms_banana_3139_tmp_1_pyx.html

? sage/misc/__home_dima__sage_temp_spms_banana_3139_tmp_2_pyx.html

[Nathann Cohen]

Hello !!!

All tests passed on a 64 bits machine runnig Fedora 12, but I have not been able to *build* Sage on my own laptop or on my lab's computer O_o

Both machines are 32 bits with processors Intel Core2 Duo :

    * One is running Fedora 14 

    * The other one runs debian unstable (laptop)

The problem happens when building mpir. The log file for the Fedora machine can be found there :

http://www-sop.inria.fr/members/Nathann.Cohen/install.log

And for the debian machine :

http://www-sop.inria.fr/members/Nathann.Cohen/install_laptop.log

When compiling, I set $SAGE_PARALLEL_SPKG_BUILD, $SAGE_VALGRIND and $MAKE to "" 

Nathann

[leif]

Nathann Cohen wrote:
> I have not
> been able to *build* Sage on my own laptop or on my lab's computer O_o
>
> Both machines are 32 bits with processors Intel Core2 Duo :
> * One is running Fedora 14
> * The other one runs debian unstable (laptop)
>
> The problem happens when building mpir.

Doing

$ export ABI=32
$ make

solves the issue.

I'll fix that in a new MPIR spkg though, in the hopefully near future.

-leif

[kcrisman]

Passes all tests except matrix/matrix2.pyx and rings/polynomial/
polynomial_element.pyx on PPC OS X 10.4.11. Plus the usual Maxima
timeout.

I think these will be the same as on the prerelease, but I can copy
their output later after I rerun them, if you'd like.

- kcrisman

[leif]

Ooops, I didn't have results for MacOS X on PPC. Please post the output
in case you rerun the tests. (You could also search for "^Got" in
testlong.log / ptestlong.log if you kept it.)

I've relaxed one noisy zero which was still too large on MacOS X 10.6.8
x86_64 (bsd.math), so I didn't expect any noise errors for the "final"
Sage 4.7.2.alpha3.

I've also tested on Linux PPC64 (POWER7), but there a lot goes wrong
(mainly due to a partially broken ECL and Maxima I think), including
some noise I didn't see on any of the other platforms, e.g. ones that
don't match "1.00..." because they are slightly *less* than one.

[leif]

leif wrote:
> I've also tested on Linux PPC64 (POWER7), but there a lot goes wrong
> (mainly due to a partially broken ECL and Maxima I think), including
> some noise I didn't see on any of the other platforms, e.g. ones that
> don't match "1.00..." because they are slightly *less* than one.

P.S.: The following tests even timeout when run individually (with the
default timeout of half an hour on a quite fast box) in my current build:

sage -t -long -force_lib sage/rings/real_mpfi.pyx # Time out
sage -t -long -force_lib sage/rings/polynomial/polynomial_element.pyx #
Time out
sage -t -long -force_lib
sage/rings/number_field/number_field_element.pyx # Time out
sage -t -long -force_lib sage/sage/rings/number_field/number_field.py #
Time out

Interestingly also sandpile takes a long time, although this is SUSE
Linux Enterprise Server 11 SP1 (ppc64), Kernel version
2.6.32.43-0.4-ppc64 and not Ubuntu.

The other failing doctests are in:

sage/misc/functional.py # 1 doctests failed
(failing MPFR assertion)
sage/interfaces/qepcad.py # 2 doctests failed
(two funny errors)
sage/plot/plot3d/list_plot3d.py # 2 doctests failed
(two times "ValueError: negative dimensions are not allowed" in
list_plot3d())

Note that there are further doctest errors in the files which timeout,
i.e., before tests start to hang.

[kcrisman]

> Ooops, I didn't have results for MacOS X on PPC. Please post the output
> in case you rerun the tests. (You could also search for "^Got" in
> testlong.log / ptestlong.log if you kept it.)

Dasher-03:~/Desktop/sage-4.7.2.alpha3 student$ ./sage -t -long "devel/
sage/sage/matrix/matrix2.pyx" "devel/sage/sage/rings/polynomial/
polynomial_element.pyx"
sage -t -long "devel/sage/sage/matrix/matrix2.pyx"
**********************************************************************
File "/Users/student/Desktop/sage-4.7.2.alpha3/devel/sage/sage/matrix/
matrix2.pyx", line 4648:
sage: eigenvectors = em[1]; eigenvectors
Expected:
[ 0.440242867... 0.567868371... 0.695493875...]
[ 0.897878732... 0.278434036... -0.341010658...]
[ 0.408248290... -0.816496580... 0.408248290...]
Got:
[-0.440242867236 -0.567868371314 -0.695493875393]
[-0.897878732262 -0.278434036822 0.341010658618]
[ 0.408248290464 -0.816496580928 0.408248290464]
**********************************************************************
File "/Users/student/Desktop/sage-4.7.2.alpha3/devel/sage/sage/matrix/
matrix2.pyx", line 4907:
sage: eigenvectors = em[1]; eigenvectors
Expected:
[ 0.164763817... 0.799699663... 0.408248290...]
[ 0.505774475... 0.104205787... -0.816496580...]
[ 0.846785134... -0.591288087... 0.408248290...]
Got:
[-0.164763817282 -0.799699663112 0.408248290464]
[-0.505774475901 -0.104205787719 -0.816496580928]
[-0.846785134519 0.591288087674 0.408248290464]
**********************************************************************
2 items had failures:
1 of 41 in __main__.example_58
1 of 27 in __main__.example_59
***Test Failed*** 2 failures.
For whitespace errors, see the file /Users/student/.sage//tmp/
matrix2_26740.py
[217.9 s]
sage -t -long "devel/sage/sage/rings/polynomial/
polynomial_element.pyx"
**********************************************************************
File "/Users/student/Desktop/sage-4.7.2.alpha3/devel/sage/sage/rings/
polynomial/polynomial_element.pyx", line 1038:
sage: parent(poly)([ 0.0 if abs(c)<=2.5e-15 else c for c in
poly.coeffs() ])
Expected:
1.0
Got:
2.6645352591e-15*x + 1.0
**********************************************************************
1 items had failures:
1 of 18 in __main__.example_20
***Test Failed*** 1 failures.
For whitespace errors, see the file /Users/student/.sage//tmp/
polynomial_element_26747.py
[104.7 s]

----------------------------------------------------------------------
The following tests failed:


sage -t -long "devel/sage/sage/matrix/matrix2.pyx"
sage -t -long "devel/sage/sage/rings/polynomial/
polynomial_element.pyx"

[Dan Drake]

Here's a new error I found with 4.7.2.alpha3: the assembler fails when
building MPIR on Ubuntu Oneiric. The log file is attached, and here's
/proc/cpuinfo for the 32-bit virtual machine I'm running this inside:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
stepping : 10
cpu MHz : 2666.546
cache size : 6144 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx lm constant_tsc up pni monitor ssse3 lahf_lm
bogomips : 5333.09
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

Any ideas?

Dan

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

[leif]

Any ideas? Reading one of the recent messages for example? ;-)

The simple solution is to

$ export ABI=32

Then run 'make' again.

[Bill Hart]

You have ABI=64 but you've got -m32 in your compiler flags. If you
pass -m32 you need to also pass ABI=32.

Bill.

[Dan Drake]

On Tue, 04 Oct 2011 at 04:43AM +0200, leif wrote:
> Any ideas? Reading one of the recent messages for example? ;-)
>
> The simple solution is to
>
> $ export ABI=32
>
> Then run 'make' again.

Ack. Sorry for the noise! I wasn't paying attention to that discussion.
MPIR builds fine with ABI=32.

[Rob Beezer]

The point of these tests was to demonstrate the "best" way to get
eigenstuff for matrices with inexact entries from the reals or
complexes. So it would be good to fix the "test" part without totally
obscuring the "doc" part.

The columns (or rows) of these matrices are eigenvectors. We could
force the first entry to be positive by massaging each row or column.
Or we could convert the test to something more functional - showing
each row or column to act like an eigenvector (Ax=\lambda x) or doing
a wholesale test like this with the relevant matrices (and testing for
a small norm on a matrix difference). However, this all just obscures
the presence of the floating point numbers that are most evident when
just outputting the matrix itself.

Sentiments?

[John Cremona]

On Tue, Oct 4, 2011 at 6:20 AM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> The point of these tests was to demonstrate the "best" way to get
> eigenstuff for matrices with inexact entries from the reals or
> complexes.  So it would be good to fix the "test" part without totally
> obscuring the "doc" part.
>
> The columns (or rows) of these matrices are eigenvectors.  We could
> force the first entry to be positive by massaging each row or column.
> Or we could convert the test to something more functional - showing
> each row or column to act like an eigenvector (Ax=\lambda x) or doing
> a wholesale test like this with the relevant matrices (and testing for
> a small norm on a matrix difference).  However, this all just obscures
> the presence of the floating point numbers that are most evident when
> just outputting the matrix itself.
>
> Sentiments?
>

This is a common and recurring issue with Sage's doctests, which are
simultaneously doing two different things: (1) tests to make sure that
behaviour is (exactly) as expected, and (2) examples of common usage.
We reflect this by having sections named EXAMPLES and TESTS (which are
sometimes both used) but both are treated the same way by the testing
system. Rob wants to keep the functionality (2) -- certainly a good
idea! -- even when achieving (1) is hard because of numerical issues.

John

[leif]

Then in some cases it would be necessary to duplicate the code to have a
'# not tested' (or '# random') example in the EXAMPLES section, and an
"obscured" (or different but [almost] equivalent) version in the TESTS
section.

I wouldn't mind that, since much code already gets almost unreadable (to
me) because of lengthy docstrings sometimes spanning multiple pages such
that the actual code (the implementation), often just a few lines,
drowns in these (if you don't use a folding editor). :-)

One would have to take care to keep examples and tests in sync of course.

Note that /some/ problems due to *noise* (not the failing eigenvectors
example) can now be fixed in an easier way, without ellipses (and even
cases where ellipses won't suffice), with Robert Bradshaw's '# tol ...'
tags (for specifying absolute or relative tolerance). [John Palmieri
polished the code. See #10952, merged into Sage 4.7.2.alpha3.]

[kcrisman]

On Oct 4, 6:01 am, leif <not.rea...@online.de> wrote:
> John Cremona wrote:
> > On Tue, Oct 4, 2011 at 6:20 AM, Rob Beezer <goo...@beezer.cotse.net> wrote:
> >> The point of these tests was to demonstrate the "best" way to get
> >> eigenstuff for matrices with inexact entries from the reals or
> >> complexes.  So it would be good to fix the "test" part without totally
> >> obscuring the "doc" part.

I don't have any opinion on this one. So just ping me offlist if you
have a patch to test for this, as you or others are able. I don't
read all sage-release posts through all the way if my RSS feed doesn't
indicate it's relevant to a platform or component I know much about.

- kcrisman

[leif]

Dan Drake wrote:
> On Tue, 04 Oct 2011 at 04:43AM +0200, leif wrote:
>> Any ideas? Reading one of the recent messages for example? ;-)
>>
>> The simple solution is to
>>
>> $ export ABI=32
>>
>> Then run 'make' again.
>
> Ack. Sorry for the noise! I wasn't paying attention to that discussion.
> MPIR builds fine with ABI=32.

An MPIR 2.1.3.p5 spkg fixing this (i.e., automatically setting ABI) is
now available at #11896 [1], currently needing review.

-leif

[1] http://trac.sagemath.org/sage_trac/ticket/11896

[Rob Beezer]

On Oct 4, 1:41 am, John Cremona <john.crem...@gmail.com> wrote:
> This is a common and recurring issue with Sage's doctests,

<snip>

> Rob wants to keep the functionality (2) -- certainly a good
> idea! -- even when achieving (1) is hard because of numerical issues.

John and Leif,

Thanks for the replies which helped crystalize my approach to this
one.

Original DOCtest has been marked "not tested" and I copied the docTEST
into a TEST section for the routine where it belongs and jumped
through the hoops that I hope will fix it on the minority hardware.

Details at: http://trac.sagemath.org/sage_trac/ticket/11897

with a cc to kcrisman, et al.

Thanks,
Rob

[leif]

davidloeffler wrote:
> For what it's worth, all other spkg test suites and the Sage tests
> (including long) pass.
>
> David
>
> On Sep 29, 7:51 pm, leif <not.rea...@online.de> wrote:
>> davidloeffler wrote:
>>> I tried building this (on 64-bit Linux) with "SAGE_CHECK" set. The
>>> python spkg failed tests, but it always has done for me. What's new is
>>> that testing Flint also failed: it wouldn't build the Flint test suite
>>> (let alone run it). I've done this in the past without failures, so it
>>> must be something fishy in the Flint 1.5.0.p9 spkg. The relevant
>>> install.log snippet is below -- I can post the whole install.log if
>>> necessary. Is this a known failure, or shall I open a new trac ticket?
>>
>> This is a (unfortunately) very well-known issue, at least to me. ;-)
>>
>> See http://trac.sagemath.org/sage_trac/ticket/9858
>>
>> I haven't had the time to provide a FLINT 1.5.2 (or 1.6) spkg yet, i.e.
>> still have to rebase my changes on those others made to the 1.5.0 spkg
>> inbetween.
>>
>> This will certainly be fixed in the final 4.7.2.

Since my FLINT 1.5.2 spkg still takes some time, I've made a FLINT
1.5.0.p10 spkg [1] which just fixes the trivial test suite build error.

See #9858 [2].

Please build (with SAGE_CHECK=yes, and Sage 4.7.2 *alpha3* of course),
test and report (i.e., review on the ticket)!

Thanks,

-leif

[1]
http://sage.math.washington.edu/home/leif/Sage/spkgs/flint-1.5.0.p10.spkg
(md5sum 907a720d1b9bf9e4bc1412e08b2f8892)

[2] http://trac.sagemath.org/sage_trac/ticket/9858