On Sun, Jul 27, 2008 at 11:26 PM, David Cournapeau
[EMAIL PROTECTED] wrote:
Hi,
After some delay, here are the win32 binaries for numpy 1.1.1rc2:
http://www.ar.media.kyoto-u.ac.jp/members/david/numpy-1.1.1.dev5559-win32-superpack-python2.5.exe
Notes on those binaries:
- Based on
Hi all,
Stefan, thank you very much for your quick answer. This was an obvious silly
mistake. Now the first function does what it should. Still, me and my
colleagues can't make any sense of what happens in the second example. The
re-transformed function is identical to the original one, but
Hi,
Well, as usual there are compromises in everything and the mgrid/ogrid
functionality is the way it currently is for some good reasons. The
first reason is that python appears to be fairly sloppy about how it
passes indexing arguments to the __getitem__ method. It passes a tuple
containing
David M. Kaplan wrote:
python appears to be fairly sloppy about how it passes
indexing arguments to the __getitem__ method.
I do not generally find the word 'sloppy' to be descriptive
of Python.
It passes a tuple containing the arguments in all cases
except when it has one argument, in
Luis Pedro Coelho wrote:
Hello all,
Numpy arrays come with several reduce operations: sum(), std(), argmin(),
min(),
The traditional implementation of these suffers from two big problems: It is
slow and it often allocates intermediate memory. I have code that is failing
with OOM
Hi Pierre,
A Friday 25 July 2008, Pierre GM escrigué:
Francesc,
Could you clarify a couple of points ?
[datetime64]
If I understand properly, your datetime64 would be time units from
the POSIX epoch (1970/01/01 00:00:00), right ? So
+7d would be 1970/01/08 (7 days after the epoch)
-7W
I have to correct myself. The function test_fft1() still does not work, it
just looked good in the plots, but at a closer look, Re(IFFT) is close to
zero and is far from matching the exact IFT.
So it seems FFT(IFFT(f)) == IFFT(FFT(f)) == 1 (if done right ;-), but I just
cannot reproduce the
On Mon, 28 Jul 2008 14:26:59 +0900
David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
After some delay, here are the win32 binaries for
numpy 1.1.1rc2:
http://www.ar.media.kyoto-u.ac.jp/members/david/numpy-1.1.1.dev5559-win32-superpack-python2.5.exe
Notes on those binaries:
-
A Saturday 26 July 2008, Matt Knox escrigué:
For this goal, we are proposing a decoupling of the date/time use
cases in two different groups:
1. A pure ``datetime`` dtype (absolute or relative) that would be
useful for timestamping purposes in general (i.e. registering
dates without a
On Mon, Jul 28, 2008 at 11:08 AM, Nils Wagner
[EMAIL PROTECTED]wrote:
On Mon, 28 Jul 2008 14:26:59 +0900
David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
After some delay, here are the win32 binaries for
numpy 1.1.1rc2:
Hi,
Sorry for the very long delay in commenting on this. In short, it looks
great, and thanks for your efforts.
A couple small comments:
In [11]: t[0] = datetime.datetime.now() # setter in action
In [12]: t[0]
Out[12]: '2008-07-16T13:39:25.315' # representation in ISO 8601
format
In trying to track down a bug in matplotlib, I have come across tsome
very strange numpy behavior. Basically, whether or not I call
np.seterr('raise') or not in a matplotlib demo affects the behavior of
seterr in another (pure numpy) script, run in a separate process.
Something about the numpy
Hello:
I'm hoping someone can straighten me out. I have a 64 bit fedora 8
quad core machine and can install blas and lapack from the yum
repository. With these, numpy installs fine and finds blas and
lapack.
I also tried removing the yum blas/lapack libs and installing atlas
via the
On Mon, Jul 28, 2008 at 13:56, John Hunter [EMAIL PROTECTED] wrote:
In trying to track down a bug in matplotlib, I have come across tsome
very strange numpy behavior. Basically, whether or not I call
np.seterr('raise') or not in a matplotlib demo affects the behavior of
seterr in another
On Mon, Jul 28, 2008 at 2:02 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Mon, Jul 28, 2008 at 13:56, John Hunter [EMAIL PROTECTED] wrote:
In trying to track down a bug in matplotlib, I have come across tsome
very strange numpy behavior. Basically, whether or not I call
np.seterr('raise') or
On Mon, Jul 28, 2008 at 14:30, John Hunter [EMAIL PROTECTED] wrote:
On Mon, Jul 28, 2008 at 2:02 PM, Robert Kern [EMAIL PROTECTED] wrote:
On Mon, Jul 28, 2008 at 13:56, John Hunter [EMAIL PROTECTED] wrote:
In trying to track down a bug in matplotlib, I have come across tsome
very strange numpy
On Mon, Jul 28, 2008 at 2:35 PM, Robert Kern [EMAIL PROTECTED] wrote:
Both, if the behavior exhibits itself without the npy file. If it only
exhibits itself with an npy involved, then we have some more
information about where the problem might be.
OK, I'll see what I can come up with. In the
Mon, 28 Jul 2008 13:56:52 -0500, John Hunter wrote:
In trying to track down a bug in matplotlib, I have come across tsome
very strange numpy behavior. Basically, whether or not I call
np.seterr('raise') or not in a matplotlib demo affects the behavior of
seterr in another (pure numpy)
On Monday 28 July 2008 12:17:41 Francesc Alted wrote:
So, for allowing this to happen, we have concluded that a
conceptual change in our second proposal is needed: instead of
a 'resolution', we can introduce the 'time unit' concept.
I'm all for that, thanks !
One thing that will not be
Hi all,
for those interested, here's a brief report on the recent SIAM meeting
where a number of Python-based tools for scientific computing
(including ipython, numpy, scipy, sage, and more) were discussed:
http://fdoperez.blogspot.com/2008/07/python-tools-for-science-go-to-siam.html
The punch
Hi there,
I ran into a little problem in some type checking code for a C extension
I'm writing. I construct X as a C-long array and then I cast it to a C-int
array Y, however the type code does not change. However, when I try
constructing the array from scratch as a C-int, I get the right type
Hi all,
I'd like to use fromfile() to read text files that look like:
23.4,123.43
456.321, 9568.00
32.0,134.4
so they are comma-separated values, but separated by newlines. I tried
this code:
import numpy as np
file = fromfiletest.txt
a = np.fromfile(file, dtype=np.float, sep=,,
Nils Wagner wrote:
David,
Did you also try ATLAS3.9.1 ?
Is it recommended to use the stable version (3.8.2)
I did not try atlas 3.9.1, but anyone can try. I personally do not want
to package unstable versions, but the vendor directory in numpy
repository should make it relatively easy
jb wrote:
I also tried removing the yum blas/lapack libs and installing atlas
via the instructions given on the scipy site for Ashigabou Repository.
Did you install blas/lapack from ashigabou repository as well ? When I
developed those packages, FC packages for blas/lapack were unusable.
Hi,
I was away during the discussion on the updated complex functions
using C99, and I've noticed it breaks some tests on windows (with mingw;
I have not tried with Visual Studio, but it is likely to make things
even worse given C support from MS compilers):
25 matches
Mail list logo
