[Numpy-discussion] Numpy 1.4.1 fails to build on (Debian) alpha and powepc
Hello, I finally found the time to update numpy in Debian. But, there is a problem... As you probably know, we support several architectures and we need to have any package available on each of them. After the upload I noticed numpy has problem building on alpha [1] (ieee754.c compilation error, probably related to the conversion from .src) and powerpc [2] (long_double identification) [1] https://buildd.debian.org/fetch.cgi?pkg=python-numpyarch=alphaver=1%3A1.4.1-2stamp=1279394977file=logas=raw [2] https://buildd.debian.org/fetch.cgi?pkg=python-numpyarch=powerpcver=1%3A1.4.1-2stamp=1279394008file=logas=raw They are quite specific pieces of code, so I'm here asking your help in order to be able to build numpy on all Debian supported architectures and so be released in the upcoming stable release :) Of course, feel free to ask me any kind of support, also if you need to test/execute something on those archs, just tell me and I'll do. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.5.x branched
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
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
[Numpy-discussion] Caching 2to3 results
[shameless plug] For those of you tired of waiting for 2to3 after rm -rf build: http://github.com/pv/lib2to3cache and cd numpy/ USE_2TO3CACHE=1 python3 setup.py build -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy Trac emails
Scipy Trac seems to work very well now, I get notification emails for comments on tickets etc. For numpy Trac, nothing right now. Can this be fixed? Thanks, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy Trac emails
Sun, 18 Jul 2010 23:59:24 +0800, Ralf Gommers wrote: Scipy Trac seems to work very well now, I get notification emails for comments on tickets etc. For numpy Trac, nothing right now. Can this be fixed? Works for me. Did you check if your email address is correct there? (- Preferences) -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Python 2.7 MSI installer for NumPy
Hello. I'd appreciate if the NumPy team could provide an MSI installer for Python 2.7. Thanks, Ram Rachum. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.5.x branched
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).
==
Re: [Numpy-discussion] Python 2.7 MSI installer for NumPy
On Sun, Jul 18, 2010 at 6:02 PM, cool-RR cool...@cool-rr.com wrote: Hello. I'd appreciate if the NumPy team could provide an MSI installer for Python 2.7. Thanks, Ram Rachum. You're not the only person who would like this - it was discussed here just 9 days ago, thread title A release for python 2.7?, and the conclusion was we'd have to wait for Numpy 1.5, probably in August. Peter ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 2.7 MSI installer for NumPy
On Sun, Jul 18, 2010 at 8:34 PM, Peter numpy-discuss...@maubp.freeserve.co.uk wrote: On Sun, Jul 18, 2010 at 6:02 PM, cool-RR cool...@cool-rr.com wrote: Hello. I'd appreciate if the NumPy team could provide an MSI installer for Python 2.7. Thanks, Ram Rachum. You're not the only person who would like this - it was discussed here just 9 days ago, thread title A release for python 2.7?, and the conclusion was we'd have to wait for Numpy 1.5, probably in August. It seems that building from the 1.4.x branch works out of the box, so at least a numpy msi should be straightforward, David Peter ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Complex nan ordering
Hi, The current way of Numpy handles ordering of complex nan is not very well defined. We should attempt to clarify this for 1.5.0. For example, what should these return: r1 = np.maximum(complex(1, nan), complex(2, 0)) r2 = np.complex64(complex(1, nan)) np.complex64(complex(2, 0)) or, what should `r3` be after this: r3 = np.array([complex(3, nan), complex(1, 0), complex(nan, 2)]) r3.sort() Previously, we have defined a lexical ordering relation for complex numbers, x y iff x.real y.real or (x.real == y.real and x.imag y.imag) but applying this to the above can cause some surprises: amax([1, 2, 4, complex(3, nan)]) == 4 which breaks nan propagation, and moreover the result depends on the order of the items, and the precise way the algorithm is written. *** Numpy IIRC has specified a lexical order between complex numbers for some time now, unlike Python in which complex numbers are unordered. So we won't change how finite numbers are handled, only the nan handling needs to be specified. *** I suggest the following, aping the way the real nan works: - (z, nan), (nan, z), (nan, nan), where z is any fp value, are all equivalent representations of cnan, as far as comparisons, sort order, etc are concerned. - The ordering between (z, nan), (nan, z), (nan, nan) is undefined. This means e.g. that maximum([cnan_1, cnan_2]) can return either cnan_1 or cnan_2 if both are some cnans. - Moreover, all comparisons , , ==, =, = where one or more operands is a cnan are false. - Except that when sorting, cnans are to be placed last. The advantages are now that nan propagation is now easier to implement, and we get faster code. Moreover, complex nans start to behave more similarly as their real counterparts in comparisons etc.; for instance in the above cases r1 = (1, nan) r2 = False r3 = [complex(1, 0), complex(3, nan), complex(nan, 2)] where in `r3` the order of the last two elements is unspecified. This is in fact the SVN trunk now works (final tweaks in r8508, 8509). Comments are welcome. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Complex nan ordering
On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen p...@iki.fi wrote: Hi, The current way of Numpy handles ordering of complex nan is not very well defined. We should attempt to clarify this for 1.5.0. For example, what should these return: r1 = np.maximum(complex(1, nan), complex(2, 0)) r2 = np.complex64(complex(1, nan)) np.complex64(complex(2, 0)) or, what should `r3` be after this: r3 = np.array([complex(3, nan), complex(1, 0), complex(nan, 2)]) r3.sort() Previously, we have defined a lexical ordering relation for complex numbers, x y iff x.real y.real or (x.real == y.real and x.imag y.imag) but applying this to the above can cause some surprises: amax([1, 2, 4, complex(3, nan)]) == 4 which breaks nan propagation, and moreover the result depends on the order of the items, and the precise way the algorithm is written. *** Numpy IIRC has specified a lexical order between complex numbers for some time now, unlike Python in which complex numbers are unordered. So we won't change how finite numbers are handled, only the nan handling needs to be specified. *** I suggest the following, aping the way the real nan works: - (z, nan), (nan, z), (nan, nan), where z is any fp value, are all equivalent representations of cnan, as far as comparisons, sort order, etc are concerned. - The ordering between (z, nan), (nan, z), (nan, nan) is undefined. This means e.g. that maximum([cnan_1, cnan_2]) can return either cnan_1 or cnan_2 if both are some cnans. The sort and cmp order was defined in 1.4.0, see the release notes. (z,z), (z, nan), (nan, z), (nan, nan) are in correct order and there are tests to enforce this. Sort and searchsorted need to work together. - Moreover, all comparisons , , ==, =, = where one or more operands is a cnan are false. - Except that when sorting, cnans are to be placed last. And in sort order. The advantages are now that nan propagation is now easier to implement, and we get faster code. Moreover, complex nans start to behave more similarly as their real counterparts in comparisons etc.; for instance in the above cases r1 = (1, nan) r2 = False r3 = [complex(1, 0), complex(3, nan), complex(nan, 2)] where in `r3` the order of the last two elements is unspecified. This is in fact the SVN trunk now works (final tweaks in r8508, 8509). Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python 2.7 MSI installer for NumPy
On 7/18/2010 2:20 PM, David Cournapeau wrote:
On Sun, Jul 18, 2010 at 8:34 PM, Peter
numpy-discuss...@maubp.freeserve.co.uk wrote:
On Sun, Jul 18, 2010 at 6:02 PM, cool-RRcool...@cool-rr.com wrote:
Hello.
I'd appreciate if the NumPy team could provide an MSI installer
for Python 2.7.
Thanks,
Ram Rachum.
You're not the only person who would like this - it was discussed
here just 9 days ago, thread title A release for python 2.7?, and
the conclusion was we'd have to wait for Numpy 1.5, probably in
August.
It seems that building from the 1.4.x branch works out of the box, so
at least a numpy msi should be straightforward,
Binaries built from the numpy 1.4.x branch do crash on Python 2.7
because of this: http://projects.scipy.org/numpy/ticket/1345. The fix is
easy to backport (attached). Until yesterday another reason not to
release numpy 1.4.1 binaries for Python 2.7 was the projected use of
PyCapsule instead of PyCObject in numpy 1.5+.
--
Christoph
Index: src/multiarray/numpyos.c
=
--- src/multiarray/numpyos.c(revision 8498)
+++ src/multiarray/numpyos.c(working copy)
@@ -418,6 +418,32 @@
return 0;
}
+/*
+ * _NumPyOS_ascii_strtod_plain:
+ *
+ * PyOS_ascii_strtod work-alike, with no enhanced features,
+ * for forward compatibility with Python = 2.7
+ */
+static double
+NumPyOS_ascii_strtod_plain(const char *s, char** endptr)
+{
+double result;
+#if PY_VERSION_HEX = 0x0207
+NPY_ALLOW_C_API_DEF
+NPY_ALLOW_C_API
+result = PyOS_string_to_double(s, endptr, NULL);
+if (PyErr_Occurred()) {
+if (endptr) {
+*endptr = (char*)s;
+}
+PyErr_Clear();
+}
+NPY_DISABLE_C_API
+#else
+result = PyOS_ascii_strtod(s, endptr);
+#endif
+return result;
+}
/*
* NumPyOS_ascii_strtod:
@@ -506,7 +532,7 @@
}
memcpy(buffer, s, n);
buffer[n] = '\0';
-result = PyOS_ascii_strtod(buffer, q);
+result = NumPyOS_ascii_strtod_plain(buffer, q);
if (endptr != NULL) {
*endptr = (char*)(s + (q - buffer));
}
@@ -515,7 +541,7 @@
}
/* End of ##2 */
-return PyOS_ascii_strtod(s, endptr);
+return NumPyOS_ascii_strtod_plain(s, endptr);
}
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Complex128
I don't understand the following. a=np.zeros( (3,3,3), dtype='Complex128') a array([[[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]], [[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]], [[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]]], dtype=complex256) i ask for Complex128 and get complex256? if i ask for complex128 (little c) I get complex128 if i ask for complex (little c) i get complex128 if i ask for Complex (cap C) i get unrecognized type ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Complex nan ordering
Sun, 18 Jul 2010 15:57:47 -0600, Charles R Harris wrote: On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen p...@iki.fi wrote: [clip] I suggest the following, aping the way the real nan works: - (z, nan), (nan, z), (nan, nan), where z is any fp value, are all equivalent representations of cnan, as far as comparisons, sort order, etc are concerned. - The ordering between (z, nan), (nan, z), (nan, nan) is undefined. This means e.g. that maximum([cnan_1, cnan_2]) can return either cnan_1 or cnan_2 if both are some cnans. The sort and cmp order was defined in 1.4.0, see the release notes. (z,z), (z, nan), (nan, z), (nan, nan) are in correct order and there are tests to enforce this. Sort and searchsorted need to work together. Ok, now we're diving into an obscure corner that hopefully many people don't care about :) There are several issues here: 1) We should not use lexical order in comparison operations, since this contradicts real-valued nan arithmetic. Currently (and in 1.4) we do some weird sort of mixture, which seems inconsistent. 2) maximum/minimum should propagate nans, fmax/fmin should not 3) sort/searchsorted, and amax/argmax need to play together 4) as long as 1)-3) are valid, I don't think anybody cares what what exactly we mean by a complex nan, as long as np.isnan(complex nan) == True The fact that there are happen to be several different representations of a complex nan should not be important. *** 1) Unless we want to define (complex(nan, 0) complex(0, 0)) == True we cannot strictly follow the lexical order in comparisons. And if we define it like this, we contradict real-valued nan arithmetic, which IMHO is quite bad. Here, it would make sense to me to lump all the different complex nans into a single cnan, as far as the arithmetic comparison operations are concerned. Then, z OP cnan == False for all comparison operations. In 1.4.1 we have import numpy as np np.__version__ '1.4.1' x = np.complex64(complex(np.nan, 1)) y = np.complex64(complex(0, 1)) x = y False x y False x = np.complex64(complex(1, np.nan)) y = np.complex64(complex(0, 1)) x = y True x y False which seems an obscure mix of real-valued nan arithmetic and lexical ordering -- I don't think it's the correct choice... Of course, the practical importance of this decision approaches zero, but it would be nice to be consistent. *** 2) For maximum/amax, strict lexical order contradicts nan propagation: maximum(1+nan*j, 2+0j) == 2+0j ??? I don't see why we should follow the lexical order when both arguments are nans. The implementation will be faster if we don't. Also, this way argmax (which should be nan-propagating) can stop looking once it finds the first nan -- and it does not need to care if later on in the array there would be a greater nan. *** 3) For sort/searchsorted we have a technical reason to do something more, and there the strict lexical order seems the correct decision. For `argmax` it was possible to be compatible with `amax` when lumping cnans in maximum -- just return the first cnan. *** 4) As far as np.isnan is concerned, np.isnan(complex(0, nan)) True np.isnan(complex(nan, 0)) True np.isnan(complex(nan, nan)) True So I think nobody should care which complex nan a function such as maximum or amax returns. We can of course give up some performance to look for the greatest nan in these cases, but I do not think that it would be very worthwhile. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Complex128
mac os x leopard 10.5.. EPD installed i just don't understand why i get one thing when i ask for another. i can get what i want, but only by not asking for it. thanks, Ross On Sun, Jul 18, 2010 at 6:02 PM, Pauli Virtanen p...@iki.fi wrote: Sun, 18 Jul 2010 17:26:13 -0500, Ross Harder wrote: I don't understand the following. a=np.zeros( (3,3,3), dtype='Complex128') a array([[[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]], [[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]], [[0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j], [0.0+0.0j, 0.0+0.0j, 0.0+0.0j]]], dtype=complex256) i ask for Complex128 and get complex256? What platform? On Win-64 longdouble == double. Of course, the byte-width names should still reflect the reality. Please file a bug ticket... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy 1.5 or 2.0
What is the difference between these two versions? I usually check out the svn version (now 2.0) and it compiles well with python 2.6, 2.7 and 3.1. Nadav. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
