Ralf Gommers wrote:
> Hi all,
>
> I'm trying to read in data from text files with genfromtxt, and have
> some trouble figuring out the right combination of keywords. The
> format is:
>
> ['0\t\t4.000e+007,0.000e+000\n',
> '\t9.860280631554179e-001,-1.902586503306264e-002\
David Cournapeau wrote:
> Kurt Smith wrote:
>
>
>> I'm the developer of fwrap. It is coming along, but will be at least
>> a month, likely two before the first release. (The main areas that
>> need some TLC are the fortran parser and the build system; the build
>> system will leverage numpy's
On Thu, Feb 25, 2010 at 11:56:34PM -0800, Nathaniel Smith wrote:
> So there's this patch I submitted:
> http://projects.scipy.org/numpy/ticket/1402
> Obviously not that high a priority in the grand scheme of things (it
> adds a function to compute the log-determinant directly), but I don't
> want
On Fri, Feb 26, 2010 at 4:29 PM, Warren Weckesser <
warren.weckes...@enthought.com> wrote:
> Ralf Gommers wrote:
> > Hi all,
> >
> > I'm trying to read in data from text files with genfromtxt, and have
> > some trouble figuring out the right combination of keywords. The
> > format is:
> >
> > ['0\
On Fri, Feb 26, 2010 at 03:52:10AM -0500, David Warde-Farley wrote:
> On Thu, Feb 25, 2010 at 11:56:34PM -0800, Nathaniel Smith wrote:
> > So there's this patch I submitted:
> > http://projects.scipy.org/numpy/ticket/1402
> > Obviously not that high a priority in the grand scheme of things (it
>
Hi,
I want to apply a function to all indices of an array that fullfill a
certain condition.
What I tried:
-8<
import numpy
def myfunc(x):
print 'myfunc of', x
a = numpy.random.random((2,3,4))
numpy.apply_along_axis(myfunc, 0, numpy.where
David Warde-Farley wrote:
> My first
> instinct would be to look for "logdet", but I would also not expect such
> a function to return the log determinant *and* the sign of the
> determinant.
What about having logadet for the (common) case where log |A| only is
needed, and having the more comple
On Fri, Feb 26, 2010 at 07:23:54PM +0900, David Cournapeau wrote:
> David Warde-Farley wrote:
> > My first
> > instinct would be to look for "logdet", but I would also not expect such
> > a function to return the log determinant *and* the sign of the
> > determinant.
> What about having logadet f
Dag Sverre Seljebotn wrote:
> (I'd think one basically has to make the same blatant assumptions that
> f2py makes about type conversion, name mangling etc., but that is also
> much less dangerous/error-prone for Fortran 77.)
Everything related to name mangling can be handled by
distutils/numsc
On Fri, Feb 26, 2010 at 11:26:28AM +0100, Gael Varoquaux wrote:
> I was more thinking of a 'return_sign=False' keyword argument.
My thoughts exactly.
David
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listi
Gael Varoquaux wrote:
> On Fri, Feb 26, 2010 at 07:23:54PM +0900, David Cournapeau wrote:
>> David Warde-Farley wrote:
>>> My first
>>> instinct would be to look for "logdet", but I would also not expect such
>>> a function to return the log determinant *and* the sign of the
>>> determinant.
>
>>
===
Announcing PyTables 2.2b3
===
PyTables is a library for managing hierarchical datasets and designed to
efficiently cope with extremely large amounts of data with support for
full 64-bit file addressing. PyTables runs on top of the HDF5 library
Hi,
26/02/10 @ 11:23 (+0100), thus spake Ole Streicher:
> Hi,
>
> I want to apply a function to all indices of an array that fullfill a
> certain condition.
>
> What I tried:
>
> -8<
> import numpy
>
> def myfunc(x):
> print 'myfunc of', x
pe, 2010-02-26 kello 12:43 +0100, Ernest Adrogué kirjoitti:
[clip]
> Or if you want to produce a different array of the same shape
> as the original, then you probably need a vectorised function.
>
> def myfunc(x):
> print 'myfunc of', x
> if x > 0.8:
> return x + 2
> els
Hello Ernest,
Ernest Adrogué writes:
> It depends on what exactly you want to do. If you just want
> to iterate over the array, try something liks this
> for element in a[a > 0.8]:
> myfunc(element)
No; I need to iterate over the *indices*, not over the elements.
a = numpy.random.random((
26/02/10 @ 13:31 (+0100), thus spake Ole Streicher:
> Hello Ernest,
>
> Ernest Adrogué writes:
> > It depends on what exactly you want to do. If you just want
> > to iterate over the array, try something liks this
> > for element in a[a > 0.8]:
> > myfunc(element)
>
> No; I need to iterate o
Hello
a VERY specific question, but I thought someone in the list might have
used this dataset before and could give me some advice
I am trying to read the daily Antarctic Sea Ice Concentrations from
Nimbus-7 SMMR and DMSP SSM/I Passive Microwave Data, as provided by
the national snow and ice dat
Nicolas wrote:
> Hello
>
> a VERY specific question, but I thought someone in the list might have
> used this dataset before and could give me some advice
>
> I am trying to read the daily Antarctic Sea Ice Concentrations from
> Nimbus-7 SMMR and DMSP SSM/I Passive Microwave Data, as provided by
>
26/02/10 @ 13:51 (+0200), thus spake Pauli Virtanen:
> pe, 2010-02-26 kello 12:43 +0100, Ernest Adrogué kirjoitti:
> [clip]
> > Or if you want to produce a different array of the same shape
> > as the original, then you probably need a vectorised function.
> >
> > def myfunc(x):
> > print 'myf
On Fri, Feb 26, 2010 at 04:42, David Cournapeau wrote:
> I don't really know the assumptions made by f2py otherwise: is it
> prevalent for most fortran compilers to pass most things by reference ?
I think that's part of the standardized semantics, yes. That said,
some things in the C API like ho
On Fri, Feb 26, 2010 at 8:06 AM, Robert Kern wrote:
> On Fri, Feb 26, 2010 at 04:42, David Cournapeau
> wrote:
>
> > I don't really know the assumptions made by f2py otherwise: is it
> > prevalent for most fortran compilers to pass most things by reference ?
>
> I think that's part of the standa
On Thu, Feb 25, 2010 at 7:18 PM, David Cournapeau wrote:
> Kurt Smith wrote:
>
>> I'm the developer of fwrap. It is coming along, but will be at least
>> a month, likely two before the first release. (The main areas that
>> need some TLC are the fortran parser and the build system; the build
>>
On Fri, Feb 26, 2010 at 2:44 AM, Dag Sverre Seljebotn
wrote:
> David Cournapeau wrote:
>> Kurt Smith wrote:
>>
>>
>>> I'm the developer of fwrap. It is coming along, but will be at least
>>> a month, likely two before the first release. (The main areas that
>>> need some TLC are the fortran pars
On Fri, Feb 26, 2010 at 4:42 AM, David Cournapeau wrote:
> Dag Sverre Seljebotn wrote:
>
>> (I'd think one basically has to make the same blatant assumptions that
>> f2py makes about type conversion, name mangling etc., but that is also
>> much less dangerous/error-prone for Fortran 77.)
>
> Every
Hi,
I built an installer for OS X and did some testing on a clean computer. All
NumPy tests pass. SciPy (0.7.1 binary) gives a number of errors and
failures, I copied one of each type below. For full output see
http://pastebin.com/eEcwkzKr . To me it looks like the failures are
harmless, and the k
On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
wrote:
> Hi,
>
> I built an installer for OS X and did some testing on a clean computer. All
> NumPy tests pass. SciPy (0.7.1 binary) gives a number of errors and
> failures, I copied one of each type below. For full output see
> http://pastebin.com/e
pe, 2010-02-26 kello 12:09 -0500, josef.p...@gmail.com kirjoitti:
> On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
[clip]
> > ValueError: numpy.dtype does not appear to be the correct type object
>
> This looks like the cython type check problem, ckdtree.c doesn't look
> compatible with your nump
On Fri, Feb 26, 2010 at 12:19 PM, Pauli Virtanen wrote:
> pe, 2010-02-26 kello 12:09 -0500, josef.p...@gmail.com kirjoitti:
>> On Fri, Feb 26, 2010 at 12:00 PM, Ralf Gommers
> [clip]
>> > ValueError: numpy.dtype does not appear to be the correct type object
>>
>> This looks like the cython type ch
pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
[clip]
> recompiling wouldn't be enough, the cython c files also need to be
> regenerated for a different numpy version.
> (If I understand the problem correctly.)
No. The Cython-generated sources just use sizeof(PyArray_Descr), the
On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
> [clip]
> > recompiling wouldn't be enough, the cython c files also need to be
> > regenerated for a different numpy version.
> > (If I understand the problem correctly.)
>
On Fri, 2010-02-26 at 07:56 +, numpy-discussion-requ...@scipy.org
wrote:
> Date: Thu, 25 Feb 2010 13:56:43 -0800
> From: Chris Barker
> Subject: Re: [Numpy-discussion] read ascii file with quote delimited
> strings
> To: Discussion of Numerical Python
> Message-ID: <4b86f21b.5070...@n
On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
wrote:
>
>
> On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
>>
>> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
>> [clip]
>> > recompiling wouldn't be enough, the cython c files also need to be
>> > regenerated for a
On Fri, Feb 26, 2010 at 10:44 AM, wrote:
> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
> >>
> >> pe, 2010-02-26 kello 12:26 -0500, josef.p...@gmail.com kirjoitti:
> >> [clip]
> >> > recompiling wouldn't be enoug
On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
wrote:
>
>
> On Fri, Feb 26, 2010 at 10:44 AM, wrote:
>>
>> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virtanen wrote:
>> >>
>> >> pe, 2010-02-26 kello 12:26 -0500, josef.
On Fri, Feb 26, 2010 at 10:53 AM, wrote:
> On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
> wrote:
> >
> >
> > On Fri, Feb 26, 2010 at 10:44 AM, wrote:
> >>
> >> On Fri, Feb 26, 2010 at 12:41 PM, Charles R Harris
> >> wrote:
> >> >
> >> >
> >> > On Fri, Feb 26, 2010 at 10:34 AM, Pauli Virt
On Fri, Feb 26, 2010 at 11:26 AM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
> On Fri, Feb 26, 2010 at 10:53 AM, wrote:
>
>> On Fri, Feb 26, 2010 at 12:50 PM, Charles R Harris
>> wrote:
>> >
>> >
>> > On Fri, Feb 26, 2010 at 10:44 AM, wrote:
>> >>
>> >> On Fri, Feb 26, 2010 at 12:
On Feb 26, 2010, at 12:42 PM, Sam Tygier wrote:
> On Fri, 2010-02-26 at 07:56 +, numpy-discussion-requ...@scipy.org
> wrote:
>> Date: Thu, 25 Feb 2010 13:56:43 -0800
>> From: Chris Barker
>>
>> if not, I'd use the std lib csv module, then convert to numpy arrays,
>> not as efficient, but it s
On 25 February 2010 00:46, Charles R Harris wrote:
> They are now typecodes but have no entries in the typename dictionary.
IIUC, p/P should map to signed/unsigned integers large enough to hold
a pointer on the platform.. So perhaps their names should be intpr_t
and uintptr_t ?
>
> The 'm', 'M'
I'm making a mistake here, one that I suspect is a dumb error. I'm not as
familiar with the math of complex hermetian matrices as I am with real
symmetry matrices.
I want to diagonalize the matrix:
Y = matrix([[0,-1j],[1j,0]]) # this is the Y Pauli spin matrix
Ey,Uy = eigh(Y)
When I try to
Nicolas,
I've attached a script I used to load the files, metadata and coordinates.
You owe me a donut.
David
On Fri, Feb 26, 2010 at 8:11 AM, Dag Sverre Seljebotn
wrote:
> Nicolas wrote:
>> Hello
>>
>> a VERY specific question, but I thought someone in the list might have
>> used this dataset
On Fri, Feb 26, 2010 at 4:01 PM, Rick Muller wrote:
> I'm making a mistake here, one that I suspect is a dumb error. I'm not as
> familiar with the math of complex hermetian matrices as I am with real
> symmetry matrices.
>
> I want to diagonalize the matrix:
>
> Y = matrix([[0,-1j],[1j,0]]) #
I have a 1D structured ndarray with several different fields in the dtype. I'm
using multiprocessing.Pool.map() to iterate over this structured ndarray,
passing one entry (of type numpy.void) at a time to the function to be called
by
each process in the pool. After much confusion about why this
On Fri, Feb 26, 2010 at 16:41, Martin Spacek wrote:
> I have a 1D structured ndarray with several different fields in the dtype. I'm
> using multiprocessing.Pool.map() to iterate over this structured ndarray,
> passing one entry (of type numpy.void) at a time to the function to be called
> by
> e
pe, 2010-02-26 kello 14:41 -0800, Martin Spacek kirjoitti:
[clip: pickling/unpickling numpy.void scalar objects]
> I suppose numpy.void is as it suggests, a pointer to a specific place in
> memory.
> I'm just surprised that this pointer isn't dereferenced before pickling Or is
> it? I'm not skil
On Sat, Feb 27, 2010 at 2:44 AM, wrote:
>
> I think I mixed up some things then,
> scipy 0.7.1 cython files should be regenerated with the latest cython
> release so that it doesn't check the sizeof anymore.
> Then, a scipy 0.7.1 build against numpy 1.3 would also work without
> recompiling agai
Argh! I mixed up where the .H went!!
Thanks for pointing out the mistake. Thought it was something mindless.
On Fri, Feb 26, 2010 at 2:18 PM, wrote:
> On Fri, Feb 26, 2010 at 4:01 PM, Rick Muller wrote:
> > I'm making a mistake here, one that I suspect is a dumb error. I'm not as
> > familiar
Hi there,
I'm having a lot of trouble on Snow Leopard.
I'm trying to build a 32bit only version of our system
Turns out I had to use python 2.7a3 in order to get Python --universalsdk to
work
But now numpy fails to build as well...
First because of the:
>> _old_init_posix = distu
On 26-Feb-10, at 7:43 PM, Charles سمير Doutriaux wrote:
> Any idea on how to build a pure 32bit numpy on snow leopard?
If I'm not mistaken you'll probably want to build against the
Python.org Python rather than the wacky version that comes installed
on the system. The Python.org installer is
On 2010-02-26 15:02, Robert Kern wrote:
>> Is this a known limitation?
>
> Nope. New bug! Thanks!
Good. I'm not crazy after all :)
> Pickling of complete arrays works. A quick workaround would be to send
> rank-0 scalars:
>
>Pool.map(map(np.asarray, x))
>
> Or just tuples:
>
>Pool.map(map
On 2010-02-26 15:26, Pauli Virtanen wrote:
> No, the unpickled void scalar will own its data. The problem is that
> either the data is not saved correctly (unlikely), or it is unpickled
> incorrectly.
>
> The relevant code path to look at is multiarraymodule:array_scalar ->
> scalarapi.c:PyArray_Sc
On Fri, Feb 26, 2010 at 6:59 PM, David Warde-Farley wrote:
> On 26-Feb-10, at 7:43 PM, Charles سمير Doutriaux wrote:
>
>> Any idea on how to build a pure 32bit numpy on snow leopard?
>
> If I'm not mistaken you'll probably want to build against the
> Python.org Python rather than the wacky version
On Sat, Feb 27, 2010 at 8:17 AM, David Cournapeau wrote:
> On Sat, Feb 27, 2010 at 2:44 AM, wrote:
>
> >
> > I think I mixed up some things then,
> > scipy 0.7.1 cython files should be regenerated with the latest cython
> > release so that it doesn't check the sizeof anymore.
> > Then, a scipy 0
I am out of the office until 03/06/2010.
I will be traveling through Saturday, March 6 and will be delayed
responding to your email. I will have periodic email access, but I will be
many time zones away from my usual location.
Note: This is an automated response to your message "NumPy-Discus
On Sat, Feb 27, 2010 at 11:59 AM, Ralf Gommers
wrote:
>
>
> So here is how I see things in the near future for release:
> - compile a simple binary installer for mac os x and windows (no need
> for doc or multiple archs) from 1.4.x
> - test this with the scipy binary out there (running the full
On Sat, Feb 27, 2010 at 2:33 PM, David Cournapeau wrote:
>
> Sorry, I should have been clearer in the above quoted list. There were
> two issues with numpy 1.4.0, one caused by datetime, and one caused by
> other changes to growing structures. The second one is ok for most
> cases, but cython < 0.
On Sat, Feb 27, 2010 at 3:43 PM, Ralf Gommers
wrote:
>
> Yes that is clear. Would it make sense to first release scipy 0.7.2 though?
> Then numpy 1.4.1 can be tested against it and we can be sure it works. The
> other way around it's not possible to test.
Yes it is, you just have to build scipy
56 matches
Mail list logo
