Upgrade PARI to 2.7.1

[jdemeyer]

Upstream: ​http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.7.1.tar.gz

Updated (changes have always been made directly in the source tarball and the package will be removed anyway in #15808): ​http://boxen.math.washington.edu/home/jdemeyer/spkg/genus2reduction-20140211.tar.bz2

[pbruin]

Good plan; there have been quite a few changes (also in the interface) from 2.5 to 2.6, but 2.7 (being a stable release) will be close to 2.6.2.

[jdemeyer]

New commits:

​17f864c	Remove mp.c.patch; instead call init_memory_functions()
​ad63daf	Move PARI databases out of PARI package
​1678b89	Merge remote-tracking branch 'origin/develop' into ticket/15765
​bfdad13	Merge branch 'u/jdemeyer/ticket/15765' of git://trac.sagemath.org/sage into ticket/15774
​0595a42	Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​6de648b

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​5b823f1

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​5cb3478

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​84c081c

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​8e2cc9e

Upgrade to PARI 2.6.2

[jdemeyer]

This version compiles fine, but there are about a million doctest failures :-(

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​19b2936

Upgrade to PARI 2.6.2

[jdemeyer]

This is a serious regression:

sage: EllipticCurve('90c3').integral_points(both_signs=False)
[(-15 : 7 : 1), (1 : 39 : 1), (21 : 79 : 1)]

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​52e24d0

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​b780916

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​9cb3ae7

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​7ee964c

Upgrade to PARI 2.6.2

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​b919439	Merge branch 'ticket/15774' into pari27
​73f51cd	Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​6091d59

Upgrade to PARI 2.7

[pbruin]

I know this isn't ready yet; I was just browsing the branch to see how many changes need to be made. Are you sure the following is correct? I think the purpose of the ellinit() call is to allow the user to specify the curve in short Weierstrass form (ellinit([a, b]) --> y^2 = x^3 + a*x + b).

@@ -1903,7 +1903,7 @@ bnfellrank(bnf,ell,help=[],bigflag=1,flag3=1) =
local(urst,urst1,den,factden,eqtheta,rnfeq,bbnf,ext,rang);
if( DEBUGLEVEL_ell >= 3, print("entree dans bnfellrank"));
- if( #ell <= 5, ell = ellinit(ell,1));
+ ell = vector(5, i, ell[i]);
\\ removes the coefficients a1 and a3
urst = [1,0,0,0];

[jdemeyer]

Replying to pbruin:

I know this isn't ready yet; I was just browsing the branch to see how many changes need to be made. Are you sure the following is correct? I think the purpose of the ellinit() call is to allow the user to specify the curve in short Weierstrass form (ellinit([a, b]) --> y^2 = x^3 + a*x + b).

@@ -1903,7 +1903,7 @@ bnfellrank(bnf,ell,help=[],bigflag=1,flag3=1) =
local(urst,urst1,den,factden,eqtheta,rnfeq,bbnf,ext,rang);
if( DEBUGLEVEL_ell >= 3, print("entree dans bnfellrank"));
- if( #ell <= 5, ell = ellinit(ell,1));
+ ell = vector(5, i, ell[i]);
\\ removes the coefficients a1 and a3
urst = [1,0,0,0];

OK, I see what you mean. We could change it to

ell = ellinit(ell);
ell = vector(5, i, ell[i]);

[jdemeyer]

We could also try to merge #11005 first, maybe that helps.

[pbruin]

Replying to jdemeyer:

We could also try to merge #11005 first, maybe that helps.

OK, I'll take a look at that one.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​01c76a3

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​24b6fe9	Update Denis Simon's GP scripts to versions of 06/04/2011 (ell.gp)
​bc6f612	Merge branches 'ticket/15774' and 'ticket/11005' into pari27
​1db424e	Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​802a31f

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​2964947

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​9cc4af7

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​1b06004

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​14a8548

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f36fba5

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​834368d

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​4829125

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​4f040c8

Merge remote-tracking branch 'origin/develop' into ticket/15767

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​27897d3

PARI 2.7 doctest fixes

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​ac97322

PARI 2.7 doctest fixes

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​c80cf8b

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​94d14a2

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​d08c8fc

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​44c0f87

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​988c1f8	Improve conversion of complex numbers to PARI
​09dea99	Merge branch 'ticket/15888' into ticket/15767
​bedb19a	Doctest fixes for PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​0e4fff5	Clean up weierstrass_p function
​666714e	Fix changelog entry for ell_wp
​d6fdd0c	CC->PARI: convert purely imaginary numbers to t_COMPLEX with real part exactly 0
​2af767a	Merge branches 'ticket/15855' and 'ticket/15888' into ticket/15767
​6a5539f	Upgrade to PARI 2.7

[jdemeyer]

New commits:

​0e4fff5	Clean up weierstrass_p function
​666714e	Fix changelog entry for ell_wp
​d6fdd0c	CC->PARI: convert purely imaginary numbers to t_COMPLEX with real part exactly 0
​2af767a	Merge branches 'ticket/15855' and 'ticket/15888' into ticket/15767
​6a5539f	Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​1a12d09

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​5467494

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​3970e57

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​e37b3ee	Merge branch 'ticket/15888' into ticket/15767
​ae1ae57	Upgrade to PARI 2.7

[jdemeyer]

New commits:

​e37b3ee	Merge branch 'ticket/15888' into ticket/15767
​ae1ae57	Upgrade to PARI 2.7

[jpflori]

Hi Jeroen,

What's the status of this? Are there still hundreds of failing stuff? With the forced pushes its not that easy to see how the situtation evolves. And I've not tested it yet.

Whatsoever, thanks for the hard work.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f6a149b

Upgrade to PARI 2.7

[jdemeyer]

Replying to jpflori:

Hi Jeroen,

What's the status of this? Are there still hundreds of failing stuff? With the forced pushes its not that easy to see how the situtation evolves. And I've not tested it yet.

It's almost ready. The announcement of the PARI-2.7 release candidate gave me a good reason to finish this ticket. Sage doctests found many (10 or so) bugs in PARI, all of which have been fixed upstream.

The forced pushes are the most convenient way to develop this, otherwise I would have 100 commits and several merges in between. I will now look into the remaining doctest failures.

[jpflori]

Sure, I wasn't criticizing your way of doing things. Just get a status report if possible at this point and know if it's worth having a look at it and potentially give you a hand.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​7067299	CC->PARI conversion: fix doctest failures
​42dc2e1	Merge commit '70672995f7b2e1b87d4d3' into ticket/15767
​a6e2f9d	Upgrade to PARI 2.7

[jdemeyer]

This passes 64-bit doctests for me. Now building a 32-bit version to check that...

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​b321ea3

Upgrade to PARI 2.7

[fbissey]

Hi,

I didn't see any changes in spkg-install in the last commit. Is there any? I am asking because in #16017 we noticed that pari doesn't have the right install_name for OS X. It turns out ​http://trac.sagemath.org/ticket/16017#comment:43 that it is caused by cruft in spkg-install. I don't think it has any value and I am wondering if you could remove it as a part of this ticket.

[jdemeyer]

Replying to fbissey:

Hi,

I didn't see any changes in spkg-install in the last commit. Is there any?

No, this ticket does not change spkg-install. So you should make the changes you propose either on #16017 or on a new ticket.

[jdemeyer]

Let me also give a general status of this ticket: the single one remaining issue is the following doctest failure on 32-bit:

sage -t --long src/doc/en/reference/coercion/index.rst
**********************************************************************
File "src/doc/en/reference/coercion/index.rst", line 65, in doc.en.reference.coercion.index
Failed example:
    f = EllipticCurve('37a').lseries().taylor_series(10); f
Expected:
    0.997997869801216 + 0.00140712894524925*z - 0.000498127610960097*z^2 + 0.000118835596665956*z^3 - 0.0000215906522442707*z^4 + (3.20363155418419e-6)*z^5 + O(z^6)
Got:
    -0.0000405744363329341 + 2.21638825958869*z - 2.40591010134898*z^2 + 1.70010490236379*z^3 - 0.876833052881789*z^4 + 0.350599228549426*z^5 + O(z^6)
**********************************************************************

The problem is that the result is totally wrong.

I have been busy with other things lately, so I haven't looked into this issue.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​ee9c845

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​1d9305b

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​082bceb

Upgrade to PARI 2.7

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​fd2bb15

Merge remote-tracking branch 'origin/develop' into ticket/15767

[pbruin]

Any progress on the remaining doctest failure? I don't have access to a 32-bit machine, otherwise I could try to look into it.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​2821016

Upgrade to PARI-2.7.1

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​1b38123

Upgrade to PARI-2.7.1

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​f26a0a0

Upgrade to PARI-2.7.1

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​5c076d6

Upgrade to pari-2.7.1-pre2

[jdemeyer]

New commits:

​5c076d6

Upgrade to pari-2.7.1-pre2

[pbruin]

Are there any obstacles to finishing this ticket soon?

[jdemeyer]

Only 70...

[Snark]

Good news, I found one of my boxes is able to reproduce the problem of comment 70. Now I need to dig what happens... first step would be trying to see if I can reproduce it in gp, because at that point that could also be an upstream issue.

[Snark]

Using ~/.sage/dokchitser.log, I was able to check the computation against debian's pari-gp package, and find there is the same discrepancy between amd64 and i386, so I reported a problem in debian.

[pbruin]

I can reproduce this inside GP 2.7.1 (patched version of this ticket) on ARM using the following commands (also adapted from dokchitser.log):

read("local/share/sage/ext/pari/dokchitser/computel.gp");
default(realprecision, 19);
conductor = 37;
gammaV = [0, 1];
weight = 2;
sgn = -1;
Lpoles = [];
Lresidues = automatic;
e = ellinit([0, 0, 1, -1, 0]);
a(k) = ellak(e, k);
initLdata("a(k)", 1.0);
v = Vec(Lseries(10.0, , 5));
print(v)

One gets the correct answer after replacing 19 by 20 in the second line, presumably because this increases the precision by one word.

[pbruin]

According to git bisect, the bug is triggered by the following upstream change (PARI Git commit 8cfb9c6b, incorrect rounding in mulur):

src/kernel/none/mp_indep.c

@@ -143 +143 @@
   y--; garde = mulll(x,y[lx]);
   for (i=lx-1; i>=3; i--) z[i]=addmul(x,y[i]);
   z[2]=hiremainder; /* != 0 since y normalized and |x| > 1 */
-
   sh = bfffo(hiremainder); m = BITS_IN_LONG-sh;
   if (sh) shift_left(z,z, 2,lx-1, garde,sh);
-  z[1] = evalsigne(s) | evalexpo(m+e); return z;
+  z[1] = evalsigne(s) | evalexpo(m+e);
+  if ((garde << sh) & HIGHBIT) roundr_up_ip(z, lx);
+  return z;
 }
 
 INLINE GEN

[pbruin]

It seems to me that the function SeriesToContFrac in Dokchitser's computel program is affected by some numerical instability, so that the above rounding fix in PARI leads to wildly different output of this function for the same input. It is probably possible to solve (or at least diminish) the problem by increasing the variable asympdigits in the script.

[Snark]

Indeed that's what Bill Allombert answered to my bug report in debian: the pari code is correct, and the computeL code looks like it uses catastrophic cancellation... hence it should really shoot for more precision. Either by increasing asymdigits at Peter suggests, or (notice that the following only solves that one example) change the line in dokchitser.py which sets the realprecision to prec//3+2 to prec//3+3.

[pbruin]

This seems to be a minimal fix:

src/ext/pari/dokchitser/computel.gp

@@ -297 +297 @@
   while (1,
     res=concat(res,[vec[1]]);
     ind=0;
-    until(ind==length(vec) || abs(vec[ind+1])>10^-asympdigits,ind++;vec[ind]=0);
+    until(ind==length(vec) || abs(vec[ind+1])>10^(-asympdigits-1),ind++;vec[ind]=0);
     if(ind>=length(vec),break);
     res=concat(res,[ind]);
     vec=Vec(x^ind/Ser(vec));

There are also two doctest failures in elliptic_curves/ell_number_field.py and elliptic_curves/height.py (at least on 32-bit ARM), which appear to be related to simon_two_descent.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​1f8eb38

Upgrade to PARI-2.7.1

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​59a5064

Upgrade to PARI-2.7.1

[jdemeyer]

We have a new regression (in a doctest added by #8828):

sage: K.<a> = NumberField(x^3-2)
sage: E = EllipticCurve([0,0,0,0,a])
sage: E.gens()
[]

This used to return

sage: K.<a> = NumberField(x^3-2)
sage: E = EllipticCurve([0,0,0,0,a])
sage: E.gens()
[(1/3*a^2 + a + 5/3 : -2*a^2 - 4/3*a - 5/3 : 1)]

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​06dbe23

Upgrade to PARI-2.7.1

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​e5bdf4c

Upgrade to PARI-2.7.1

[pbruin]

Replying to jdemeyer:

We have a new regression (in a doctest added by #8828):

sage: K.<a> = NumberField(x^3-2)
sage: E = EllipticCurve([0,0,0,0,a])
sage: E.gens()
[]

This used to return

sage: K.<a> = NumberField(x^3-2)
sage: E = EllipticCurve([0,0,0,0,a])
sage: E.gens()
[(1/3*a^2 + a + 5/3 : -2*a^2 - 4/3*a - 5/3 : 1)]

The parameter lim1 for Simon's 2-descent program needs to be adjusted (default is 2, minimal value for which a point is found is now apparently 5):

src/sage/schemes/elliptic_curves/height.py

@@ -1800 +1800 @@
         This curve does have a point of good reduction whose canonical
         point is approximately 1.68::
 
-            sage: P = E.gens()[0]
+            sage: P = E.gens(lim1=5)[0]
             sage: P.height()
             1.68038085233673
             sage: P.has_good_reduction()

[pbruin]

Replying to pbruin:

The parameter lim1 for Simon's 2-descent program needs to be adjusted (default is 2, minimal value for which a point is found is now apparently 5):

Actually the same can be done much more efficiently using lim3 instead (with lim1 it needlessly increases the search bound for quartics that are not everywhere locally soluble):

src/sage/schemes/elliptic_curves/height.py

@@ -1800 +1800 @@
         This curve does have a point of good reduction whose canonical
         point is approximately 1.68::
 
-            sage: P = E.gens()[0]
+            sage: P = E.gens(lim3=5)[0]
             sage: P.height()
             1.68038085233673
             sage: P.has_good_reduction()

[pbruin]

The other remaining failure on 32-bit (see comment:94) is in the following doctest (in ell_number_field.py, introduced in #15483):

sage: K.<s> = QuadraticField(229)
sage: c4 = 2173 - 235*(1 - s)/2
sage: c6 = -124369 + 15988*(1 - s)/2
sage: E = EllipticCurve([-c4/48, -c6/864])
sage: E.simon_two_descent()
(0, 0, [])

This returns (1, 1, []) on 32-bit because a certain quartic is incorrectly determined to be locally soluble at infinity. It appears to be caused by polsturm being called on a polynomial whose precision is too low. This bug is similar to but different than the one in #15483, and seems somewhat harder to fix.

[pbruin]

It seems the above problem can be solved by computing the exact inequalities appearing in Sturm's method and checking them using the function nfrealsign() from the script. I am uploading a patch that I also sent to Denis Simon.

[pbruin]

Trac 15767: more exact Archimedean computations in ell.gp

[pbruin]

It seems that the link to the updated genus2red has broken.

[jpflori]

Yes indeed, note that I downloaded it a few days ago without problem.

[jdemeyer]

I have been away for 3 weeks without touching anything Sage-related, so I'm just coming back to this now.

Strange that the boxen link doesn't work anymore, even this gives a 404: ​http://boxen.math.washington.edu/home/jdemeyer (luckily, the directory on boxen still exists). Does anybody have a clue what could have caused this? If no, I should ask on sagemath-admins.

[pbruin]

Replying to jdemeyer:

Strange that the boxen link doesn't work anymore, even this gives a 404: ​http://boxen.math.washington.edu/home/jdemeyer (luckily, the directory on boxen still exists). Does anybody have a clue what could have caused this?

This could be relevant: ​https://groups.google.com/forum/#!topic/sage-devel/dhON2NJoSoc

[kcrisman]

The issue with the links is fixed, so perhaps it's time to review this (e.g. #16165 depends on this).

[jdemeyer]

Sure, I'll start with rebasing to the latest beta. Hold on...

[jdemeyer]

Replying to pbruin:

The parameter lim1 for Simon's 2-descent program needs to be adjusted (default is 2, minimal value for which a point is found is now apparently 5):

Do you happen to know the deeper reason why this needs to be changed?

I'll make the change in the doctest.

[jdemeyer]

Did you get any answers from Denis Simon yet?

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​5605a97

Upgrade to PARI-2.7.1

[pbruin]

Replying to jdemeyer:

Replying to pbruin:

The parameter lim1 for Simon's 2-descent program needs to be adjusted (default is 2, minimal value for which a point is found is now apparently 5):

Do you happen to know the deeper reason why this needs to be changed?

No, I only found this experimentally. I would guess some PARI number field function returns a more complicated or "unlucky" result than before in this example.

Did you get any answers from Denis Simon yet?

So far I didn't.

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​37fc8e8

Upgrade to PARI-2.7.1

[jdemeyer]

I rebased this ticket and added the fixes by Peter Bruin. It now again passes doctests on 64-bit.

[pbruin]

I am now running make ptestlong on ARM 32-bit.

[jdemeyer]

Tests pass on 32-bit Linux! Party!

[pbruin]

And all the developers rejoiced!

If you agree with the (small) changes in the reviewer patch, this ticket is good to go as far as I'm concerned.

[rws]

Fails on OpenSuSE 12.3:

sage -t --long src/sage/libs/pari/gen.pyx
**********************************************************************
File "src/sage/libs/pari/gen.pyx", line 2236, in sage.libs.pari.gen.gen.Ser
Failed example:
    pari(Mod(0, 7)).Ser()
Expected:
    O(x^16)
Got:
    Mod(0, 7) + O(x^16)
**********************************************************************
1 item had failures:
   1 of   9 in sage.libs.pari.gen.gen.Ser
    [1270 tests, 1 failure, 1.48 s]

[jdemeyer]

Replying to rws:

Fails on OpenSuSE 12.3

Indeed, the last commit broke this.

[pbruin]

Replying to rws:

Fails on OpenSuSE 12.3:

Ouch, that is my fault. The change to Ser() was the last thing I added to my reviewer patch; I tested everything that I thought might call this code, but inexplicably forgot to test the file itself. I'll fix the doctest.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​1d103da

Trac 15767: fix doctest in Ser()

[jdemeyer]

Peter, could you please add some documentation for the application of Sturm's Theorem in ell.gp? I checked the calculations by hand and it looks correct, but it would be nice to have the calculation as comment in the file.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​62ca821

Trac 15767: explain application of Sturm's theorem

[pbruin]

Replying to jdemeyer:

Peter, could you please add some documentation for the application of Sturm's Theorem in ell.gp? I checked the calculations by hand and it looks correct, but it would be nice to have the calculation as comment in the file.

Done in the above commit.

[jdemeyer]

Replying to pbruin:

Done in the above commit.

Nice.

[vbraun]

I'm getting merge failures, will release beta1 soon. Please merge with that release then.

[jdemeyer]

Replying to vbraun:

I'm getting merge failures, will release beta1 soon. Please merge with that release then.

OK, I will do that. Unfortunately, this ticket tends to give a lot of conflicts because it touches so much code (in a way which cannot really be avoided). For beta2, I hope you will give this ticket priority and ask other branches to merge with this.

[vbraun]

I've released beta1, if you can resolve the conflicts soon then I'll merge this as the first ticket.

[jdemeyer]

Done. I'm running doctests now to check that nothing got broken.

[pbruin]

This branch agrees (up to whitespace) with a merge I did. If it passes doctests, you can set it back to positive review.