Hi Bruce,
In the context of the actual problem, I have a long series of
non-equidistant and irregularly spaced float numbers and I have to take
values between given limits with the constraint of keeping a minimal
separation. Option 2 just misses the first value of the input array if
it is
On Thu, Jun 10, 2010 at 1:16 PM, Bino Oetomo b...@indoakses-online.com wrote:
Dear All ..
I tried to install numpy and scipy ... basicaly I want to use OMPC
You need at least numpy 1.4 to build scipy from current svn,
David
___
NumPy-Discussion
On Wed, Jun 9, 2010 at 5:27 PM, Jason McCampbell
jmccampb...@enthought.comwrote:
Hi everyone,
This is a follow-up to Travis's message on the re-factoring project from
May 25th and the subsequent discussion. For background, I am a developer at
Enthought working on the NumPy re-factoring
On Thu, Jun 10, 2010 at 7:26 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Wed, Jun 9, 2010 at 5:27 PM, Jason McCampbell
jmccampb...@enthought.com wrote:
Hi everyone,
This is a follow-up to Travis's message on the re-factoring project from
May 25th and the subsequent
Hi Chuck,
Good questions. Responses inline below...
Jason
On Thu, Jun 10, 2010 at 8:26 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Wed, Jun 9, 2010 at 5:27 PM, Jason McCampbell
jmccampb...@enthought.com wrote:
Hi everyone,
This is a follow-up to Travis's message on the
I have a few radical suggestions:
1. Use ctypes as glue to the core DLL, so we can completely forget about
refcounts and similar mess. Why put manual reference counting and error
handling in the core? It's stupid.
2. The core should be a plain DLL, loadable with ctypes. (I know David
Den 10.06.2010 18:48, skrev Sturla Molden:
ctypes will also make porting to other Python implementations easier
(or even other languages: Ruby, JacaScript) easier. Not to mention
that it will make NumPy impervious to changes in the Python C API.
Linking is also easier with ctypes. I started
Another suggestion I'd like to make is bytearray as memory buffer for
the ndarray. An ndarray could just store or extend a bytearray, instead
of having to deal with malloc/free and and the mess that comes with it.
Python takes care of the reference counts for bytearrays, and ctypes
calls the
On Fri, Jun 11, 2010 at 6:56 AM, Sturla Molden stu...@molden.no wrote:
Also about array iterators in NumPy's C base (i.e. for doing something
along an axis): we don't need those. There is a different way of coding
which leads to faster code.
1. Collect an array of pointers to each subarray
Wes,
Sorry to contact you directly. I answered to this ad on 05/24, sending a cover
letter and a link to my resume to Matt. However, I didn't get any news since.
Do you mind telling me how to check the status of my application ? If it is
rejected, so it goes, but I'd still like to know.
In
Hello,
I have posted previously about dates prior to 1900 but this seems to be a
seperate issue. The error message is definitley different.
I can not seem to convert a timseseries from one frequency ('D') to another
('H') when i use dates prior to 1970 as shown below. This works fine when I
On Jun 10, 2010, at 11:48 AM, Sturla Molden wrote:
I have a few radical suggestions:
There are some good ideas there. I suspect we can't address all of them in
the course of this re-factoring effort, but I really appreciate you putting
them out there, because they are useful things to
Den 10.06.2010 22:28, skrev Pauli Virtanen:
Some places where Openmp could probably help are in the inner ufunc
loops. However, improving the memory efficiency of the data access
pattern is another low-hanging fruit for multidimensional arrays.
Getting the intermediate array out of
Thu, 10 Jun 2010 18:48:04 +0200, Sturla Molden wrote:
[clip]
5. Allow OpenMP pragmas in the core. If arrays are above a certain size,
it should switch to multi-threading.
Some places where Openmp could probably help are in the inner ufunc
loops. However, improving the memory efficiency of the
On Fri, Jun 11, 2010 at 7:25 AM, Sturla Molden stu...@molden.no wrote:
Den 10.06.2010 22:07, skrev Travis Oliphant:
2. The core should be a plain DLL, loadable with ctypes. (I know David
Cournapeau and Robert Kern is going to hate this.) But if Python can have a
custom loader for .pyd
Den 10.06.2010 22:07, skrev Travis Oliphant:
2. The core should be a plain DLL, loadable with ctypes. (I know David
Cournapeau and Robert Kern is going to hate this.) But if Python can have a
custom loader for .pyd files, so can NumPy for it's core DLL. For ctypes we
just need to specify a
Oops, somebody should double check who's in copy before sending his emails...
Sorry about the noise all.
However, feel free to contact me offlist w/ your ideas regarding handling time
series in numpy.
All my apologies again.
P.
___
NumPy-Discussion
Den 11.06.2010 00:57, skrev David Cournapeau:
Do you have the code for this ? That's something I wanted to do, but
never took the time to do. Faster generic iterator would be nice, but
very hard to do in general.
/* this computes the start adress for every vector along a dimension
(axis)
On Thu, Jun 10, 2010 at 6:27 PM, Sturla Molden stu...@molden.no wrote:
Den 11.06.2010 00:57, skrev David Cournapeau:
Do you have the code for this ? That's something I wanted to do, but
never took the time to do. Faster generic iterator would be nice, but
very hard to do in general.
On 06/11/2010 10:02 AM, Charles R Harris wrote:
But for an initial refactoring it probably falls in the category of
premature optimization. Another thing to avoid on the first go around is
micro-optimization, as it tends to complicate the code and often doesn't
do much for performance.
I
On 06/11/2010 09:27 AM, Sturla Molden wrote:
Strided memory access is slow. So it often helps to make a temporary
copy that are contiguous.
Ah, ok, I did not know this was called copy-in/copy-out, thanks for the
explanation. I agree this would be a good direction to pursue, but maybe
out of
Den 11.06.2010 04:19, skrev David:
Ah, ok, I did not know this was called copy-in/copy-out, thanks for the
explanation. I agree this would be a good direction to pursue, but maybe
out of scope for the first refactoring,
Copy-in copy-out is actually an implementation detail in Fortran
On Jun 10, 2010, at 7:16 PM, Bevan Jenkins wrote:
Hello,
I have posted previously about dates prior to 1900 but this seems to be a
seperate issue. The error message is definitley different.
I can not seem to convert a timseseries from one frequency ('D') to another
('H') when i use dates
Den 11.06.2010 03:02, skrev Charles R Harris:
But for an initial refactoring it probably falls in the category of
premature optimization. Another thing to avoid on the first go around
is micro-optimization, as it tends to complicate the code and often
doesn't do much for performance.
On Thu, Jun 10, 2010 at 8:40 PM, Sturla Molden stu...@molden.no wrote:
Den 11.06.2010 03:02, skrev Charles R Harris:
But for an initial refactoring it probably falls in the category of
premature optimization. Another thing to avoid on the first go around
is micro-optimization, as it
25 matches
Mail list logo
