Re: [Numpy-discussion] 1.5.x branched

2010-07-18 Thread Ralf Gommers
On Sun, Jul 18, 2010 at 2:51 AM, Charles R Harris charlesr.har...@gmail.com
 wrote:



 On Sat, Jul 17, 2010 at 12:32 PM, Pauli Virtanen p...@iki.fi wrote:

 Dear all,

 Based on patches contributed by Christoph Gohlke, I've created a branch
 for 1.5.x:

http://svn.scipy.org/svn/numpy/branches/1.5.x

 It should be

  a) Binary compatible with Numpy 1.4 on Python 2.x.

 This meant rolling back the datetime and a couple other changes.

  b) Support Python 3.1 and 2.7.

 I expect it will be easy to track changes in the trunk, even if preparing
 the release will still take some time.

 Thanks a lot Pauli and Christoph!

Builds fine on OS X 10.6 with both 2.7 and 3.1, and all tests pass. With one
exception: in-place build for 3.1 is broken. Does anyone know is this is a
distutils or numpy issue? The problem is that on import numpy.__config__ can
not be found.


 Probably best to get started. The changes I want to put in are small
 additions and won't be difficult to backport as long as Ralf doesn't put out
 the first release this evening ;)

 Don't think that's going to happen, but it would be good to discuss the
release schedule. What changes need to go in before a first beta, and how
much time do you all need for that?

Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] 1.5.x branched

2010-07-18 Thread Pauli Virtanen
Sun, 18 Jul 2010 21:13:43 +0800, Ralf Gommers wrote:
[clip]
 Builds fine on OS X 10.6 with both 2.7 and 3.1, and all tests pass. With
 one exception: in-place build for 3.1 is broken. Does anyone know is
 this is a distutils or numpy issue? The problem is that on import
 numpy.__config__ can not be found.

The inplace build goes to

build/py3k

I don't think we can easily support inplace build in the main directory.

[clip]
 Don't think that's going to happen, but it would be good to discuss the
 release schedule. What changes need to go in before a first beta, and
 how much time do you all need for that?

I don't have anything urgent.

It might be good to glance through the tickets, however, to see if 
there's something serious pending.

Also, I'm not 100% sure what's the Python 3 status on Windows, so that 
should be checked too.

Pauli 

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] 1.5.x branched

2010-07-18 Thread Christoph Gohlke


On 7/18/2010 7:52 AM, Pauli Virtanen wrote:
 Sun, 18 Jul 2010 21:13:43 +0800, Ralf Gommers wrote:
 [clip]
 Builds fine on OS X 10.6 with both 2.7 and 3.1, and all tests pass. With
 one exception: in-place build for 3.1 is broken. Does anyone know is
 this is a distutils or numpy issue? The problem is that on import
 numpy.__config__ can not be found.

 The inplace build goes to

   build/py3k

 I don't think we can easily support inplace build in the main directory.

 [clip]
 Don't think that's going to happen, but it would be good to discuss the
 release schedule. What changes need to go in before a first beta, and
 how much time do you all need for that?

 I don't have anything urgent.

 It might be good to glance through the tickets, however, to see if
 there's something serious pending.

 Also, I'm not 100% sure what's the Python 3 status on Windows, so that
 should be checked too.


I tested MSVC builds of numpy 1.5.0.dev8500 on 32 and 64 bit Python 2.5, 
2.6, 2.7, and 3.1 for Windows.

I general all looks good, including the Python 3 builds.

Numpy 1.5 builds OK with msvc after applying the patch at 
http://projects.scipy.org/numpy/attachment/ticket/1502/msvc_isnan_isinf.patch

