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
___
-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
Hi Travis,
On Mon, Feb 13, 2012 at 11:46 PM, Travis Oliphant tra...@continuum.io 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
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 hand
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
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'
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 of
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
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
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.
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
On Tue, Feb 14, 2012 at 09:30, Pauli Virtanen p...@iki.fi 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
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 operations.
On Mon, Feb 13, 2012 at 23:23, Marcel Oliver
m.oli...@jacobs-university.de 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.
On Tue, Feb 14, 2012 at 12:05 AM, Eric Firing efir...@hawaii.edu 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
On Tue, Feb 14, 2012 at 12:58 AM, Travis Oliphant tra...@continuum.iowrote:
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,
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 Feb 14, 2012, at 1:47 PM, Charles R Harris wrote:
clip
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) + 128
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
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
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 numpy
On Tue, Feb 14, 2012 at 7:22 AM, Gordon L. Kindlmann g...@uchicago.eduwrote:
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
On Tuesday, February 14, 2012, Travis Oliphant tra...@continuum.io 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
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
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,
On Mon, Feb 13, 2012 at 6:19 PM, Mark Wiebe mwwi...@gmail.com 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
On 02/14/2012 08:59 AM, Chris Barker wrote:
On Mon, Feb 13, 2012 at 6:19 PM, Mark Wiebemwwi...@gmail.com 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
On Mon, Feb 13, 2012 at 9:55 PM, Fernando Perez fperez@gmail.com 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
On Tue, Feb 14, 2012 at 9:26 AM, David Cournapeau courn...@gmail.com 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 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 our
On Tue, Feb 14, 2012 at 1:03 AM, Travis Oliphant tra...@continuum.iowrote:
snip
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
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
Hi,
You can subscribe here:
http://mail.scipy.org/mailman/listinfo/numpy-discussion
-=- Olivier
Le 14 février 2012 14:22, pulkit yadav yadavpul...@gmail.com 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
Hi,
On Tue, Feb 14, 2012 at 10:25 AM, Travis Oliphant tra...@continuum.io 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
On Tue, Feb 14, 2012 at 12:25 PM, Travis Oliphant tra...@continuum.iowrote:
snip
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
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 limitations
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 really
- 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 person.
I
On Tue, Feb 14, 2012 at 7:25 PM, Travis Oliphant tra...@continuum.iowrote:
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
On Tuesday, February 14, 2012, Travis Oliphant tra...@continuum.io 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
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 and who
On Tue, Feb 14, 2012 at 12:27 PM, Benjamin Root ben.r...@ou.edu wrote:
On Tuesday, February 14, 2012, Travis Oliphant tra...@continuum.io
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
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 Foundation.
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
On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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,
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 the sub 10
Hi,
On Tue, Feb 14, 2012 at 1:54 PM, Travis Oliphant tra...@continuum.io 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,
On 02/14/2012 03:12 PM, Chris Barker wrote:
On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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
On Tue, Feb 14, 2012 at 4:03 AM, Francesc Alted franc...@continuum.io 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
On Tue, Feb 14, 2012 at 3:12 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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
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
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 this
On Tue, 2012-02-14 at 15:12 -0800, Chris Barker wrote:
On Tue, Feb 14, 2012 at 9:16 AM, Dag Sverre Seljebotn
d.s.seljeb...@astro.uio.no 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
On Tuesday, February 14, 2012, Matthew Brett matthew.br...@gmail.com
wrote:
Hi,
On Tue, Feb 14, 2012 at 1:54 PM, Travis Oliphant tra...@continuum.io
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
Hi,
On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant tra...@continuum.io 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
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 also
Hi,
On Tue, Feb 14, 2012 at 4:43 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant tra...@continuum.io 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
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, scipy,
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 Foundation
On Tuesday, February 14, 2012, Travis Oliphant tra...@continuum.io 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
On Tue, Feb 14, 2012 at 6:43 PM, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Tue, Feb 14, 2012 at 3:58 PM, Travis Oliphant tra...@continuum.io 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
On Tue, Feb 14, 2012 at 2:24 PM, Ralf Gommers
ralf.gomm...@googlemail.com wrote:
On Tue, Feb 14, 2012 at 7:25 PM, Travis Oliphant tra...@continuum.io
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
Hi,
On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe mwwi...@gmail.com 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
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
On Tue, Feb 14, 2012 at 7:19 PM, Matthew Brett matthew.br...@gmail.comwrote:
Hi,
On Mon, Feb 13, 2012 at 7:02 PM, Mark Wiebe mwwi...@gmail.com 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.
On Tue, Feb 14, 2012 at 9:17 PM, Benjamin Root ben.r...@ou.edu 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
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root ben.r...@ou.edu 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
On Tuesday, February 14, 2012, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root ben.r...@ou.edu 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
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
On Tue, Feb 14, 2012 at 9:37 PM, Benjamin Root ben.r...@ou.edu wrote:
On Tuesday, February 14, 2012, Mark Wiebe mwwi...@gmail.com wrote:
On Tue, Feb 14, 2012 at 8:17 PM, Benjamin Root ben.r...@ou.edu wrote:
Just a thought I had. Right now, I can pass a list of python ints or
floats into
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 =
71 matches
Mail list logo
