On Mon, Oct 5, 2009 at 9:42 PM, Robert Kern wrote:
> On Mon, Oct 5, 2009 at 23:34, Ondrej Certik wrote:
>
>> The only mention of the _import_array() in the documentation that I
>> found is here:
>>
>> http://docs.scipy.org/doc/numpy/reference/c-api.array.html#NO_IMPORT_ARRAY
>>
>>
>> but I don't
Tom K. wrote:
> Chris - I really like this and find it useful. I would change the name to
> something like "growable" or "ArrayList"
hmm. I think I like "growable" or maybe "growarray".
> I think the right amount to grow is 2x -
I think that may be too much.. one if the key advantages of this
On Mon, Oct 5, 2009 at 23:34, Ondrej Certik wrote:
> The only mention of the _import_array() in the documentation that I
> found is here:
>
> http://docs.scipy.org/doc/numpy/reference/c-api.array.html#NO_IMPORT_ARRAY
>
>
> but I don't understand what it means do I have to just call
> _import
On Mon, Oct 5, 2009 at 9:25 PM, Ondrej Certik wrote:
> On Mon, Oct 5, 2009 at 8:38 PM, Ondrej Certik wrote:
>> On Mon, Oct 5, 2009 at 7:34 PM, Charles R Harris
>> wrote:
>>>
>>>
>>> On Mon, Oct 5, 2009 at 7:40 PM, Ondrej Certik wrote:
>> [...]
still alive
Segmentation fault
On Mon, Oct 5, 2009 at 8:38 PM, Ondrej Certik wrote:
> On Mon, Oct 5, 2009 at 7:34 PM, Charles R Harris
> wrote:
>>
>>
>> On Mon, Oct 5, 2009 at 7:40 PM, Ondrej Certik wrote:
> [...]
>>> still alive
>>> Segmentation fault
>>>
>>>
>>>
>>> What puzzles me is that there is no debugging print statem
On Mon, Oct 5, 2009 at 7:34 PM, Charles R Harris
wrote:
>
>
> On Mon, Oct 5, 2009 at 7:40 PM, Ondrej Certik wrote:
[...]
>> still alive
>> Segmentation fault
>>
>>
>>
>> What puzzles me is that there is no debugging print statement just
>> before the segfault.
>
> Maybe you need to flush the buff
Christopher Barker wrote:
>
>
> What do folks think? is this useful? What would you change, etc?
>
Chris - I really like this and find it useful. I would change the name to
something like "growable" or "ArrayList" - accumulator seems like an object
for cumulative summation. I think the righ
On Mon, Oct 5, 2009 at 7:40 PM, Ondrej Certik wrote:
> Hi,
>
> I am getting a segfault in PyArray_SimpleNewFromData in Cython. I am
> trying to debug it for the last 4 hours, but still absolutely no clue,
> so I am posting it here, maybe someone knows where the problem is:
>
> cdef ndarray array_
Hi,
I am getting a segfault in PyArray_SimpleNewFromData in Cython. I am
trying to debug it for the last 4 hours, but still absolutely no clue,
so I am posting it here, maybe someone knows where the problem is:
cdef ndarray array_double_c2numpy(double *A, int len):
from numpy import empty
On Mon, Oct 5, 2009 at 6:57 PM, Charles R Harris
wrote:
>
>
> On Mon, Oct 5, 2009 at 2:10 PM, Pauli Virtanen wrote:
>
>> ma, 2009-10-05 kello 13:54 -0600, Charles R Harris kirjoitti:
>> > Is there an easy way to test build documentation for a module that is
>> > not yet part of numpy?
>>
>> Make
On Mon, Oct 5, 2009 at 2:10 PM, Pauli Virtanen wrote:
> ma, 2009-10-05 kello 13:54 -0600, Charles R Harris kirjoitti:
> > Is there an easy way to test build documentation for a module that is
> > not yet part of numpy?
>
> Make a small Sphinx project for that:
>
> $ easy_install numpydoc
> $ mkdi
On Mon, Oct 5, 2009 at 18:15, Elaine Angelino wrote:
>> Well, what other recarray functionality are you using?
>
> None, in our code. We also thought that since at least some people like
> using the attribute reference property, perhaps users of tabarrays might too
> (though we don't personally
Do the minimum number of .view()s that you can get away with.
>
>
I guess our bottom line is that we're still not 100% clear as to the
recommendation of the NumPy community regarding whether we should use
recarray or ndarray. It seems like recarray has some advantages (e.g. the
nice inference func
On Mon, Oct 5, 2009 at 17:52, Elaine Angelino wrote:
> On Mon, Oct 5, 2009 at 6:36 PM, Robert Kern wrote:
>
>> > the main reason we went with the recarray over the ndarray is because
>> > the
>> > recarray has a couple of useful construction functions (e.g.
>> > np.rec.fromrecords and np.rec.from
On Mon, Oct 5, 2009 at 6:36 PM, Robert Kern wrote:
> >
> > the main reason we went with the recarray over the ndarray is because the
> > recarray has a couple of useful construction functions (e.g.
> > np.rec.fromrecords and np.rec.fromarrays). not only are these functions
> > convenient to us
On Mon, Oct 5, 2009 at 17:16, Elaine Angelino wrote:
> hey pierre -- good question. this is something we debated a while ago (we
> actually sent a couple of emails over the numpy list about this very topic)
> when coming up with our design. at the time, there did not seem to be
> strong opinions
hey pierre -- good question. this is something we debated a while ago (we
actually sent a couple of emails over the numpy list about this very topic)
when coming up with our design. at the time, there did not seem to be
strong opinions either way about using ndarray vs. recarray
the main reason w
On Mon, Oct 5, 2009 at 17:03, Pierre GM wrote:
> All,
> What Python version are we supporting in 1.4.0dev ? 2.4 still ?
Yes.
> For
> which version of numpy will we be moving to a more recent one ?
There is no plan in place to change this requirement.
--
Robert Kern
"I have come to believe th
All,
What Python version are we supporting in 1.4.0dev ? 2.4 still ? For
which version of numpy will we be moving to a more recent one ?
Thx in advance
P.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinf
Ciao Elaine,
I just quickly browsed through your code. Say, what's the reason
behind using np.recarrays instead of just standard ndarrays (with
flexible dtype). Do you really need the overhead of accessing fields
as attributes ? It looks like you're always accessing fields as items...
Cheers
2009/10/5 Christopher Barker :
> Francesc Alted wrote:
>> A Saturday 03 October 2009 10:06:12 Christopher Barker escrigué:
>>> This idea was inspired by a discussion at the SciPy conference, in which
>>> we spent a LOT of time during the numpy tutorial talking about how to
>>> accumulate values in
Hi there,
We are writing to announce the release of "Tabular", a package of Python
modules for working with tabular data.
Tabular is a package of Python modules for working with tabular data. Its
main object is the tabarray class, a data structure for holding and
manipulating tabular data. By put
ma, 2009-10-05 kello 13:54 -0600, Charles R Harris kirjoitti:
> Is there an easy way to test build documentation for a module that is
> not yet part of numpy?
Make a small Sphinx project for that:
$ easy_install numpydoc
$ mkdir foo
$ cd foo
$ sphinx-quickstart
...
$ vi conf.py
... add 'sphinx.ex
On Mon, Oct 5, 2009 at 14:55, Sebastian Haase wrote:
> On Mon, Oct 5, 2009 at 8:43 PM, Robert Kern wrote:
>> On Mon, Oct 5, 2009 at 13:37, Sebastian Haase wrote:
>>> Thanks for the reply.
>>> I thought one reason for amax was that
>>> from numpy import *
>>> would not not import max but only ama
On Mon, Oct 5, 2009 at 8:43 PM, Robert Kern wrote:
> On Mon, Oct 5, 2009 at 13:37, Sebastian Haase wrote:
>> Thanks for the reply.
>> I thought one reason for amax was that
>> from numpy import *
>> would not not import max but only amax.
>
> I have my timelines confused. Numeric has neither amax
Hi All,
Is there an easy way to test build documentation for a module that is not
yet part of numpy?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
All,
Could you try r7449 ? I introduced some mechanisms to keep track of
invalid lines (where the number of columns don't match what's
expected). By default, a warning is emitted and these lines are
skipped, but an optional argument gives the possibility to raise an
exception instead.
Now,
On Mon, Oct 5, 2009 at 13:37, Sebastian Haase wrote:
> Thanks for the reply.
> I thought one reason for amax was that
> from numpy import *
> would not not import max but only amax.
I have my timelines confused. Numeric has neither amax() nor max(). I
don't actually recall the sequence of events,
Thanks for the reply.
I thought one reason for amax was that
from numpy import *
would not not import max but only amax.
How about sum ?
Does "from numpy import *"
overwrite the builtin sum ?
not to mention the "symmetry" / consistency argument for having "asum" ?
More comments ??
--Sebastian Haa
Francesc Alted wrote:
> A Saturday 03 October 2009 10:06:12 Christopher Barker escrigué:
>> This idea was inspired by a discussion at the SciPy conference, in which
>> we spent a LOT of time during the numpy tutorial talking about how to
>> accumulate values in an array when you don't know how big
On Mon, Oct 5, 2009 at 10:56, Sebastian Haase wrote:
> Hi,
>
> Is this a dumb question ?
> Why is there no np.asum() equivalent to np.sum() - like amax() to max() ?
Back when Numeric was being written, max() and min() existed as
builtins, but sum() did not. In order to support "from Numeric impo
Hi,
Is this a dumb question ?
Why is there no np.asum() equivalent to np.sum() - like amax() to max() ?
Another question: what does it mean that amax() (and max()) is a
"function" while maximum() is a ufunc !?
>>> N.max
>>> N.maximum
>>> N.amax
Is there a performance difference connected to
On Mon, Oct 5, 2009 at 4:52 PM, wrote:
> On Mon, Oct 5, 2009 at 5:37 AM, Sebastian Walter
> wrote:
>> On Fri, Oct 2, 2009 at 10:40 PM, wrote:
>>> On Fri, Oct 2, 2009 at 3:38 PM, Charles R Harris
>>> wrote:
On Fri, Oct 2, 2009 at 12:30 PM, wrote:
>
> On Fri, Oct 2, 2009
On Mon, Oct 5, 2009 at 5:37 AM, Sebastian Walter
wrote:
> On Fri, Oct 2, 2009 at 10:40 PM, wrote:
>> On Fri, Oct 2, 2009 at 3:38 PM, Charles R Harris
>> wrote:
>>>
>>>
>>> On Fri, Oct 2, 2009 at 12:30 PM, wrote:
On Fri, Oct 2, 2009 at 2:09 PM, Charles R Harris
wrote:
>
>>>
On Mon, Oct 5, 2009 at 9:00 AM, Paul Rudin wrote:
>
> denis bzowy writes:
>
>> Folks,
>> http://groups.google.com/group/numpy-discussion
>> ->
>> The group named numpy-discussion has been removed because it violated
>> Google's
>> Terms Of Service
>>
>> however scipy-user is there; how come ?
denis bzowy writes:
> Folks,
> http://groups.google.com/group/numpy-discussion
> ->
> The group named numpy-discussion has been removed because it violated Google's
> Terms Of Service
>
> however scipy-user is there; how come ?
>
> I like google groups for its viewer, otherwise don't care much
Folks,
http://groups.google.com/group/numpy-discussion
->
The group named numpy-discussion has been removed because it violated Google's
Terms Of Service
however scipy-user is there; how come ?
I like google groups for its viewer, otherwise don't care much.
What mail / group viewer do experts u
Original Message
Subject: [f2py] ANN: a journal paper about F2PY has been published
Date: Mon, 05 Oct 2009 11:52:20 +0300
From: Pearu Peterson
Reply-To: For users of the f2py program
To: For users of the f2py program
Hi,
A journal paper about F2PY has been published in Inte
jah gmail.com> writes:
> Thanks all. Robert, griddata is exactly what I was looking for. David, I
think that should work too. And Denis, griddata is sufficiently fast that I am
not complaining---contouring about 1e6 or 1e7 points typically.
>
Fyinfo, take a look at http://yt.enzotools.org
"Y
On Fri, Oct 2, 2009 at 10:40 PM, wrote:
> On Fri, Oct 2, 2009 at 3:38 PM, Charles R Harris
> wrote:
>>
>>
>> On Fri, Oct 2, 2009 at 12:30 PM, wrote:
>>>
>>> On Fri, Oct 2, 2009 at 2:09 PM, Charles R Harris
>>> wrote:
>>> >
>>> >
>>> > On Fri, Oct 2, 2009 at 11:35 AM, Charles R Harris
>>> > wr
A Saturday 03 October 2009 10:06:12 Christopher Barker escrigué:
> OK -- this one I'm intending to send!
>
> Hi all,
>
> This idea was inspired by a discussion at the SciPy conference, in which
> we spent a LOT of time during the numpy tutorial talking about how to
> accumulate values in an array w
41 matches
Mail list logo
