On Tue, Feb 11, 2014 at 8:57 AM, Christopher Jordan-Squire
wrote:
> Thanks for the answers! My responses are inline.
my C is a bit weak, so forgive my misunderstanding, but:
>> {
>> char* ind;
>> double val, wght;
>> } data[] = { {"camera", 15, 2}, {"necklace", 100, 20}, {"vase", 90, 20},
>>
Thanks for the answers! My responses are inline.
On Tue, Feb 11, 2014 at 8:36 AM, Chris Barker wrote:
> On Mon, Feb 10, 2014 at 10:43 PM, Christopher Jordan-Squire
> wrote:
>>
>> I'm trying to wrap some C code using cython. The C code can take
>> inputs in two modes: dense inputs and sparse inpu
On Mon, Feb 10, 2014 at 10:43 PM, Christopher Jordan-Squire wrote:
> I'm trying to wrap some C code using cython. The C code can take
> inputs in two modes: dense inputs and sparse inputs. For dense inputs
> the array indexing is naive. I have wrappers for that. In the sparse
> case the matrix en
I'm trying to wrap some C code using cython. The C code can take
inputs in two modes: dense inputs and sparse inputs. For dense inputs
the array indexing is naive. I have wrappers for that. In the sparse
case the matrix entries are typically indexed via names. So, for
example, the library documenta
>
>
> --
>
> Message: 6
> Date: Thu, 3 May 2012 10:00:11 -0700
> From: Keith Goodman
> Subject: Re: [Numpy-discussion] record arrays initialization
> To: Discussion of Numerical Python
> Message-ID:
>
> Content-Type: te
On Wed, May 2, 2012 at 4:46 PM, Kevin Jacobs
wrote:
> The cKDTree implementation is more than 4 times faster than the brute-force
> approach:
>
> T = scipy.spatial.cKDTree(targets)
>
> In [11]: %timeit foo1(element, targets) # Brute force
> 1000 loops, best of 3: 385 us per loop
>
> In [12]: %
Sounds like it could be a good match for `scipy.spatial.cKDTree`.
It can handle single-element queries...
>>> element = numpy.arange(1, 8)
>>> targets = numpy.random.uniform(0, 8, (1000, 7))
>>> tree = scipy.spatial.cKDTree(targets)
>>> distance, index = tree.query(element)
>>> targets[index]
arr
On Wed, May 2, 2012 at 6:46 PM, Kevin Jacobs
wrote:
> On Wed, May 2, 2012 at 7:25 PM, Aronne Merrelli
> wrote:
>>
>> In general this is a good suggestion - I was going to mention it
>> earlier - but I think for this particular problem it is not better
>> than the "brute force" and argmin() NumPy
On Wednesday, May 2, 2012, Stéfan van der Walt wrote:
> On Wed, May 2, 2012 at 4:46 PM, Kevin Jacobs
>
> >
> > wrote:
> > A FLANN implementation should be even faster--perhaps by as much as
> another
> > factor of two.
>
> I guess it depends on whether you care about the "Approximate" in
> "Fast
On Wed, May 2, 2012 at 4:46 PM, Kevin Jacobs
wrote:
> A FLANN implementation should be even faster--perhaps by as much as another
> factor of two.
I guess it depends on whether you care about the "Approximate" in
"Fast Library for Approximate Nearest Neighbors".
Stéfan
_
On Wed, May 2, 2012 at 4:26 PM, Moroney, Catherine M (388D)
wrote:
> Using structured arrays is making my code complex when I try to call the
> vectorized function. If I stick to the original record arrays, what's the
> best way of initializing b from a without doing an row-by-row copy?
What doe
On Wed, May 2, 2012 at 7:25 PM, Aronne Merrelli
wrote:
> In general this is a good suggestion - I was going to mention it
> earlier - but I think for this particular problem it is not better
> than the "brute force" and argmin() NumPy approach. On my laptop, the
> KDTree query is about a factor of
On May 2, 2012, at 3:23 PM,
wrote:
>> A) ?How do I most efficiently construct a record array from a single array?
>> I want to do the following, but it segfaults on me when i try to print b.
>>
>> vtype = [("x", numpy.ndarray)]
>> a = numpy.arange(0, 16).reshape(4,4)
>> b = numpy.recarray((4)
On Wed, May 2, 2012 at 5:27 PM, Kevin Jacobs
wrote:
> On Wed, May 2, 2012 at 5:45 PM, Moroney, Catherine M (388D)
> wrote:
>>
>> Thanks to Perry for some very useful off-list conversation. I realize
>> that
>> I wasn't being clear at all in my earlier description of the problem so
>> here it i
On Wed, May 2, 2012 at 5:45 PM, Moroney, Catherine M (388D) <
catherine.m.moro...@jpl.nasa.gov> wrote:
> Thanks to Perry for some very useful off-list conversation. I realize
> that
> I wasn't being clear at all in my earlier description of the problem so
> here it is
> in a nutshell:
>
> Find t
On Wed, May 2, 2012 at 2:45 PM, Moroney, Catherine M (388D)
wrote:
> Find the best match in an array t(5000, 7) for a single vector e(7). Now
> scale
> it up so e is (128, 512, 7) and I want to return a (128, 512) array of the
> t-identifiers
> that are the best match for e. "Best match" is de
On Wed, May 2, 2012 at 1:06 PM, Moroney, Catherine M (388D)
wrote:
> Hello,
>
> Can somebody give me some hints as to how to code up this function
> in pure python, rather than dropping down to Fortran?
>
> I will want to compare a 7-element vector (called "element") to a large list
> of similarl
Thanks to Perry for some very useful off-list conversation. I realize that
I wasn't being clear at all in my earlier description of the problem so here it
is
in a nutshell:
Find the best match in an array t(5000, 7) for a single vector e(7). Now scale
it up so e is (128, 512, 7) and I want to
On Wed, May 2, 2012 at 11:06 AM, Moroney, Catherine M (388D)
wrote:
> I will want to compare a 7-element vector (called "element") to a large list
> of similarly-dimensioned
> vectors (called "target", and pick out the vector in "target" that is the
> closest to "element"
> (determined by minimi
Hello,
Can somebody give me some hints as to how to code up this function
in pure python, rather than dropping down to Fortran?
I will want to compare a 7-element vector (called "element") to a large list of
similarly-dimensioned
vectors (called "target", and pick out the vector in "target" that
On Wed, Jul 15, 2009 at 14:38, Pauli Virtanen wrote:
> On 2009-07-15, Robert Kern wrote:
>> On Wed, Jul 15, 2009 at 14:19, Vebjorn Ljosa wrote:
>>> Suppose I have a record array where one of the fields is a nested array:
>>>
>>> >>> from numpy import *
>>> >>> desc = dtype([('point', 'i4', 3), (
On 2009-07-15, Robert Kern wrote:
> On Wed, Jul 15, 2009 at 14:19, Vebjorn Ljosa wrote:
>> Suppose I have a record array where one of the fields is a nested array:
>>
>> >>> from numpy import *
>> >>> desc = dtype([('point', 'i4', 3), ('unimportant', 'S3')])
>> >>> a = array([((1,2,3), 'foo'),
On Jul 15, 2009, at 15:28, Robert Kern wrote:
>
> Generally, scalars are never views. a[0] pulls out a record scalar.
Thank you, that explains it. I should have noticed that a[0] was just
a tuple.
Vebjorn
___
NumPy-Discussion mailing list
NumPy-Discu
On Wed, Jul 15, 2009 at 14:19, Vebjorn Ljosa wrote:
> Suppose I have a record array where one of the fields is a nested array:
>
> >>> from numpy import *
> >>> desc = dtype([('point', 'i4', 3), ('unimportant', 'S3')])
> >>> a = array([((1,2,3), 'foo'), ((7,8,9), 'bar')], dtype=desc)
> >>> a
>
Suppose I have a record array where one of the fields is a nested array:
>>> from numpy import *
>>> desc = dtype([('point', 'i4', 3), ('unimportant', 'S3')])
>>> a = array([((1,2,3), 'foo'), ((7,8,9), 'bar')], dtype=desc)
>>> a
array([([1, 2, 3], 'foo'), ([7, 8, 9], 'bar')],
dtype=[('po
2008/6/27 Fernando Perez <[EMAIL PROTECTED]>:
> On Thu, Jun 26, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> One downside of this is that the attribute access feature slows down
>> all field accesses, even the r['foo'] form, because it sticks a bunch
>> of pure Python code in the mi
Perry Greenfield wrote:
> Hi Chris,
>
> Didn't we remove all dependence on recarray? I could have sworn we
> did that.
>
> Perry
>
Perry,
You are right. We no longer import the recarray module from numpy.
Chris
--
Christopher Hanley
Systems Software Engineer
Space Telescope Science Ins
Hi Chris,
Didn't we remove all dependence on recarray? I could have sworn we
did that.
Perry
On Jun 26, 2008, at 12:45 PM, Christopher Hanley wrote:
> Travis E. Oliphant wrote:
>> Stéfan van der Walt wrote:
>>> Hi all,
>>>
>>> I am documenting `recarray`, and have a question:
>>>
>>> Is its u
On Fri, Jun 27, 2008 at 7:10 AM, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 26, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
>> One downside of this is that the attribute access feature slows down
>> all field accesses, even the r['foo'] form, because it sticks a bunch
>>
On Thu, Jun 26, 2008 at 1:25 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> One downside of this is that the attribute access feature slows down
> all field accesses, even the r['foo'] form, because it sticks a bunch
> of pure Python code in the middle. Much code won't notice this, but if
> you end
On Thu, Jun 26, 2008 at 09:36:38PM -0500, Robert Kern wrote:
> On Thu, Jun 26, 2008 at 21:24, Gael Varoquaux
> <[EMAIL PROTECTED]> wrote:
> > I understand all your comments and thank you for making this distinction
> > explicit. I can see why recarray can slow code down, but I find attribute
> > lo
On Thu, Jun 26, 2008 at 21:24, Gael Varoquaux
<[EMAIL PROTECTED]> wrote:
> I understand all your comments and thank you for making this distinction
> explicit. I can see why recarray can slow code down, but I find attribute
> lookup make code much more readable, and interactive work fantastic (tab
I understand all your comments and thank you for making this distinction
explicit. I can see why recarray can slow code down, but I find attribute
lookup make code much more readable, and interactive work fantastic (tab
completion). For many of my applications I do have a strong use case for
these
> Does that clarify the discussion for you?
>
>
>
>
> Yes, thanks very much, this is very helpful. (I think I was confused
> by the fact that, AFAICT, the Guide to Numpy only mentions recarray --
> as distinct from Record arrays -- in one somewhat cryptic line.) But
> I guess that the nu
>
> In [12]: r2.foo
> Out[12]: array([1, 1, 1])
>
>
> One downside of this is that the attribute access feature slows down
> all field accesses, even the r['foo'] form, because it sticks a bunch
> of pure Python code in the middle. Much code won't notice this, but if
> you end up having to iterate
> Let's be clear, there are two very closely related things: recarrays
> and record arrays. Record arrays are just ndarrays with a complicated
> dtype. E.g.
>
> In [1]: from numpy import *
>
> In [2]: ones(3, dtype=dtype([('foo', int), ('bar', float)]))
> Out[2]:
> array([(1, 1.0), (1, 1.0), (1,
On Thu, Jun 26, 2008 at 15:13, Dan Yamins <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 26, 2008 at 3:34 PM, Gael Varoquaux
> <[EMAIL PROTECTED]> wrote:
>>
>> On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
>> > I personally think they are the best thing since sliced bread, and
>> > every
On Thu, Jun 26, 2008 at 3:34 PM, Gael Varoquaux <
[EMAIL PROTECTED]> wrote:
> On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
> > I personally think they are the best thing since sliced bread, and
> > everyone here who uses them becomes immediately addicted to them. I
> > would like
On Thu, Jun 26, 2008 at 11:48:06AM -0500, John Hunter wrote:
> I personally think they are the best thing since sliced bread, and
> everyone here who uses them becomes immediately addicted to them. I
> would like to see better support for them, especially making the attrs
> exposed to dir so tab c
Would someone kindly provide links to references for the fancy data types
superseding the recarrays? Having come from an R-Project background,
manipulating the latter takes time to become acclimated to when building
data.frame like objects.
TIA,
--
Vince Fulco
__
On Thu, Jun 26, 2008 at 11:38 AM, Travis E. Oliphant
<[EMAIL PROTECTED]> wrote:
> Stéfan van der Walt wrote:
>> Hi all,
>>
>> I am documenting `recarray`, and have a question:
>>
>> Is its use still recommended, or has it been superseded by fancy data-types?
>>
> I rarely recommend it's use (but so
Travis E. Oliphant wrote:
> Stéfan van der Walt wrote:
>> Hi all,
>>
>> I am documenting `recarray`, and have a question:
>>
>> Is its use still recommended, or has it been superseded by fancy data-types?
>>
> I rarely recommend it's use (but some people do like attribute access to
> the fields
Stéfan van der Walt wrote:
> Hi all,
>
> I am documenting `recarray`, and have a question:
>
> Is its use still recommended, or has it been superseded by fancy data-types?
>
I rarely recommend it's use (but some people do like attribute access to
the fields).It is wrong, however, to say tha
Stéfan van der Walt wrote:
> Hi all,
>
> I am documenting `recarray`, and have a question:
>
> Is its use still recommended, or has it been superseded by fancy data-types?
>
> Regards
> Stéfan
> ___
> Numpy-discussion mailing list
> Numpy-discussion@sc
Hi all,
I am documenting `recarray`, and have a question:
Is its use still recommended, or has it been superseded by fancy data-types?
Regards
Stéfan
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinf
On Tue, Mar 18, 2008 at 2:18 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 18, 2008 at 9:48 AM, <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > How do I handle numpy record arrays (heterogenous dtype) with ctypes?
> > The python side is reasonably obvious to me, but I'm confused
On Tue, Mar 18, 2008 at 9:48 AM, <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> How do I handle numpy record arrays (heterogenous dtype) with ctypes?
> The python side is reasonably obvious to me, but I'm confused about
> how to declare my C function's signature; whether I need to include
> the nump
Hi all,
How do I handle numpy record arrays (heterogenous dtype) with ctypes?
The python side is reasonably obvious to me, but I'm confused about
how to declare my C function's signature; whether I need to include
the numpy array interface header file or not... etc...
It's not obvious to me how a
48 matches
Mail list logo
