[Numpy-discussion] numpy for Python 3?
If not now, when? Thanks, Dick Moores ___ 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
Re: [Numpy-discussion] Complex nan ordering
On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen 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. > > However, nans have been propagated by maximum and minimum since 1.4.0. There was a question, discussed on the list, as to what 'nan' complex to return in the propagation, but it was still a nan complex in your definition of such objects. The final choice was driven by using the first of the already available complex nans as it was the easiest thing to do. However, (nan, nan) would be just as easy to do now that nans are available. I'm not sure what your modifications to the macros buys us, what do you want to achieve? Chuck ___ 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 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
Re: [Numpy-discussion] Complex nan ordering
On Sun, Jul 18, 2010 at 5:00 PM, Pauli Virtanen wrote:
> Sun, 18 Jul 2010 15:57:47 -0600, Charles R Harris wrote:
> > On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen 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.
>
>
How so? Nans sort to the end for reals and also to the end for complex. The
sort order for complex isn't strictly a lexical extension of the reals, it's
a bit closer to what you are talking about, *all* complex numbers containing
nans sort higher than "real" complex numbers. The need was to separate the
nan containing numbers from the real numbers. But within each of the "real"
and "nan" regions the numbers are sorted lexically.
> 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
>
>
So they do at this time.
> 3) sort/searchsorted, and amax/argmax need to play together
>
>
Then I think amax/amin should conform to the sort order. If we are going to
compare nans, then they should to sit somewhere in a strict order, they
can't both be largest and smallest. The choice of where to put them is
somewhat arbitrary, but they need to go somewhere consistent.
> 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
>
>
But that has nothing to do with sorting order, its just a broad
classification like positive numbers. In this case it is nan containing
complex numbers.
> The fact that there are happen to be several different representations
> of a complex nan should not be important.
>
>
Why not? Suppose you want to search for certain combinations?
>***
>
> 1)
>
> Unless we want to define
>
>(complex(nan, 0) > complex(0, 0)) == True
>
>
Looks reasonable to me. That is what the sort order does.
> 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.
>
>
As mentioned above, the sorting order for complex isn't strictly lexical.
Whether it is reasonable to extend the sorting order to the usual
comparisons is a different question. I didn't do it for a reason, but maybe
now is the time to "sort" things out.
> 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 ???
>
>
But that isn't what the sort order yields. An complex number containing nans
in any position will always sort greater than (z,z), it is only in
comparisons between two numbers containing nans that the lexical order comes
back into play.
> 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.
>
>
I'm actually a bit curious about the speed.
> 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.
>
>
Exactly.
> For `argmax` it was possible to be compatible with `amax` when lumping
> cnans in maximum -- just re
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 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
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] 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] 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
wrote:
On Sun, Jul 18, 2010 at 6:02 PM, cool-RR 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
Re: [Numpy-discussion] Complex nan ordering
On Sun, Jul 18, 2010 at 3:36 PM, Pauli Virtanen 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
[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] Python 2.7 MSI installer for NumPy
On Sun, Jul 18, 2010 at 8:34 PM, Peter wrote: > On Sun, Jul 18, 2010 at 6:02 PM, cool-RR 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
Re: [Numpy-discussion] Python 2.7 MSI installer for NumPy
On Sun, Jul 18, 2010 at 6:02 PM, cool-RR 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] 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).
==
[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] 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] 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
[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
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
Re: [Numpy-discussion] 1.5.x branched
On Sun, Jul 18, 2010 at 2:51 AM, Charles R Harris wrote: > > > On Sat, Jul 17, 2010 at 12:32 PM, Pauli Virtanen 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
[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-numpy&arch=alpha&ver=1%3A1.4.1-2&stamp=1279394977&file=log&as=raw [2] https://buildd.debian.org/fetch.cgi?pkg=python-numpy&arch=powerpc&ver=1%3A1.4.1-2&stamp=1279394008&file=log&as=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
