Hi,
I am sub-classing numpy.ndarry for vector array representation. The append
function is like this:
def append(self, other):
self = numpy.append(self, [other], axis=0)
Example:
vary = VectorArray([v1, v2])
#vary = numpy.append(vary, [v1], axis=0)
vary.append(v1)
The commented synt
On Fri, Mar 30, 2012 at 4:08 PM, Maggie Mari wrote:
> Hello, everyone.
>
> I work with Travis at Continuum, and he asked me to setup a YouTrack
> server that everyone is welcome to play around with. There is a test
> project currently set up, with some fake tickets.
>
> Here is the address:
>
>
Hello, everyone.
I work with Travis at Continuum, and he asked me to setup a YouTrack
server that everyone is welcome to play around with. There is a test
project currently set up, with some fake tickets.
Here is the address:
http://ec2-107-21-65-210.compute-1.amazonaws.com:8011/issues
On 30 March 2012 21:40, mark florisson wrote:
> On 30 March 2012 21:38, mark florisson wrote:
>> On 30 March 2012 19:53, Chris Barker wrote:
>>> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
>>> wrote:
Although the segfault was caused by a bug in NumPy, you should
probably also con
On 30 March 2012 21:38, mark florisson wrote:
> On 30 March 2012 19:53, Chris Barker wrote:
>> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
>> wrote:
>>> Although the segfault was caused by a bug in NumPy, you should
>>> probably also consider using Cython, which can make a lot of this pain
On 30 March 2012 19:53, Chris Barker wrote:
> On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
> wrote:
>> Although the segfault was caused by a bug in NumPy, you should
>> probably also consider using Cython, which can make a lot of this pain
>> and boring stuff go away.
>
> Is there a good demo
On Fri, Mar 30, 2012 at 10:57 AM, mark florisson
wrote:
> Although the segfault was caused by a bug in NumPy, you should
> probably also consider using Cython, which can make a lot of this pain
> and boring stuff go away.
Is there a good demo/sample somewhere of an ndarray subclass in Cython?
So
On 29 March 2012 09:07, Christoph Gohle wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Am 08.03.2012 um 20:39 schrieb Pauli Virtanen:
>
>> 08.03.2012 17:37, Christoph Gohle kirjoitti:
>>> thanks for testing. I have now tried on different platforms. I get
>>> all kinds of crashes on
On Fri, Mar 30, 2012 at 2:20 PM, Tim Cera wrote:
>> My suggestion is:
>> Step 1: Change the current PR so that it has only one user-exposed
>> function, something like pad(..., mode="foo"), and commit that.
>> Everyone seems to pretty much like that interface, implementing it
>> would take <1 hour
>
> My suggestion is:
> Step 1: Change the current PR so that it has only one user-exposed
> function, something like pad(..., mode="foo"), and commit that.
> Everyone seems to pretty much like that interface, implementing it
> would take <1 hour of work, and then the basic functionality would be
>
I rearranged your questions.
Why is this function allocating new arrays that will just be
> copied into the big array and then discarded, instead of filling in
> the big array directly? (Again, this is a speed issue.)
My example in the e-mail was incorrect (sorry about that). The way it
actuall
On Fri, Mar 30, 2012 at 1:22 PM, Charles R Harris
wrote:
>
>
> On Fri, Mar 30, 2012 at 5:41 AM, Nathaniel Smith wrote:
>>
>> On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera wrote:
>> > If instead you passed in a function:
>> >
>> > def padwithzeros(vector, pad_width, iaxis, **kwargs):
>> >
On Fri, Mar 30, 2012 at 5:41 AM, Nathaniel Smith wrote:
> On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera wrote:
> > If instead you passed in a function:
> >
> > def padwithzeros(vector, pad_width, iaxis, **kwargs):
> > bvector = np.zeros(pad_width[0])
> > avector = np.zeros(pad_wi
On Thu, Mar 29, 2012 at 6:53 PM, Tim Cera wrote:
> If instead you passed in a function:
>
> def padwithzeros(vector, pad_width, iaxis, **kwargs):
> bvector = np.zeros(pad_width[0])
> avector = np.zeros(pad_width[1])
> return bvector, avector
>
> b = pad(padwithzeros
On Fri, Mar 30, 2012 at 8:35 AM, Richard Hattersley
wrote:
> I like where this is going.
>
> Driven by a desire to avoid a million different methods on a single
> class, we've done something similar in our library.
> So instead of
> thing.mean()
> thing.max(...)
> etc.
> we have:
> thi
I like where this is going.
Driven by a desire to avoid a million different methods on a single
class, we've done something similar in our library.
So instead of
thing.mean()
thing.max(...)
etc.
we have:
thing.scrunch(MEAN, ...)
thing.scrunch(MAX, ...)
etc.
Where the constant
16 matches
Mail list logo
