thanks!
On Wed, Feb 25, 2009 at 1:22 AM, Andrew Straw wrote:
> Given what you're doing, may I also suggest having a look at
> http://code.astraw.com/projects/motmot/wxglvideo.html
>
> -Andrew
>
> Chris Colbert wrote:
> > As an update for any future googlers:
> >
> > the problem was with revpixel
Given what you're doing, may I also suggest having a look at
http://code.astraw.com/projects/motmot/wxglvideo.html
-Andrew
Chris Colbert wrote:
> As an update for any future googlers:
>
> the problem was with revpixels = pixeldata[::-1,:,;:-1] which apparently
> returns an array that is discont
Ralph Heinkel wrote:
> However here something is strange:
>
>
arr = array([('john', 4),('mark', 3)],
> dtype=[(('source:yy', 'name'),'O'),(('source:xx','id'),int)])
>
arr[0]
> ('john', 4)
>
arr[0][0]
> Traceback (most recent cal
On Wed, Feb 25, 2009 at 3:26 AM, Charles R Harris
wrote:
>
> Good point. However, most of the ufuncs involving standard functions like
> sin, cos, etc. are implemented as generic loops that are passed a function
> pointer and for such functions the call overhead is probably not significant
> in t
As an update for any future googlers:
the problem was with revpixels = pixeldata[::-1,:,;:-1] which apparently
returns an array that is discontinuous in memory. What Lisandro suggested
worked. pixeldata[::-1,:,;:-1].copy() returns a continuous array object
which natively implements a single-segment
thanks for both answers!
Lisandro, you're right, I should have declared the array outside the loop.
Thanks for catching that!
Robert, as always, thanks for the answer. Quick and to the point! You've
helped me more than once on the enthought list :)
On Tue, Feb 24, 2009 at 8:06 PM, Lisandro Dal
When you do pixeldata[::-1,:,::-1], you just got a new array with
different strides, but now non-contiguous... So I believe you really
need a fresh copy of the data... tostring() copies, but could be
slow... try to use
revpixels = pixeldata[::-1,:,::-1].copy()
...
rgbBMP = wx.BitmapFromBuffer(64
On Tue, Feb 24, 2009 at 18:15, Chris Colbert wrote:
> Hi all,
>
> I'm new to mailing list and relatively new (~1 year) to python/numpy. I
> would appreciate any insight any of you may have here. The last 8 hours of
> digging through the docs has left me, finally, stuck.
>
> I am making a wxPython
Hi all,
I'm new to mailing list and relatively new (~1 year) to python/numpy. I
would appreciate any insight any of you may have here. The last 8 hours of
digging through the docs has left me, finally, stuck.
I am making a wxPython program that includes webcam functionality. The
script below jus
Hi,
> The variable-length string dtypes are not builtin. The user-defined
> lengths make them user-defined dtypes.
Right - but I was failing to understand, from the code, how '0' rather
than '2' could result. Have I missed something?
> If you want a real kick in the pants, try playing with dtyp
On Tue, Feb 24, 2009 at 15:04, Matthew Brett wrote:
> Hi,
>
> I was just trying to write a docstring for np.dtype.isbuiltin, when I
> realized I didn't understand it.
>
> As far as I can see, isbuitin should return:
>
> 0 for structured array dtypes
> 1 for types compiled into numpy
> 2 for extens
Hi,
I was just trying to write a docstring for np.dtype.isbuiltin, when I
realized I didn't understand it.
As far as I can see, isbuitin should return:
0 for structured array dtypes
1 for types compiled into numpy
2 for extension types using the numpy C-API type extension machinery.
Here's the
haha, so it was a stupid error...my stupid error. [?]
I incorrectly understood ([0,0],[1,1]) as index 0 of *a* summed with index 0
of *b*, and analogously for [1,1].
Gthanks, Josef
On Tue, Feb 24, 2009 at 3:20 PM, wrote:
> On Tue, Feb 24, 2009 at 2:55 PM, Jose Borreguero
> wrote:
> > The foll
On Tuesday 24 February 2009 14:39:39 Christopher Barker wrote:
> I'm having a bit of trouble getting fancy indexing to do what I want.
Use ix_:
In [2]: a
Out[2]:
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11],
[12, 13, 14, 15],
[16, 17, 18, 19],
[20
On Tue, Feb 24, 2009 at 2:55 PM, Jose Borreguero wrote:
> The following example:
>
> from numpy import *
> a=arange(12).reshape(2,3,2)
> b=arange(24).reshape(2,3,2,2)
> c=tensordot( a,b,axes=([0,0],[1,1]) )
>
> defaults:
> c=tensordot( a,b,axes=([0,0],[1,1]) )
> File "/usr/lib/python2.4/site-packa
On Tue, Feb 24, 2009 at 1:39 PM, Christopher Barker
wrote:
> HI all,
>
> I'm having a bit of trouble getting fancy indexing to do what I want.
>
> Say I have a 2-d array:
>
> >>> a
> array([[ 0, 1, 2, 3],
>[ 4, 5, 6, 7],
>[ 8, 9, 10, 11],
>[12, 13, 14, 15],
>
Robert Kern wrote:
> On Tue, Feb 24, 2009 at 13:39, Christopher Barker
> wrote:
>> >>> a
>> array([[ 0, 1, 2, 3],
>>[ 4, 5, 6, 7],
>>[ 8, 9, 10, 11],
>>[12, 13, 14, 15],
>>[16, 17, 18, 19],
>>[20, 21, 22, 23]])
>>
>> I want to extract a sub-array:
The following example:
from numpy import *
a=arange(12).reshape(2,3,2)
b=arange(24).reshape(2,3,2,2)
c=tensordot( a,b,axes=([0,0],[1,1]) )
defaults:
c=tensordot( a,b,axes=([0,0],[1,1]) )
File "/usr/lib/python2.4/site-packages/numpy/core/numeric.py", line 359, in
tensordot
raise ValueError, "shape
On Tue, Feb 24, 2009 at 13:39, Christopher Barker wrote:
> HI all,
>
> I'm having a bit of trouble getting fancy indexing to do what I want.
>
> Say I have a 2-d array:
>
> >>> a
> array([[ 0, 1, 2, 3],
> [ 4, 5, 6, 7],
> [ 8, 9, 10, 11],
> [12, 13, 14, 15],
> [
HI all,
I'm having a bit of trouble getting fancy indexing to do what I want.
Say I have a 2-d array:
>>> a
array([[ 0, 1, 2, 3],
[ 4, 5, 6, 7],
[ 8, 9, 10, 11],
[12, 13, 14, 15],
[16, 17, 18, 19],
[20, 21, 22, 23]])
I want to extract a sub-array:
On Tue, Feb 24, 2009 at 11:09 AM, Matthieu Brucher <
matthieu.bruc...@gmail.com> wrote:
> In fact, the __inline is not helpful. It's the static keyword that
> enables the compiler to inline the function if the function is small
> enough. As the static indicates that the function will not be seen
>
The inline keyword is never an obligation to inline, it's only a
proposal. And the compiler in fact doesn't care about it. When using
an optimization mode, the compiler will inline the function if it is
simple enough. It's its call. It will even be easier to do so if the
static keyword is used, as
Matthieu Brucher wrote:
> In fact, the __inline is not helpful. It's the static keyword that
> enables the compiler to inline the function if the function is small
> enough. As the static indicates that the function will not be seen
> from the outside, it can do this.
>
Depends what is meant by
I ran into this problem as well a few months back.
The reason for the empty residual array when M==N is that the LAPACK
routine for Ax = b puts the solution for x in b. When M>N, the
norm-squared is parceled out into the unused (M-N) points in the b
array. When M==N, there's no room for the resids
In fact, the __inline is not helpful. It's the static keyword that
enables the compiler to inline the function if the function is small
enough. As the static indicates that the function will not be seen
from the outside, it can do this.
Matthieu
2009/2/24 David Cournapeau :
> On Wed, Feb 25, 2009
On Wed, Feb 25, 2009 at 2:21 AM, Charles R Harris
wrote:
>
> In order to inline, the function definition would need to be in the header
> and a library version would still be required for passing functions by
> address or in case the compiler decided *not* to inline.
I looked more into this while
On Tue, Feb 24, 2009 at 7:04 AM, Neal Becker wrote:
> Pauli Virtanen iki.fi> writes:
>
> ...
> > One question: doesn't this add one extra function call to all umath
> > functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
> > when the appropriate platform-specified functions are
Tue, 24 Feb 2009 14:04:42 +, Neal Becker wrote:
> Pauli Virtanen iki.fi> writes:
>
> ...
>> One question: doesn't this add one extra function call to all umath
>> functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
>> when the appropriate platform-specified functions are ava
Hi,
I'm trying to use the additional 'title' feature of dtypes when
creating arrays. The reason for using titles is that I want to store
meta data about the columns in them (so do-not-use-titles is not the
right solution for me...)
Everything works fine without titles:
>>> arr = array([('john',
Pauli Virtanen iki.fi> writes:
...
> One question: doesn't this add one extra function call to all umath
> functions? Could we do '#define npy_XXX XXX' in the npy_math.h header
> when the appropriate platform-specified functions are available?
There shouldn't be overhead on modern compilers fo
30 matches
Mail list logo
