Hi all,
This email is about the difference, given a recarray 'arr',
between
A)
arr.foo.x[0]
and B)
arr.foo[0].x
Specifically, form A returns the 0-th x value, whereas form B raises
AttributeError:
Some code demonstrating this:
>>> arr = np.zeros((4,), dtype = [('foo',[('x','H'),('y','H
On Tue, Feb 14, 2012 at 9:37 PM, Benjamin Root wrote:
> On Tuesday, February 14, 2012, Mark Wiebe wrote:
> > On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root wrote:
> >>
> >> Just a thought I had. Right now, I can pass a list of python ints or
> floats into np.array() and get a numpy array with
On 2012-02-14, at 10:14 PM, Bruce Southey wrote:
> I will miss you as a numpy release manager!
> You have not only done an incredible job but also taken the role to a
> higher level.
> Your attitude and attention to details has been amazing.
+1, hear hear! Thank you for all the time you've inves
On Tuesday, February 14, 2012, Mark Wiebe wrote:
> On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root wrote:
>>
>> Just a thought I had. Right now, I can pass a list of python ints or
floats into np.array() and get a numpy array with a sensible dtype. Is
there any reason why we can't do the same fo
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root wrote:
> Just a thought I had. Right now, I can pass a list of python ints or
> floats into np.array() and get a numpy array with a sensible dtype. Is
> there any reason why we can't do the same for python's datetime? Right
> now, it is very easy
On Tue, Feb 14, 2012 at 9:17 PM, Benjamin Root wrote:
> Just a thought I had. Right now, I can pass a list of python ints or
> floats into np.array() and get a numpy array with a sensible dtype. Is
> there any reason why we can't do the same for python's datetime? Right
> now, it is very easy
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett wrote:
> Hi,
>
> On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe wrote:
> > I took a look into the code to see what is causing this, and the reason
> is
> > that nothing has ever been implemented to deal with the fields. This
> means
> > it falls back to
Just a thought I had. Right now, I can pass a list of python ints or
floats into np.array() and get a numpy array with a sensible dtype. Is
there any reason why we can't do the same for python's datetime? Right
now, it is very easy for me to make a list comprehension of datetime
objects using st
Hi,
On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe wrote:
> I took a look into the code to see what is causing this, and the reason is
> that nothing has ever been implemented to deal with the fields. This means
> it falls back to treating all struct dtypes as if they were a plain "void"
> dtype, wh
On Tue, Feb 14, 2012 at 2:24 PM, Ralf Gommers
wrote:
>
>
> On Tue, Feb 14, 2012 at 7:25 PM, Travis Oliphant
> wrote:
>>
>>
>> On Feb 14, 2012, at 3:32 AM, David Cournapeau wrote:
>>
>> > Hi Travis,
>> >
>> > It is great that some resources can be spent to have people paid to
>> > work on NumPy. T
On Tue, Feb 14, 2012 at 6:43 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant wrote:
When we selected the name NumFOCUS just a few weeks ago, we created the
list
for numfocus and then I signed everyone up for that list who was on the
ot
On Tuesday, February 14, 2012, Travis Oliphant wrote:
>>
>> I have to agree with Mathew here, to a point. There has been
discussions of these groups before, but I don't recall any announcement of
this group. Of course, now that it has been announced, maybe a link to it
should be prominent on the
On 2/14/12 7:17 PM, Travis Oliphant wrote:
> * Fund Open Source Projects in Science (currently NumPy, SciPy,
> IPython, and Matplotlib are first-tier with a whole host of second-tier
> projects that could received funding)
> * through grants
So, for example, would the Foundat
>>
>> Your points are well taken. However, my point is that this has been
>> discussed on an open mailing list. Things weren't *as* open as they could
>> have been, perhaps, in terms of board selection. But, there was opportunity
>> for people to provide input.
>
> I am on the numpy, scip
Hi,
On Tue, Feb 14, 2012 at 4:43 PM, Matthew Brett wrote:
> Hi,
>
> On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant wrote:
When we selected the name NumFOCUS just a few weeks ago, we created the
list
for numfocus and then I signed everyone up for that list who was on the
>>
>
> I have to agree with Mathew here, to a point. There has been discussions of
> these groups before, but I don't recall any announcement of this group. Of
> course, now that it has been announced, maybe a link to it should be
> prominent on the numpy/scipy pages(maybe others?). It should a
Hi,
On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant wrote:
>>>
>>> When we selected the name NumFOCUS just a few weeks ago, we created the list
>>> for numfocus and then I signed everyone up for that list who was on the
>>> other one. I apologize if anyone felt left out. That is not my
>>
On Tuesday, February 14, 2012, Matthew Brett
wrote:
> Hi,
>
> On Tue, Feb 14, 2012 at 1:54 PM, Travis Oliphant
wrote:
>>
>> There is a mailing list for numfocus that you can sign up for if you
would
>> like to be part of those discussions. Let me know if you would like
more
>> information about
On Tue, 2012-02-14 at 15:12 -0800, Chris Barker wrote:
>
> On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
> wrote:
> > It was about the need for a dedicated matrix multiplication
> operator.
>
> has anyone proposed that? I do think we've had a proposal on the table
> for generally more op
>>
>> When we selected the name NumFOCUS just a few weeks ago, we created the list
>> for numfocus and then I signed everyone up for that list who was on the
>> other one. I apologize if anyone felt left out. That is not my
>> intention.
>
> My point is that there are two ways go to about
15.02.2012 00:23, Marcel Oliver kirjoitti:
[clip]
> Thanks for all the replies. Playing a bit with timeit, it is clear
> that it cannot just be the overhead of checking the type of the index
> array, as the overhead grows very roughly propertional to the size of
> the index array, but remains inde
On Tue, Feb 14, 2012 at 3:12 PM, Chris Barker wrote:
> On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
> wrote:
>> It was about the need for a dedicated matrix multiplication operator.
>
> has anyone proposed that? I do think we've had a proposal on the table
> for generally more operators:
On Tue, Feb 14, 2012 at 4:03 AM, Francesc Alted wrote:
> On Feb 14, 2012, at 1:50 AM, Wes McKinney wrote:
> [clip]
>> But:
>>
>> In [40]: timeit hist[i, j]
>> 1 loops, best of 3: 32 us per loop
>>
>> So that's roughly 7-8x slower than a simple Cython method, so I
>> sincerely hope it could be
On 02/14/2012 03:12 PM, Chris Barker wrote:
> On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
> wrote:
>> It was about the need for a dedicated matrix multiplication operator.
>
> has anyone proposed that? I do think we've had a proposal on the table
> for generally more operators: i.e. lik
Hi,
On Tue, Feb 14, 2012 at 1:54 PM, Travis Oliphant wrote:
>
> There is a mailing list for numfocus that you can sign up for if you would
> like to be part of those discussions. Let me know if you would like more
> information about that. John Hunter, Fernando Perez, me, Perry
> Greenfield,
Francesc Alted wrote:
> On Feb 14, 2012, at 1:50 AM, Wes McKinney wrote:
> [clip]
> > But:
> >
> > In [40]: timeit hist[i, j]
> > 1 loops, best of 3: 32 us per loop
> >
> > So that's roughly 7-8x slower than a simple Cython method, so I
> > sincerely hope it could be brought down to
On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
wrote:
> It was about the need for a dedicated matrix multiplication operator.
has anyone proposed that? I do think we've had a proposal on the table
for generally more operators: i.e. like matlab's ".*" vs "*", and yes,
matrix multiplication
>
> Travis, it's very good to see that the release manager role can be filled
> going forward (it's not the most popular job), but I think the way it should
> work is that people volunteer for this role and then the community agrees on
> giving a volunteer that role.
>
> I actually started co
>>
>> There is a mailing list for numfocus that you can sign up for if you would
>> like to be part of those discussions. Let me know if you would like more
>> information about that.John Hunter, Fernando Perez, me, Perry
>> Greenfield, and Jarrod Millman are the initial board of the Foun
On Tue, Feb 14, 2012 at 12:27 PM, Benjamin Root wrote:
>
>
> On Tuesday, February 14, 2012, Travis Oliphant
> wrote:
> >> > As you can see there were changes in each release. Most of these
> were minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing
> the changes from 1.5.1 to 1.
On Tue, 2012-02-14 at 14:14 -0600, Travis Oliphant wrote:
> > Is that a prompt for feedback? :)
>
> Absolutely. That's the reason I'm getting more active on this list.
> But, at the same time, we all need to be aware of the tens of
> thousands of users of NumPy who don't use the mailing list an
On Tuesday, February 14, 2012, Travis Oliphant wrote:
>> > As you can see there were changes in each release. Most of these
were minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing
the changes from 1.5.1 to 1.6.1.At first blush, it looks like there are
a lot of changes to swa
On Tue, Feb 14, 2012 at 7:25 PM, Travis Oliphant wrote:
>
> On Feb 14, 2012, at 3:32 AM, David Cournapeau wrote:
>
> > Hi Travis,
> >
> > It is great that some resources can be spent to have people paid to
> > work on NumPy. Thank you for making that happen.
> >
> > I am slightly confused about ro
>>
>> - The packaging quagmire? This continues to be a problem, though
>> python3 does have new improvements to distutils. I'm not really up to
>> speed on the situation, to be frank. If we want to bring this up,
>> someone will have to provide a solid reference or volunteer to do it
>> in pers
> > As you can see there were changes in each release. Most of these were
> > minor prior to the change from 1.5.1 to 1.6.1. I am still reviewing the
> > changes from 1.5.1 to 1.6.1.At first blush, it looks like there are a
> > lot of changes to swallow that are not necessarily minor.I
On Feb 14, 2012, at 7:04 AM, Henry Gomersall wrote:
> On Mon, 2012-02-13 at 22:56 -0600, Travis Oliphant wrote:
>> But, I am also aware of *a lot* of users who never voice their opinion
>> on this list, and a lot of features that they want and need and are
>> currently working around the limitat
On Tue, Feb 14, 2012 at 12:25 PM, Travis Oliphant wrote:
>
> There is a mailing list for numfocus that you can sign up for if you would
> like to be part of those discussions. Let me know if you would like more
> information about that.
I would like more information about (as would many oth
Hi,
On Tue, Feb 14, 2012 at 10:25 AM, Travis Oliphant wrote:
>
> On Feb 14, 2012, at 3:32 AM, David Cournapeau wrote:
>
>> Hi Travis,
>>
>> It is great that some resources can be spent to have people paid to
>> work on NumPy. Thank you for making that happen.
>>
>> I am slightly confused about ro
Hi,
You can subscribe here:
http://mail.scipy.org/mailman/listinfo/numpy-discussion
-=- Olivier
Le 14 février 2012 14:22, pulkit yadav a écrit :
> Hello,
>
> I am a Python enthusiast and developer. Please add me to numpy mailing
> list so that I can contribute to the FLOSS community.
>
> --
>
Hello,
I am a Python enthusiast and developer. Please add me to numpy mailing list
so that I can contribute to the FLOSS community.
--
Pulkit
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-disc
On Tue, Feb 14, 2012 at 1:03 AM, Travis Oliphant wrote:
>
>Mostly I'm happy with the changes (after a cursory review). As I
> expected, there are some real improvements.Of course, I haven't looked
> at the changes that occur when the scalar being used does not fit in the
> range of t
On Feb 14, 2012, at 3:32 AM, David Cournapeau wrote:
> Hi Travis,
>
> It is great that some resources can be spent to have people paid to
> work on NumPy. Thank you for making that happen.
>
> I am slightly confused about roadmaps for numpy 1.8 and 2.0. This
> needs discussion on the ML, and ou
On Tue, Feb 14, 2012 at 9:26 AM, David Cournapeau wrote:
> I will be at pydata, so I can try to get an elevator pitch ready for
> the packaging situation.
Awesome! I didn't realize you were coming, and you're obviously the
person I had in mind for this job :)
Cheers,
f
On Mon, Feb 13, 2012 at 9:55 PM, Fernando Perez wrote:
> Hi folks,
>
> [ I'm broadcasting this widely for maximum reach, but I'd appreciate
> it if replies can be kept to the *numpy* list, which is sort of the
> 'base' list for scientific/numerical work. It will make it much
> easier to organize
On 02/14/2012 08:59 AM, Chris Barker wrote:
> On Mon, Feb 13, 2012 at 6:19 PM, Mark Wiebe wrote:
>> It might be nice to turn the matrix class into a short class hierarchy,
>
> am I confused, or did a thread get mixed in? This seems to be a
> numpy/scipy thing, not a Python3 thing. Or is there some
On Mon, Feb 13, 2012 at 6:19 PM, Mark Wiebe wrote:
> It might be nice to turn the matrix class into a short class hierarchy,
am I confused, or did a thread get mixed in? This seems to be a
numpy/scipy thing, not a Python3 thing. Or is there some support in
Python itself required for this to be pr
On 02/14/2012 09:40 AM, Olivier Delalleau wrote:
Really not an expert here, but it looks like it's trying various
compilation options, some work and some don't, and for some reason
it's really unhappy about the one where it can't find Python.h.
Maybe add /usr/include/python2.6 to your CPATH, see
Really not an expert here, but it looks like it's trying various
compilation options, some work and some don't, and for some reason it's
really unhappy about the one where it can't find Python.h.
Maybe add /usr/include/python2.6 to your CPATH, see if that helps (and make
sure permissions are correc
On Tuesday, February 14, 2012, Travis Oliphant wrote:
> Here is the code I used to determine the coercion table of types. I
first used *all* of the numeric_ops, narrowed it down to those with 2
inputs and 1 output, and then determined the run-time coercion table.
Then, I removed ops that had the
On Tue, Feb 14, 2012 at 7:22 AM, Gordon L. Kindlmann wrote:
> Hello,
>
> This (below) caught my eye and I'm wondering what further information is
> available?
>
> I very much value the ability to wrap underlying array data from numpy for
> processing in non-python libraries, as well as the ability
On 02/14/2012 06:22 AM, Gordon L. Kindlmann wrote:
> Hello,
>
> This (below) caught my eye and I'm wondering what further information is
> available?
>
> I very much value the ability to wrap underlying array data from numpy for
> processing in non-python libraries, as well as the ability to wrap
Hello,
This (below) caught my eye and I'm wondering what further information is
available?
I very much value the ability to wrap underlying array data from numpy for
processing in non-python libraries, as well as the ability to wrap numpy arrays
around array data allocated by non-python librar
Hi folks,
[ I'm broadcasting this widely for maximum reach, but I'd appreciate
it if replies can be kept to the *numpy* list, which is sort of the
'base' list for scientific/numerical work. It will make it much
easier to organize a coherent set of notes later on. Apology if
you're subscribed to
On Feb 14, 2012, at 1:47 PM, Charles R Harris wrote:
> About the behavior in question, I would frame this as a specific case with
> argument for and against like so:
>
> The Current Behavior
>
> In [1]: array([127], int8) + 127
> Out[1]: array([-2], dtype=int8)
>
> In [2]: array([127], int8) +
On Mon, 2012-02-13 at 22:56 -0600, Travis Oliphant wrote:
> But, I am also aware of *a lot* of users who never voice their opinion
> on this list, and a lot of features that they want and need and are
> currently working around the limitations of NumPy to get.These are
> going to be my primary
On Tue, Feb 14, 2012 at 12:58 AM, Travis Oliphant wrote:
> >
> > The lack of commutativity wasn't in precision, it was in the typecodes,
> and was there from the beginning. That caused confusion. A current cause of
> confusion is the many to one relation of, say, int32 and long, longlong
> which v
On Tue, Feb 14, 2012 at 12:05 AM, Eric Firing wrote:
> On 02/13/2012 08:07 PM, Charles R Harris wrote:
>>
>
>>
>> Let it go, Travis. It's a waste of time.
>
> (Off-list) Chuck, I really appreciate your consistent good sense; this
> is just one of many examples. Thank you for all your numpy work.
On Mon, Feb 13, 2012 at 23:23, Marcel Oliver
wrote:
> Hi,
>
> I have a short piece of code where the use of an index array "feels
> right", but incurs a severe performance penalty: It's about an order
> of magnitude slower than all other operations with arrays of that
> size.
>
> It comes up in a
On 14/02/2012 10:30, Pauli Virtanen wrote:
> 14.02.2012 10:20, Mads Ipsen kirjoitti:
> [clip]
>> * Should import_array() only be called one time, namely when the main
>> application is started?
> It should be called once when the application is started, before you do
> any other Numpy-using operati
On Tue, Feb 14, 2012 at 09:30, Pauli Virtanen wrote:
> 14.02.2012 10:20, Mads Ipsen kirjoitti:
> [clip]
>> * Should import_array() only be called one time, namely when the main
>> application is started?
>
> It should be called once when the application is started, before you do
> any other Numpy-
Hi Travis,
It is great that some resources can be spent to have people paid to
work on NumPy. Thank you for making that happen.
I am slightly confused about roadmaps for numpy 1.8 and 2.0. This
needs discussion on the ML, and our release manager currently is Ralf
- he is the one who ultimately de
14.02.2012 10:20, Mads Ipsen kirjoitti:
[clip]
> * Should import_array() only be called one time, namely when the main
> application is started?
It should be called once when the application is started, before you do
any other Numpy-using operations.
http://docs.scipy.org/doc/numpy/reference/c-ap
Hi,
The C++ module here is a class that's used by an OpenGL window, to
extract data from numpy arrays and basically draw molecules whose
coordinates are stored in numpy arrays.
The C++ module is accessed from Python using wrappers generated by swig.
Our application may contain many active Op
Technically, when you write an extension module you really should use
import_array(); in the init method of the extensions module. This ensures
that the C-API is loaded so that the API -table is available if your C++ code
uses the C-API at all.
In this case you are just using some #defines t
On Feb 14, 2012, at 1:50 AM, Wes McKinney wrote:
[clip]
> But:
>
> In [40]: timeit hist[i, j]
> 1 loops, best of 3: 32 us per loop
>
> So that's roughly 7-8x slower than a simple Cython method, so I
> sincerely hope it could be brought down to the sub 10 microsecond
> level with a little bit
For reference, here is the table that shows the actual changes between 1.5.1
and 1.6.1 at least on 64-bit platforms in terms of type-casting. I updated the
comparison code to throw out changes that are just "spelling differences" (i.e.
where 1.6.1 chooses to create an output dtype with an 'L' c
Hi,
I have C++ module (OpenGL) that extracts data from numpy arrays. The
interface is pure read-only: It never returns any Python objects but
only extracts data from numpy arrays. Eg:
#include "numpy/arrayobject.h"
void PrimitiveManager::deleteAtoms(PyObject * numpy_indices)
{
// Extract
Jeroen's reply about the Sage "buildbot" is below:
>Jeroen, do we have an
> automatic buildbot system for Sage?
Depends on what you mean with "automatic". We have the buildbot setup
at http://build.sagemath.org/sage/waterfall which builds automatically
but I still have to change versions by ha
Hi Travis,
On Mon, Feb 13, 2012 at 11:46 PM, Travis Oliphant wrote:
> Here is the code I used to determine the coercion table of types. I first
> used *all* of the numeric_ops, narrowed it down to those with 2 inputs and 1
> output, and then determined the run-time coercion table. Then, I r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I am trying to compile numpy 1.6.1 from source on a Redhat Linux
enterprise 6 machine, and I get a problem with Python.h : somehow it
can't be located by numpy's install script:
SystemError: Cannot compile 'Python.h'. Perhaps you need to insta
On 02/13/2012 08:07 PM, Charles R Harris wrote:
>
>
> Let it go, Travis. It's a waste of time.
(Off-list) Chuck, I really appreciate your consistent good sense; this
is just one of many examples. Thank you for all your numpy work.
Eric
___
NumPy-Disc
71 matches
Mail list logo