Only a few tests fail. Except for one error 
(http://projects.scipy.org/numpy/ticket/1499), all failed tests can 
probably be marked as known. The 32 bit Python 2.5 build shows some 
additional failures due to inf/nan issues but I don't really care enough 
to report them here.

A lot of warnings are printed during the test. Can they be disabled in 
the final release?
Warning: invalid value encountered in sign
Warning: invalid value encountered in fmax
Warning: invalid value encountered in fmin
Warning: invalid value encountered in logaddexp
Warning: invalid value encountered in logaddexp2
Warning: invalid value encountered in maximum
Warning: invalid value encountered in minimum
Warning: invalid value encountered in absolute
Warning: invalid value encountered in equal
Warning: invalid value encountered in less



==
ERROR: test_filename (test_memmap.TestMemmap)
--
Traceback (most recent call last):
   File 
X:\Python26-x64\lib\site-packages\numpy\core\tests\test_memmap.py, 
line 60, in test_filename
 os.unlink(tmpname)
WindowsError: [Error 32] The process cannot access the file because it 
is being used by another process: 
'c:\\users\\gohlke\\appdata\\local\\temp\\mmapgl7bkg'


This error could be due to a Python bug: 
http://bugs.python.org/issue7443. I tried the proposed patches for 
issue7443 without success.


==
ERROR: Ticket #99
--
Traceback (most recent call last):
   File X:\Python26-x64\lib\site-packages\numpy\testing\decorators.py, 
line 215, in knownfailer
 return f(*args, **kwargs)
   File 
X:\Python26-x64\lib\site-packages\numpy\core\tests\test_regression.py, 
line 145, in test_intp
 np.intp('0x' + 'f'*i_width,16)
TypeError: function takes at most 1 argument (2 given)


Fails on 64 bit Python 2.x only. This test is disabled for Python 3.0+. 
It seems np.intp does not inherit from Python long on win-amd64 
platforms. This can probably be marked as knownfailure for win-amd64. 
See http://projects.scipy.org/numpy/ticket/99.


==
ERROR: test_ldexp (test_umath.TestLdexp)
--
Traceback (most recent call last):
   File 
X:\Python26-x64\lib\site-packages\numpy\core\tests\test_umath.py, line 
363, in test_ldexp
 assert_almost_equal(ncu.ldexp(np.array(2., np.longdouble), 
np.array(3, np.int16)), 16.)
TypeError: function not supported for these types, and can't coerce 
safely to supported types


This also fails for Python 2.5.4, Solaris 8, sparc 32 bits. See 
http://projects.scipy.org/numpy/ticket/1499


==
FAIL: test_special_values (test_umath_complex.TestClog)
--
Traceback (most recent call last):
   File 
X:\Python26-x64\lib\site-packages\numpy\core\tests\test_umath_complex.py, 
line 224, in test_special_values
 assert_almost_equal(np.log(x), y)
   File X:\Python26-x64\lib\site-packages\numpy\testing\utils.py, line 
443, in assert_almost_equal
 raise AssertionError(msg)
AssertionError:
Arrays are not almost equal
  ACTUAL: array([ NaN+2.35619449j])
  DESIRED: (inf+2.3561944901923448j)
  raise AssertionError('\nArrays are not almost equal\n ACTUAL: array([ 
 NaN+2.35619449j])\n DESIRED: (inf+2.3561944901923448j)')


This can probably be marked as a known failure again (as in 1.4.1).


==

[Numpy-discussion] 1.5.x branched

2010-07-17 Thread Pauli Virtanen
Dear all,

Based on patches contributed by Christoph Gohlke, I've created a branch 
for 1.5.x:

http://svn.scipy.org/svn/numpy/branches/1.5.x

It should be

  a) Binary compatible with Numpy 1.4 on Python 2.x.

 This meant rolling back the datetime and a couple other changes.

  b) Support Python 3.1 and 2.7.

I expect it will be easy to track changes in the trunk, even if preparing 
the release will still take some time.

-- 
Pauli Virtanen

___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] 1.5.x branched

2010-07-17 Thread Charles R Harris
On Sat, Jul 17, 2010 at 12:32 PM, Pauli Virtanen p...@iki.fi wrote:

 Dear all,

 Based on patches contributed by Christoph Gohlke, I've created a branch
 for 1.5.x:

http://svn.scipy.org/svn/numpy/branches/1.5.x

 It should be

  a) Binary compatible with Numpy 1.4 on Python 2.x.

 This meant rolling back the datetime and a couple other changes.

  b) Support Python 3.1 and 2.7.

 I expect it will be easy to track changes in the trunk, even if preparing
 the release will still take some time.


Probably best to get started. The changes I want to put in are small
additions and won't be difficult to backport as long as Ralf doesn't put out
the first release this evening ;)

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion