0.7.1: new schedule
Hi, I have changed the schedule for scipy 0.7.1. I set up the release date for the first June. Ideally, I would like that all backports go into the 0.7.x branch within the end of next WE. Is that ok with everyone involved working on 0.7.x branch ? Some matlab IO problems have been fixed by Matthew, Pauli and Josef have backported some fixes in stats and special, and I have fixed everything I wanted to see fixed for 0.7.x. cheers, David
Thu, 21 May 2009 14:33:30 +0900, David Cournapeau wrote:
I have changed the schedule for scipy 0.7.1. I set up the release date for the first June. Ideally, I would like that all backports go into the 0.7.x branch within the end of next WE. Is that ok with everyone involved working on 0.7.x branch ? Some matlab IO problems have been fixed by Matthew, Pauli and Josef have backported some fixes in stats and special, and I have fixed everything I wanted to see fixed for 0.7.x.
Probably OK. However, several of the bugfixes to scipy.special have not been backported. I think at the following should be ported: -- bug fix for struve function 5465 5466 -- bug fix for AMOS bessel functions, fix negative orders 5516 5521 Also the new Bessel Iv implementation should maybe be ported... I'll try to find time for doing all this, though doing it by the end of next weekend may be a bit tight. -- Pauli Virtanen
Pauli Virtanen wrote:
Probably OK. However, several of the bugfixes to scipy.special have not been backported.
I think at the following should be ported:
-- bug fix for struve function 5465 5466
-- bug fix for AMOS bessel functions, fix negative orders 5516 5521
Those look easy enough, and they have tests. I can do the backport if you want, it should only take me a few minutes, David
Pauli Virtanen wrote:
Thu, 21 May 2009 14:33:30 +0900, David Cournapeau wrote:
I have changed the schedule for scipy 0.7.1. I set up the release date for the first June. Ideally, I would like that all backports go into the 0.7.x branch within the end of next WE. Is that ok with everyone involved working on 0.7.x branch ? Some matlab IO problems have been fixed by Matthew, Pauli and Josef have backported some fixes in stats and special, and I have fixed everything I wanted to see fixed for 0.7.x.
Probably OK. However, several of the bugfixes to scipy.special have not been backported.
I think at the following should be ported:
-- bug fix for struve function 5465 5466
I backported this one (r5764).
-- bug fix for AMOS bessel functions, fix negative orders 5516 5521
But not this one: the changes do not apply, there need to be other commits as well - even by importing assert_to_tol code as well for the tests to run, 5 tests are failing. David
Fri, 22 May 2009 14:51:36 +0900, David Cournapeau wrote: [clip]
But not this one: the changes do not apply, there need to be other commits as well - even by importing assert_to_tol code as well for the tests to run, 5 tests are failing.
I'd like to backport everything from trunk in scipy.special, except the following: 9600bcf... Revert "use np.power in rdist (test commit with bzr)" ff046c6... Do not detect Endianess in Cephes. 3a99ec1... Add test case for ndtr. The bzr commit was broken, and the ndtr/endianness fixes break other things. All other commits are bugfixes of some sort; no feature additions here. What are fixed is: #924 #803 - pbdv errors #503 - reimplementation of real Bessel I #854 - correct NaN returns for iv/jv/ etc when out-of-domain #853 - fix invalid return values from complex Bessel functions #623 - fix invalid return values from real Bessel J #852 - make Bessel zeros computable for orders > 100 Plus some minor documentation fixes. And also the following: - The special functions now raise warnings instead of printing to stderr, if the errprint toggle is enabled (it was and is disabled by default. - The real-valued jve, ive, yve, kve, and kv functions return now NAN when the result would be complex-valued. (Previously they returned the real part.) *** I have the stuff already backported here: http://github.com/pv/scipy-work/commits/work-0.7.x The differences to trunk are minimal: git diff --stat ..svn/trunk -- scipy/special scipy/special/cephes/mconf.h | 12 +++++++++++- scipy/special/tests/test_basic.py | 4 +++- 2 files changed, 14 insertions(+), 2 deletions(-) I used this script to do the backporting: http://www.iki.fi/pav/tmp/git-cherry-tree And it went like this: http://www.iki.fi/pav/tmp/special-rebase-trace.txt The -o mode of git-cherry-tree seems to be useful for keeping track of stuff to backport. BTW, do we want to do backports commit-by-commit, or in larger chunks? Currently, this is commit-by-commit. -- Pauli Virtanen
2009/5/23 Pauli Virtanen <pav@iki.fi>:
BTW, do we want to do backports commit-by-commit, or in larger chunks? Currently, this is commit-by-commit.
I'd prefer to see functional chunks -- it would make them much easier to track. Then again, if we combined patches that way in trunk it would also have helped. Regards Stéfan
Pauli Virtanen wrote:
Fri, 22 May 2009 14:51:36 +0900, David Cournapeau wrote: [clip]
But not this one: the changes do not apply, there need to be other commits as well - even by importing assert_to_tol code as well for the tests to run, 5 tests are failing.
I'd like to backport everything from trunk in scipy.special, except the following:
9600bcf... Revert "use np.power in rdist (test commit with bzr)" ff046c6... Do not detect Endianess in Cephes. 3a99ec1... Add test case for ndtr.
The bzr commit was broken, and the ndtr/endianness fixes break other things. All other commits are bugfixes of some sort; no feature additions here. What are fixed is:
#924 #803 - pbdv errors #503 - reimplementation of real Bessel I #854 - correct NaN returns for iv/jv/ etc when out-of-domain #853 - fix invalid return values from complex Bessel functions #623 - fix invalid return values from real Bessel J #852 - make Bessel zeros computable for orders > 100
Plus some minor documentation fixes.
And also the following:
- The special functions now raise warnings instead of printing to stderr, if the errprint toggle is enabled (it was and is disabled by default.
- The real-valued jve, ive, yve, kve, and kv functions return now NAN when the result would be complex-valued. (Previously they returned the real part.)
***
I have the stuff already backported here:
http://github.com/pv/scipy-work/commits/work-0.7.x
The differences to trunk are minimal:
git diff --stat ..svn/trunk -- scipy/special
scipy/special/cephes/mconf.h | 12 +++++++++++- scipy/special/tests/test_basic.py | 4 +++- 2 files changed, 14 insertions(+), 2 deletions(-)
I used this script to do the backporting:
http://www.iki.fi/pav/tmp/git-cherry-tree
And it went like this:
http://www.iki.fi/pav/tmp/special-rebase-trace.txt
The -o mode of git-cherry-tree seems to be useful for keeping track of stuff to backport.
Great, thanks.
BTW, do we want to do backports commit-by-commit, or in larger chunks?
One commit per bug fix would be good, for example. I generally backport things using git cherry-pick -n + inplace build + tests, and refer to the svn commit in the git commit. There may be a better way. cheers, David
On Sat, May 23, 2009 at 8:41 AM, Pauli Virtanen <pav@iki.fi> wrote:
BTW, do we want to do backports commit-by-commit, or in larger chunks? Currently, this is commit-by-commit.
I have tested your changes on linux and wine, and I pushed your changes into the 0.7.x branch. I still need to do a quick test for Mac OS X, and I will then release the RC for 0.7.x. cheers, David
Hi, Tue, 26 May 2009 11:32:11 +0900, David Cournapeau kirjoitti:
On Sat, May 23, 2009 at 8:41 AM, Pauli Virtanen <pav@iki.fi> wrote:
BTW, do we want to do backports commit-by-commit, or in larger chunks? Currently, this is commit-by-commit.
I have tested your changes on linux and wine, and I pushed your changes into the 0.7.x branch. I still need to do a quick test for Mac OS X, and I will then release the RC for 0.7.x.
Thanks! Pauli
On Tue, May 26, 2009 at 4:16 PM, Pauli Virtanen <pav@iki.fi> wrote:
Hi,
Tue, 26 May 2009 11:32:11 +0900, David Cournapeau kirjoitti:
On Sat, May 23, 2009 at 8:41 AM, Pauli Virtanen <pav@iki.fi> wrote:
BTW, do we want to do backports commit-by-commit, or in larger chunks? Currently, this is commit-by-commit.
I have tested your changes on linux and wine, and I pushed your changes into the 0.7.x branch. I still need to do a quick test for Mac OS X, and I will then release the RC for 0.7.x.
Thanks!
Ok, there are 2 failures on mac os x in scipy.special. test_yn_zeros and test_ynp_zeros are (way) below the tolerance you set up, I put the output of the test in #953. If you don't have access to a mac os x machine, don't hesitate to ask me some additional info, David
Thu, 28 May 2009 16:29:38 +0900, David Cournapeau wrote: [clip]
Ok, there are 2 failures on mac os x in scipy.special. test_yn_zeros and test_ynp_zeros are (way) below the tolerance you set up, I put the output of the test in #953.
I think I found a single-line fix: --- a.f 2009-05-29 00:12:14.000000000 +0300 +++ b.f 2009-05-29 21:27:18.246736714 +0300 @@ -159,7 +159,7 @@ BS=BS+2.0D0*F SU=SU+(-1)**(K/2)*F/K ELSE IF (K.GT.1) THEN - SV=SV+(-1)**(K/2)*K/(K*K-1.0)*F + SV=SV+(-1)**(K/2)*K*F/(K*K-1.0) ENDIF F2=F1 15 F1=F Fixes the issue at least with Gfortran ffloat-store. Who said multiplication is commutative :) -- Pauli Virtanen
participants (4)
-
David Cournapeau
-
David Cournapeau
-
Pauli Virtanen
-
Stéfan van der Walt