Hi Gilberto,
* onefire onefire.mys...@gmail.com [2014-04-18]:
Interesting! Using sync() as you suggested makes every write slower, and
it decreases the time difference between save and savez,
so maybe I was observing the 10 times difference because the file system
buffers were being flushed
Hi again,
* onefire onefire.mys...@gmail.com [2014-04-18]:
I think your workaround might help, but a better solution would be to not
use Python's zipfile module at all. This would make it possible to, say,
let the user choose the checksum algorithm or to turn that off.
Or maybe the
El 17/04/14 21:19, Julian Taylor ha escrit:
On 17.04.2014 20:30, Francesc Alted wrote:
El 17/04/14 19:28, Julian Taylor ha escrit:
On 17.04.2014 18:06, Francesc Alted wrote:
In [4]: x_unaligned = np.zeros(shape,
dtype=[('y1',np.int8),('x',np.float64),('y2',np.int8,(7,))])['x']
on arrays of
El 18/04/14 13:01, Valentin Haenel ha escrit:
Hi again,
* onefire onefire.mys...@gmail.com [2014-04-18]:
I think your workaround might help, but a better solution would be to not
use Python's zipfile module at all. This would make it possible to, say,
let the user choose the checksum
Hi. I am part of the pypy team. I recently rewrote mtrand.pyx as
mtrand.py that uses cffi, in order to use it with pypy. mtrand.pyx uses
cython to compile a python extension module, where my approach was to
compile the randomkit code as a shared object, and to use that directly
via cffi.
If this
Hi,
* Valentin Haenel valen...@haenel.co [2014-04-17]:
* Valentin Haenel valen...@haenel.co [2014-04-17]:
* Julian Taylor jtaylor.deb...@googlemail.com [2014-04-17]:
On 17.04.2014 21:30, onefire wrote:
Thanks for the suggestion. I did profile the program before, just not
using
On 18.04.2014 18:29, Valentin Haenel wrote:
Hi,
* Valentin Haenel valen...@haenel.co [2014-04-17]:
* Valentin Haenel valen...@haenel.co [2014-04-17]:
* Julian Taylor jtaylor.deb...@googlemail.com [2014-04-17]:
On 17.04.2014 21:30, onefire wrote:
Thanks for the suggestion. I did profile the
Resolved by installing anaconda.
--
View this message in context:
http://numpy-discussion.10968.n7.nabble.com/ImportError-usr-local-lib-python2-7-site-packages-numpy-1-8-0-py2-7-linux-x86-64-egg-numpy-core-multg-tp37372p37412.html
Sent from the Numpy-discussion mailing list archive at
I think we'll be ready to start implementation once I get the conversion to
datetime.datetime on the proposal with some decent examples. It would also be
great to have opinions on what test cases should be used, so please speak up if
you feel you have anything to say about that.
Cheers,
On Mon, Apr 14, 2014 at 11:59 AM, Chris Barker chris.bar...@noaa.govwrote:
- datetime64 objects with high precision (e.g., ns) can't compare to
datetime objects.
That's a problem, but how do you think it should be handled? My thought is
that it should round to microseconds, and then compare
10 matches
Mail list logo
