Where are the pre-release prereleases?
kcrisman
and http://sage.math.washington.edu/home/release/sage-4.7.2.alpha3/
seem empty. I have some folks hankerin' to download alpha3 (because
it has some goodies in it) but it doesn't seem to exist, currently.
Any ETA, or at least the "unofficial" version?
Thanks!
- kcrisman
Volker Braun
leif
> Both http://sage.math.washington.edu/home/release/sage-4.7.2.alpha3-old/
> and http://sage.math.washington.edu/home/release/sage-4.7.2.alpha3/
> seem empty.
They (still) are, almost.
> I have some folks hankerin' to download alpha3 (because
> it has some goodies in it) but it doesn't seem to exist, currently.
> Any ETA, or at least the "unofficial" version?
FOR THE IMPATIENT ONLY... ;-)
The current alpha3 *prerelease* can be found here:
http://sage.math.washington.edu/home/leif/Sage/release/sage-4.7.2.alpha3-prerelease/
There's a source tarball (and its md5sum) as well as the "source tree"
for upgrading:
md5sum (version of Sept. 19th): ad021855ae07ecdd1cdcc7b973c9cdba
http://sage.math.washington.edu/home/leif/Sage/release/sage-4.7.2.alpha3-prerelease/sage-4.7.2.alpha3-prerelease/
(Upgrade path, not really tested.)
I've also put all new *optional* spkgs into that directory, as these are
not part of the tarball, nor yet downloadable from the usual location:
http://sage.math.washington.edu/home/leif/Sage/release/sage-4.7.2.alpha3-prerelease/database_cremona_ellcurve-20110915.spkg
(This is just a *larger* database compared to the one part of the
standard elliptic_curves-0.3 spkg contained in the tarball.)
There's also an updated PolyBoRi spkg (0.7.1.p6) which isn't yet
included into the tarball (the p5 is of course), but that one is only
required on non-Intel/AMD (non-x86/x86_64) platforms, e.g. SPARC, maybe
Itanium, most probably also PowerPC (haven't tried yet):
Note that a few (1 to 5, or 8, depending on the platform) doctests are
known to fail at the moment (in three / four different files), due to
numerical noise, on "rare" or old platforms (SunOS / Solaris SPARC,
Linux ia64 (Itanium), Linux x86 (Pentium4 at least), and -- a bit
strange -- Debian x86_64 on a Sandy Bridge Core i3).
Rob Beezer just reported three doctests segfaulting (in ATLAS /
libpthread) on a Core i7 2600 running some Ubuntu/Linaro x86_64. We
couldn't yet track this further down.
Also, this prerelease is inofficial and *volatile*, and hence should be
treated as such, although I currently don't expect any tickets to get
*unmerged* again. (More likely, besides fixing at least some of the
doctest errors, I'll include further tickets, but -- if at all -- only
very few, and only "easy" ones.)
Please don't complain about any failures on Apple boxes (running MacOS X
10.x), as I couldn't test on such yet.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
kcrisman
> Please don't complain about any failures on Apple boxes (running MacOS X
> 10.x), as I couldn't test on such yet.
or similar to other failures you know of. This is on OS X 10.6.
- kcrisman
sage -t -long -force_lib "devel/sage/sage/matrix/matrix2.pyx"
**********************************************************************
File "/Users/.../sage-4.7.2.alpha3-prerelease/devel/sage/sage/matrix/
matrix2.pyx", line 4644:
sage: eigenvalues = em[0]; eigenvalues
Expected:
[ 13.3484692... 0 0]
[ 0 -1.34846922... 0]
[ 0 0 -6.2265089...e-16]
Got:
[ 13.3484692283 0 0]
[ 0 -1.34846922835 0]
[ 0 0 -6.20220383126e-16]
**********************************************************************
1 items had failures:
1 of 41 in __main__.example_58
[33.4 s]
sage -t -long -force_lib "devel/sage/sage/rings/polynomial/
polynomial_element.pyx"
**********************************************************************
File "/Users/.../sage-4.7.2.alpha3-prerelease/devel/sage/sage/rings/
polynomial/polynomial_element.pyx", line 1026:
sage: f * (x^2 + 1) % (x^5 + x + 1)
Expected:
1.0
Got:
1.11022302463e-16*x^4 + 1.11022302463e-16*x^2 + 1.0
**********************************************************************
File "/Users/.../sage-4.7.2.alpha3-prerelease/devel/sage/sage/rings/
polynomial/polynomial_element.pyx", line 1034:
sage: f*g % m
Expected:
-8.881784...e-16*x^3 + 8.881784...e-16*x^2 - 8.881784...e-16*x +
1.0
Got:
-1.33226762955e-15*x^3 + 2.22044604925e-15*x^2 +
4.4408920985e-16*x + 1.0
**********************************************************************
1 items had failures:
2 of 16 in __main__.example_20
[12.4 s]
Volker Braun
leif
>
>> Please don't complain about any failures on Apple boxes (running MacOS X
>> 10.x), as I couldn't test on such yet.
>
> No complaints, but I might as well report, in case these are the same
> or similar to other failures you know of.
Of course, thanks.
Yes, they are, i.e., the same doctests failing (due to numerical noise)
as on some other systems as well.
-leif
leif
> Note that a few (1 to 5, or 8, depending on the platform) doctests are
> known to fail at the moment (in three / four different files), due to
> numerical noise, on "rare" or old platforms (SunOS / Solaris SPARC,
> Linux ia64 (Itanium), Linux x86 (Pentium4 at least), and -- a bit
> strange -- Debian x86_64 on a Sandy Bridge Core i3).
P.S.: OTOH, all failures are due to noisy *zeroes* only.
Doctests (are known to) fail in:
* sage/misc/preparser.py (IA64 / Itanium 2 only; signed zero)
* sage/matrix/matrix2.pyx
* sage/matrix/matrix_double_dense.pyx
* sage/rings/polynomial/polynomial_element.pyx
Volker Braun
P.S.: OTOH, all failures are due to noisy *zeroes* only.
leif
> On Thursday, September 22, 2011 5:43:14 PM UTC+1, leif wrote:
>
> P.S.: OTOH, all failures are due to noisy *zeroes* only.
>
> Thats because the doctests framework can handle random noise around a
> non-zero constant just fine using ellipses. But that breaks when you
> have random noise around zero, 6.123...e-16 is just crap without any
> significant digit.
Ach nee?! Sag' blo�!!1! ;-)
Unfortunately for dense RDF / CDF matrices only, we have the nice
.zero_at(epsilon) method.
> We need to make the doctester smarter to understand
> random noise around zero, this
> is http://trac.sagemath.org/sage_trac/ticket/10952
Yep, I know that ticket...
Volker Braun
> is http://trac.sagemath.org/sage_trac/ticket/10952
Yep, I know that ticket...
John H Palmieri
To be fair, I would say that before the most recent patch, it was a really ugly shed.
--
John
Volker Braun
To be fair, I would say that before the most recent patch, it was a really ugly shed.
leif
I don't think it is [yet] powerful enough to solve all of the failures;
we'll have to mess up at least some examples / tests "manually" (i.e.,
without simply tagging them), unfortunately.
I've not yet decided whether to fix the failures by reviewer patches on
the corresponding tickets, or, unconventional but IMHO easier, open just
one ticket to solve all of them at once, to be merged / applied on top
of the current prerelease.
The disadvantage of the latter procedure is that the authors and
reviewers of the tickets that introduced the doctest errors won't get
the <del>punishment</del> <ins>feedback</ins> they deserve...
-leif
P.S.: IIRC now, there were indeed also very few where the periods aren't
sufficiently placed, i.e., failures not due to just a noisy zero.
leif
Except for the two in sage/matrix/matrix2.pyx, these should now all be
fixed by reviewer patches to #7852 and #10635; require #11848 as well.
(Thanks, Rob.)
Patch for the remaining ones (caused by #11595) coming soon.
leif
Reviewer patch is attached to #11595; all known doctest errors fixed now.
Jeroen Demeyer
errors!
leif
noise fixes.
Please report any build errors and doctest failures.
Tarball:
md5sum: fcd35ecfe81337367c3ce42bd4abbd1d
Upgrade path:
sage.math binary:
md5sum: 338b71a8df7d26ef7e7a965273275017
Ticket overview (starting with the alpha0):
http://sage.math.washington.edu/home/leif/Sage/release/sage-4.7.2.alpha3-prerelease/tickets.html
New *optional* spkgs (not included in the tarball):
Finally:
http://sage.math.washington.edu/home/leif/Sage/release/sage-4.7.2.alpha3-prerelease/README.txt
Jeroen Demeyer
sage-4.7.2.alpha3-prelease1 == sage-4.7.2.alpha3
sage-4.7.2.alpha3-prelease2 == sage-4.7.2.alpha4
sage-4.7.2.alpha3-prelease3 == sage-4.7.2.rc0
sage-4.7.2.alpha3 == sage-4.7.2
Making preleases of prereleases (and asking people to test them) looks a
bit silly to me.
Jeroen.
John Cremona
I agree that this is confusing. Yesterday I built alpha2, necessary
to do some testing of tickets, and if there were now an alpha3 I would
build that. But I don't understand this naming system -- everything
you say about the prereleases surely applies to any alpha, by
definition?
Obviously I do much appreciate the hard work that goes into release
management, and you can do whatever makes that job easier for you, but
the rest of us have to understand what you are doing!
John
>
> Jeroen.
>
> --
> 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.
>
>