On Mon, Mar 7, 2011 at 4:22 PM, Dan Halbert wrote:
> On 3/7/2011 6:48 PM, Christopher Barker wrote:
>> On 3/7/11 3:36 PM, Dan Halbert wrote:
>>> We currently have some straightforward NumPy code that indirectly
>>> implements a C API defined by a third party. We built a Cython layer that
>>> dir
On 3/7/2011 9:25 PM, Nathaniel Smith wrote:
> On Mon, Mar 7, 2011 at 3:36 PM, Dan Halbert wrote:
>> Or is there some higher-level compiled array language that looks something
>> like NumPy code?
>
> You might want to try Eigen:
>http://eigen.tuxfamily.org/
Thanks - didn't know about this. I'
On 3/7/2011 9:13 PM, Sturla Molden wrote:
> Den 08.03.2011 00:36, skrev Dan Halbert:
>> Do you all have some recommendations about tools, libraries, or languages
>> that you have used to rewrite NumPy code easily into something that's more
>> self-contained and callable from C?
>
> Fortran 95
>
>
On Mon, Mar 7, 2011 at 3:36 PM, Dan Halbert wrote:
> Or is there some higher-level compiled array language that looks something
> like NumPy code?
You might want to try Eigen:
http://eigen.tuxfamily.org/
-- Nathaniel
___
NumPy-Discussion mailing lis
Den 08.03.2011 00:36, skrev Dan Halbert:
> Do you all have some recommendations about tools, libraries, or languages
> that you have used to rewrite NumPy code easily into something that's more
> self-contained and callable from C?
Fortran 95
It has the power of C, without the unsafe pointer ar
Thanks very much. It works.
On Mon, Mar 7, 2011 at 11:53 AM, wrote:
> for your problem, you can do:
>
>
>
> import numpy as np
>
> weights = np.array([1,2])
>
> matrix1 = np.ones((2,3))
> matrix2 = 2*np.ones((2,3))
>
> matrices = np.array([matrix1,matrix2])
>
> weigh
Den 07.03.2011 18:28, skrev Christopher Barker:
> 1, 2, 3, 4
> 5, 6
> 7, 8, 9, 10, 11, 12
> 13, 14, 15
> ...
>
> In my case, these will only be 2-d, though I suppose one could have a
> n-d version where the last dimension was ragged (or any dimension, I
> suppose, though I'm having trouble wrapping
On 3/7/2011 6:48 PM, Christopher Barker wrote:
> On 3/7/11 3:36 PM, Dan Halbert wrote:
>> We currently have some straightforward NumPy code that indirectly implements
>> a C API defined by a third party. We built a Cython layer that directly
>> provides the API in a .a library, and then calls Pyt
On 3/7/11 3:36 PM, Dan Halbert wrote:
> We currently have some straightforward NumPy code that indirectly implements
> a C API defined by a third party. We built a Cython layer that directly
> provides the API in a .a library, and then calls Python. The layering looks
> like this:
>
>C main
We currently have some straightforward NumPy code that indirectly implements a
C API defined by a third party. We built a Cython layer that directly provides
the API in a .a library, and then calls Python. The layering looks like this:
C main program -> API in Cython -> Python -> NumPy
This i
On 7 March 2011 15:29, Christopher Barker wrote:
> On 3/7/11 11:18 AM, Francesc Alted wrote:
>
>> but, instead of returning a numpy array of 'object' elements, plain
>> python lists are returned instead.
>
> which gives you the append option -- I can see how that would be
> usefull. Though I'd kin
On 3/7/11 11:18 AM, Francesc Alted wrote:
> Well, I don't think there is such a 'standard' way for dealing with
> ragged arrays, but yes, pytables has support for them. Creating them is
> easy:
>
> # Create a VLArray:
> fileh = tables.openFile('vlarray1.h5', mode='w')
> vlarray = fileh.createVLAr
A Monday 07 March 2011 19:42:00 Christopher Barker escrigué:
> But now that you've entered the conversation, does HDF and/or
> pytables have a standard way of dealing with this?
Well, I don't think there is such a 'standard' way for dealing with
ragged arrays, but yes, pytables has support for th
On 3/7/11 11:42 AM, Christopher Barker wrote:
> On 3/7/11 9:33 AM, Francesc Alted wrote:
>> A Monday 07 March 2011 18:28:11 Christopher Barker escrigué:
>>> I'm setting out to write some code to access and work with ragged
>>> arrays stored in netcdf files. It dawned on me that ragged arrays
>>> ar
On 3/7/11 9:33 AM, Francesc Alted wrote:
> A Monday 07 March 2011 18:28:11 Christopher Barker escrigué:
>> I'm setting out to write some code to access and work with ragged
>> arrays stored in netcdf files. It dawned on me that ragged arrays
>> are not all that uncommon, so I'm wondering if any of
Hi
I know Numeric 24.2 is really old and probably unsupported by now, but I
thought it might be of interest that Service Pack 1 for Windows 7 has
"broken" Numeric 24.2.
We have an old software product that uses Python 2.3 and Numeric 24.2,
"frozen" using py2exe, and we started receiving report
for your problem, you can do:
import numpy as np
weights = np.array([1,2])
matrix1 = np.ones((2,3))
matrix2 = 2*np.ones((2,3))
matrices = np.array([matrix1,matrix2])
weighted_sum = np.tensordot(weights, matrices, (0,0))
--
On Mon, Mar 07
On Mon, Mar 7, 2011 at 9:23 AM, Robert Kern wrote:
> On Mon, Mar 7, 2011 at 11:08, Christopher Barker
> wrote:
> > On 3/6/11 5:54 AM, Charles R Harris wrote:
> >> I suppose this might cause a problem with lazy/quick c extensions that
> >> expected elements in a certain order, so some breakage co
@Jeff
I need to work with ragged arrays too. Are object arrays of 1d numpy arrays
slower than lists of 1d numpy arrays?
@ Christopher
I'd be interested in hearing if you come up with any better solutions.
On Mon, Mar 7, 2011 at 9:37 AM, Jeff Whitaker wrote:
> On 3/7/11 10:28 AM, Christopher Bar
On 3/7/11 10:28 AM, Christopher Barker wrote:
> Hi folks,
>
> I'm setting out to write some code to access and work with ragged arrays
> stored in netcdf files. It dawned on me that ragged arrays are not all
> that uncommon, so I'm wondering if any of you have any code you've
> developed that I cou
Mon, 07 Mar 2011 11:23:33 -0600, Robert Kern wrote:
[clip]
> Can someone explain exactly what changed? Or point to the changeset that
> made it? It's not clear to me what operations are different under Mark's
> changes.
Mark mentioned three points here:
http://permalink.gmane.org/gmane.comp.python
A Monday 07 March 2011 18:28:11 Christopher Barker escrigué:
> Hi folks,
>
> I'm setting out to write some code to access and work with ragged
> arrays stored in netcdf files. It dawned on me that ragged arrays
> are not all that uncommon, so I'm wondering if any of you have any
> code you've deve
A Monday 07 March 2011 15:39:38 Pauli Virtanen escrigué:
> Mon, 07 Mar 2011 15:23:10 +0100, Francesc Alted wrote:
> [clip]
>
> > ValueError: numpy.dtype has the wrong size, try recompiling
> >
> > I don't think I'm wrong here, but I'd appreciate if somebody else
> > can reproduce this (either wit
Hi folks,
I'm setting out to write some code to access and work with ragged arrays
stored in netcdf files. It dawned on me that ragged arrays are not all
that uncommon, so I'm wondering if any of you have any code you've
developed that I could learn-from borrow from, etc.
note that when I say
On Mon, Mar 7, 2011 at 11:08, Christopher Barker wrote:
> On 3/6/11 5:54 AM, Charles R Harris wrote:
>> I suppose this might cause a problem with lazy/quick c extensions that
>> expected elements in a certain order, so some breakage could occur.
>
> absolutely!
>
> (I've gotten a bit confused abou
On 3/6/11 5:54 AM, Charles R Harris wrote:
> I suppose this might cause a problem with lazy/quick c extensions that
> expected elements in a certain order, so some breakage could occur.
absolutely!
(I've gotten a bit confused about this thread, but if this is about the
question of whether struct
Hi,
On Mon, Mar 7, 2011 at 5:01 PM, Neal Becker wrote:
> reshape can view a 1d array as non-overlapping segments.
>
> Is there a convenient way to view a 1d array as a 2d array of overlapping
> segments?
>
> nonoverlapping:
> l: segment length
> k: overlap
> u is the 1d array
> v is a 2d array
>
On 03/07/2011 04:15 PM, Dag Sverre Seljebotn wrote:
> On 03/07/2011 03:55 PM, John Cartwright wrote:
>> Thanks for your reply Ralf. I'm not sure if it's a warning or error, output
>> looks like:
>>
>> ...
>> building library "npymath" sources
>> customize GnuFCompiler
>> Found executable /usr/bin
On 03/07/2011 03:55 PM, John Cartwright wrote:
> Thanks for your reply Ralf. I'm not sure if it's a warning or error, output
> looks like:
>
> ...
> building library "npymath" sources
> customize GnuFCompiler
> Found executable /usr/bin/g77
> gnu: no Fortran 90 compiler found
> gnu: no Fortran 90
Here is some *working* code i wrote once. It uses strides, look at the
docs for what it is.
from numpy.lib import stride_tricks
def overlap_array( y, len_blocks, overlap=0 ):
"""
Make use of strides to return a two dimensional whose
rows come from a one dimensional array. Strides
Mon, 07 Mar 2011 10:01:21 -0500, Neal Becker wrote:
> reshape can view a 1d array as non-overlapping segments.
>
> Is there a convenient way to view a 1d array as a 2d array of
> overlapping segments?
>
> nonoverlapping:
> l: segment length
> k: overlap
> u is the 1d array
> v is a 2d array
>
>
On Mon, Mar 7, 2011 at 8:37 AM, Pauli Virtanen wrote:
> Mon, 07 Mar 2011 08:30:11 -0500, josef.pktd wrote:
> [clip]
>> assert_approx_equal checks for signigicant digits in decimal system,
>> which looks like it's easy to interpret.
>
> Ditto for tolerance=1e-7, which has the advantage that it's w
reshape can view a 1d array as non-overlapping segments.
Is there a convenient way to view a 1d array as a 2d array of overlapping
segments?
nonoverlapping:
l: segment length
k: overlap
u is the 1d array
v is a 2d array
v[i] = u[l*i:(l+1)*i]
overlapping:
v[i] = u[l*i:(l+1)*i+k]
__
Thanks for your reply Ralf. I'm not sure if it's a warning or error, output
looks like:
...
building library "npymath" sources
customize GnuFCompiler
Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found
gnu: no Fortran 90 compiler found
customize GnuFCompiler
gnu: no Fortran 90 compil
Mon, 07 Mar 2011 15:23:10 +0100, Francesc Alted wrote:
[clip]
> ValueError: numpy.dtype has the wrong size, try recompiling
>
> I don't think I'm wrong here, but I'd appreciate if somebody else can
> reproduce this (either with tables or with another Cython-dependent
> package).
Ok, seems this ne
A Monday 07 March 2011 15:17:17 Pauli Virtanen escrigué:
> Mon, 07 Mar 2011 14:57:39 +0100, Francesc Alted wrote:
> [clip]
>
> > > However, the size of PyArray_Descr does not seem to have changed
> > > between 1.5.1 and the Git master. So I'm not sure why you see
> > > this error...
> >
> > Maybe
Mon, 07 Mar 2011 14:57:39 +0100, Francesc Alted wrote:
[clip]
> > However, the size of PyArray_Descr does not seem to have changed
> > between 1.5.1 and the Git master. So I'm not sure why you see this
> > error...
>
> Maybe a Cython problem?
That would be seriously weird. Maybe the binaries you
On Mon, Mar 7, 2011 at 5:53 PM, Gökhan Sever wrote:
> Hello,
>
> I am going to the PyCon this week. I am presenting a poster about an
> atmospheric sciences related project -- the most active development
> from my coding site over at http://code.google.com/p/ccnworks/
>
> Is there anybody in the c
A Monday 07 March 2011 14:49:26 Pauli Virtanen escrigué:
> Mon, 07 Mar 2011 13:17:55 +0100, Francesc Alted wrote:
> [clip]
>
> > from tables.utilsExtension import getPyTablesVersion,
> > getHDF5Version
> >
> > File "definitions.pxd", line 138, in init tables.utilsExtension
> >
> > (t
Mon, 07 Mar 2011 13:17:55 +0100, Francesc Alted wrote:
[clip]
> from tables.utilsExtension import getPyTablesVersion, getHDF5Version
> File "definitions.pxd", line 138, in init tables.utilsExtension
> (tables/utilsExtension.c:9238)
> ValueError: numpy.dtype has the wrong size, try recompiling
On Mon, Mar 7, 2011 at 5:17 AM, Francesc Alted wrote:
> A Monday 28 February 2011 16:31:59 Ralf Gommers escrigué:
> > >> Proposed schedule:
> > >> March 15: beta 1
> > >> March 28: rc 1
> > >> April 17: rc 2 (if needed)
> > >> April 24: final release
> > >>
> > >> Let me know what you think. Bonu
Mon, 07 Mar 2011 08:30:11 -0500, josef.pktd wrote:
[clip]
> assert_approx_equal checks for signigicant digits in decimal system,
> which looks like it's easy to interpret.
Ditto for tolerance=1e-7, which has the advantage that it's what
"print abs(desired-actual)" prints.
> I don't have much ide
On Mon, Mar 7, 2011 at 6:53 AM, Pauli Virtanen wrote:
> Mon, 07 Mar 2011 06:39:20 -0500, josef.pktd wrote:
> [clip]
>> Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5,
>> atol=1.e-8 ?
>
> Probably no reason, it should be fixed.
>
>> What's the status on np.testing.assert_app
A Sunday 06 March 2011 06:47:34 Mark Wiebe escrigué:
> I think it's ok to revert this behavior for backwards compatibility,
> but believe it's an inconsistent and unintuitive choice. In
> broadcasting, there are two operations, growing a dimension 1 -> n,
> and appending a new 1 dimension to the le
Hello all,
I am new to python and numpy.
My question is how to sum up N weighted matrices.
For example w=[1,2] (N=2 case)
m1=[1 2 3,
3 4 5]
m2=[3 4 5,
4 5 6]
I want to get a matrix Y=w[1]*m1+w[2]*m2 by using a loop.
My original problem is like this
X=[1 2 3,
3 4 5,
4 5 6]
A Monday 28 February 2011 16:31:59 Ralf Gommers escrigué:
> >> Proposed schedule:
> >> March 15: beta 1
> >> March 28: rc 1
> >> April 17: rc 2 (if needed)
> >> April 24: final release
> >>
> >> Let me know what you think. Bonus points for volunteering to fix
> >> some of those tickets:)
While do
Mon, 07 Mar 2011 06:39:20 -0500, josef.pktd wrote:
[clip]
> Why does assert_allclose have atol=0, while np.allclose has rtol=1.e-5,
> atol=1.e-8 ?
Probably no reason, it should be fixed.
> What's the status on np.testing.assert_approx_equal, I would have liked
> to use it more often, except it do
Hi Gökhan,
I will present a poster about astronomical data reduction and
visualization on Sunday. I will arrive to Atlanta on Wednesday
morning to attend a couple of tutorials before the conference and look
forward to participating in sprints or other activities.
Regards,
Miguel
On Mon, Mar 07,
On Mon, Mar 7, 2011 at 4:10 AM, Pauli Virtanen wrote:
> Mon, 07 Mar 2011 11:03:17 +0800, Ralf Gommers wrote:
> [clip]
>> If anyone has new deprecations they want to put in for 1.6, discussing
>> them now would be good. I found one item in Trac, #1543. The proposal in
>> the ticket is to deprecate
Mon, 07 Mar 2011 11:03:17 +0800, Ralf Gommers wrote:
[clip]
> If anyone has new deprecations they want to put in for 1.6, discussing
> them now would be good. I found one item in Trac, #1543. The proposal in
> the ticket is to deprecate assert_almost_equal because it is quite badly
> behaved. This
Hello,
I am going to the PyCon this week. I am presenting a poster about an
atmospheric sciences related project -- the most active development
from my coding site over at http://code.google.com/p/ccnworks/
Is there anybody in the community participating there as well? Any
plans for sprinting or
51 matches
Mail list logo
