[Numpy-discussion] 1.4.0: Setting a firm release date for 1st december.
Hi, I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any Otherwise, I think there has been quite a lot of new features. If people want to add new functionalities or features, please do it soon, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.4.0: Setting a firm release date for 1st december.
On Mon, Nov 2, 2009 at 3:29 AM, David Cournapeau courn...@gmail.com wrote: Hi, I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any Otherwise, I think there has been quite a lot of new features. If people want to add new functionalities or features, please do it soon, I wanted to get __input_prepare__ in for the 1.4 release, but I don't think I can get it in and tested by November 16. Darren ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.4.0: Setting a firm release date for 1st december.
Mon, 02 Nov 2009 17:29:18 +0900, David Cournapeau wrote: I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any Otherwise, I think there has been quite a lot of new features. If people want to add new functionalities or features, please do it soon, Can we get the complex functions to npy_math for 1.4.0: could be useful for the next Scipy? This is pretty quick to do, I can just write up some more tests one evening and commit. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Random int64 and float64 numbers
2009/11/1 Thomas Robitaille thomas.robitai...@gmail.com: Hi, I'm trying to generate random 64-bit integer values for integers and floats using Numpy, within the entire range of valid values for that type. To generate random 32-bit floats, I can use: Others have addressed why this is giving bogus results. But it's worth thinking about what you're actually trying to do. If it's fuzz tests, that is, producing unrestricted random floats to feed to a function, then even if this worked it wouldn't produce what you want: it will never produce floats of order unity, for example. If you want do what you described, you could produce floats uniformly from -1 to 1 and then multiply the results by the largest representable float. If you want random floats, I suggest generating an array of random bytes and reinterpreting them as floats. You'll get a fair number of NaNs and infinities, so you may want to take only the finite values and regenerate the rest. This will give you some numbers from all over the range of floats, including tiny values (and denormalized values, which are a potentially important special case). Anne np.random.uniform(low=np.finfo(np.float32).min,high=np.finfo (np.float32).max,size=10) which gives for example array([ 1.47351436e+37, 9.93620693e+37, 2.22893053e+38, -3.33828977e+38, 1.08247781e+37, -8.37481260e+37, 2.64176554e+38, -2.72207226e+37, 2.54790459e+38, -2.47883866e+38]) but if I try and use this for 64-bit numbers, i.e. np.random.uniform(low=np.finfo(np.float64).min,high=np.finfo (np.float64).max,size=10) I get array([ Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf, Inf]) Similarly, for integers, I can successfully generate random 32-bit integers: np.random.random_integers(np.iinfo(np.int32).min,high=np.iinfo (np.int32).max,size=10) which gives array([-1506183689, 662982379, -1616890435, -1519456789, 1489753527, -604311122, 2034533014, 449680073, -444302414, -1924170329]) but am unsuccessful for 64-bit integers, i.e. np.random.random_integers(np.iinfo(np.int64).min,high=np.iinfo (np.int64).max,size=10) which produces the following error: OverflowError: long int too large to convert to int Is this expected behavior, or are these bugs? Thanks for any help, Thomas ___ 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] 1.4.0: Setting a firm release date for 1st december.
On Mon, Nov 2, 2009 at 1:29 AM, David Cournapeau courn...@gmail.com wrote: Hi, I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any It would be nice to track down the reduceat bug. Not that I've managed to get myself working on the problem. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.4.0: Setting a firm release date for 1st december.
On Mon, Nov 2, 2009 at 9:38 PM, Pauli Virtanen pav...@iki.fi wrote: Can we get the complex functions to npy_math for 1.4.0: could be useful for the next Scipy? This is pretty quick to do, I can just write up some more tests one evening and commit. The idea was partially to set a date to force me putting my code in shape soon. The whole point of setting release dates is to organize ones own time around it, after all :) David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Setting a firm release date for 1st december.
On Nov 2, 2009, at 11:09 AM, numpy-discussion-requ...@scipy.org wrote: From: David Cournapeau courn...@gmail.com Subject: [Numpy-discussion] 1.4.0: Setting a firm release date for 1st december. To: Discussion of Numerical Python numpy-discussion@scipy.org Message-ID: 5b8d13220911020029q1d9f1bd7ia1770e3b93e6e...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hi, I think it is about time to release 1.4.0. Instead of proposing a release date, I am setting a firm date for 1st December, and 16th november to freeze the trunk. If someone wants a different date, you have to speak now. There are a few issues I would like to clear up: - Documentation for datetime, in particular for the public C API - Snow Leopard issues, if any Otherwise, I think there has been quite a lot of new features. If people want to add new functionalities or features, please do it soon, cheers, David This seems like an appropriate opportunity to ping an issue I posted on Trac: http://projects.scipy.org/numpy/ticket/1177 Basically, interp doesn't currently play nice with numpy scalars. Patch included with ticket (see second comment). Cheers, -Tony___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines
Anybody have any ideas here? Otherwise, I'm thinking this should be posted to the numpy bugs list. What's the best way to report a bug of this kind? Thanks! On Fri, Oct 30, 2009 at 5:48 PM, Reckoner recko...@gmail.com wrote: Robert Kern wrote: You can import numpy.core.multiarray on both machines? Yes. For each machine separately, you can cPickle files with numpy arrays without problems loading/dumping. The problem comes from transferring the win32 cPickle'd files to Linux 64 bit and then trying to load them. Transferring cPickle'd files that do *not* have numpy arrays work as expected. In other words, cPICKLE'd lists transfer fine back and forth between the two machines. In fact, we currently get around this problem by converting the numpy arrays to lists, transferring them, and then re-numpy-ing them on the respective hosts thanks. On Fri, Oct 30, 2009 at 11:13 AM, Reckoner recko...@gmail.com wrote: Hi, % python -c 'import numpy.core.multiarray' works just fine, but when I try to load a file that I have transferred from another machine running Windows to one running Linux, I get: % python -c 'import cPickle;a=cPickle.load(open(matrices.pkl))' Traceback (most recent call last): File string, line 1, in module ImportError: No module named multiarray otherwise, cPickle works normally when transferring files that *do* not contain numpy arrays. I am using version 1.2 on both machines. It's not so easy for me to change versions, by the way, since this is the version that my working group has decided on to standardize on for this effort. Any help appreciated. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines
On Mon, Nov 2, 2009 at 15:42, Reckoner recko...@gmail.com wrote: Anybody have any ideas here? Nope! Otherwise, I'm thinking this should be posted to the numpy bugs list. What's the best way to report a bug of this kind? Create a new ticket on the Trac: http://projects.scipy.org/numpy/ If you can attach the offending pickle files, that would be ideal. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines
On Mon, Nov 2, 2009 at 2:42 PM, Reckoner recko...@gmail.com wrote: Anybody have any ideas here? Otherwise, I'm thinking this should be posted to the numpy bugs list. What's the best way to report a bug of this kind? Thanks! On Fri, Oct 30, 2009 at 5:48 PM, Reckoner recko...@gmail.com wrote: Robert Kern wrote: You can import numpy.core.multiarray on both machines? Yes. For each machine separately, you can cPickle files with numpy arrays without problems loading/dumping. The problem comes from transferring the win32 cPickle'd files to Linux 64 bit and then trying to load them. Transferring cPickle'd files that do *not* have numpy arrays work as expected. In other words, cPICKLE'd lists transfer fine back and forth between the two machines. In fact, we currently get around this problem by converting the numpy arrays to lists, transferring them, and then re-numpy-ing them on the respective hosts thanks. On Fri, Oct 30, 2009 at 11:13 AM, Reckoner recko...@gmail.com wrote: Hi, % python -c 'import numpy.core.multiarray' works just fine, but when I try to load a file that I have transferred from another machine running Windows to one running Linux, I get: % python -c 'import cPickle;a=cPickle.load(open(matrices.pkl))' Traceback (most recent call last): File string, line 1, in module ImportError: No module named multiarray otherwise, cPickle works normally when transferring files that *do* not contain numpy arrays. I am using version 1.2 on both machines. It's not so easy for me to change versions, by the way, since this is the version that my working group has decided on to standardize on for this effort. Any help appreciated. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Have you have tried the other Cookbook approaches: http://www.scipy.org/Cookbook/InputOutput Like using numpy's own array io functions - load/save(z)? (seems to work between 64-bit Windows 7 and 64-bit Linux - each has different numpy versions) Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] persistent ImportError: No module named multiarray when moving cPickle files between machines
thanks for the suggestion! I will look into it. The other thing is that the numpy arrays in question are actually embedded in another object. When I convert the numpy arrays into plain lists, and then cPickle them, there is no problem with any of the larger objects. That is the way we are currently working around this issue. Thanks again. On Mon, Nov 2, 2009 at 2:43 PM, Bruce Southey bsout...@gmail.com wrote: On Mon, Nov 2, 2009 at 2:42 PM, Reckoner recko...@gmail.com wrote: Anybody have any ideas here? Otherwise, I'm thinking this should be posted to the numpy bugs list. What's the best way to report a bug of this kind? Thanks! On Fri, Oct 30, 2009 at 5:48 PM, Reckoner recko...@gmail.com wrote: Robert Kern wrote: You can import numpy.core.multiarray on both machines? Yes. For each machine separately, you can cPickle files with numpy arrays without problems loading/dumping. The problem comes from transferring the win32 cPickle'd files to Linux 64 bit and then trying to load them. Transferring cPickle'd files that do *not* have numpy arrays work as expected. In other words, cPICKLE'd lists transfer fine back and forth between the two machines. In fact, we currently get around this problem by converting the numpy arrays to lists, transferring them, and then re-numpy-ing them on the respective hosts thanks. On Fri, Oct 30, 2009 at 11:13 AM, Reckoner recko...@gmail.com wrote: Hi, % python -c 'import numpy.core.multiarray' works just fine, but when I try to load a file that I have transferred from another machine running Windows to one running Linux, I get: % python -c 'import cPickle;a=cPickle.load(open(matrices.pkl))' Traceback (most recent call last): File string, line 1, in module ImportError: No module named multiarray otherwise, cPickle works normally when transferring files that *do* not contain numpy arrays. I am using version 1.2 on both machines. It's not so easy for me to change versions, by the way, since this is the version that my working group has decided on to standardize on for this effort. Any help appreciated. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion Have you have tried the other Cookbook approaches: http://www.scipy.org/Cookbook/InputOutput Like using numpy's own array io functions - load/save(z)? (seems to work between 64-bit Windows 7 and 64-bit Linux - each has different numpy versions) Bruce ___ 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] Automatic string length in recarray
Hi,
I'm having trouble with creating np.string_ fields in recarrays. If I
create a recarray using
np.rec.fromrecords([(1,'hello'),(2,'world')],names=['a','b'])
the result looks fine:
rec.array([(1, 'hello'), (2, 'world')], dtype=[('a', 'i8'), ('b', '|
S5')])
But if I want to specify the data types:
np.rec.fromrecords([(1,'hello'),(2,'world')],dtype=[('a',np.int8),
('b',np.str)])
the string field is set to a length of zero:
rec.array([(1, ''), (2, '')], dtype=[('a', '|i1'), ('b', '|S0')])
I need to specify datatypes for all numerical types since I care about
int8/16/32, etc, but I would like to benefit from the auto string
length detection that works if I don't specify datatypes. I tried
replacing np.str by None but no luck. I know I can specify '|S5' for
example, but I don't know in advance what the string length should be
set to.
Is there a way to solve this problem without manually examining the
data that is being passed to rec.fromrecords?
Thanks for any help,
Thomas
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
