Re: [Numpy-discussion] Removing numscons, adding bento scripts to main branch ?

sound ok with everyone ? > > cheers, > > David > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. ol

Re: [Numpy-discussion] Removing numscons, adding bento scripts to main branch ?

gt; Does that sound ok with everyone ? > > cheers, > > David > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. ol

[Numpy-discussion] 1.7.x release of NumPy

Hi all, Has there been a discussion of a 1.7.x release of NumPy? There are a few new features that should go into the 1.x release of NumPy, that don't require the ABI changes of 2.0.I thought I had heard Mark talk in support of such a thing. What are the plans for the release of Num

Re: [Numpy-discussion] lstsq: masked arrays, weights, scaling, and covariance

Chuck > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthought.com 1-512-536-1057 http://www.enthought.com

[Numpy-discussion] A Foundation for the support of NumPy and SciPy

Hi all, At the recent US SciPy conference and at other times in the past I have been approached about the possibility of creating a foundation to support the development of SciPy and NumPy. I know there are varying opinions about that, but I am generally very supportive of the idea and would

Re: [Numpy-discussion] A Foundation for the support of NumPy and SciPy

; Busybox, jQuery, Wine, Boost, ... have also chosen this approach: > http://www.sfconservancy.org/members/current/ > > TL;DR: When it comes to legal matters: starting your own non-profit is > to joining an existing umbrella non-profit as CVS is to git. (And in > fact git is

Re: [Numpy-discussion] NA masks in the next numpy release?

ing the issues, and we can certainly discuss ways to improve this. > > Remember, we *all* have a common agreement here. NumPy needs better support > for missing data (in whatever form). Let's work from that assumption and > make NumPy a better library to use for everybody! > > Cheers! > Ben Root > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthought.com 1-512-536-1057 http://www.enthought.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NA masks in the next numpy release?

gt; > On Tue, Oct 25, 2011 at 2:56 PM, Travis Oliphant > wrote: >> It is a shame that Nathaniel and perhaps Matthew do not feel like their >> voice was heard. I wish I could have participated more fully in some of >> the discussions. I don't know if I could have real

Re: [Numpy-discussion] NA masks in the next numpy release?

s the counter-argument to this proposal? -Travis On Oct 27, 2011, at 7:31 PM, Matthew Brett wrote: > Hi, > > On Tue, Oct 25, 2011 at 7:56 PM, Travis Oliphant > wrote: >> So, I am very interested in making sure I remember the details of the >> counterproposal.What I

Re: [Numpy-discussion] NA masks in the next numpy release?

> the current implementation. There is nothing essentially masky about masks. > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis O

Re: [Numpy-discussion] consensus (was: NA masks in the next numpy release?)

not dealing with missing data well is a missing NumPy feature. -Travis > See you, > > Matthew > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discu

Re: [Numpy-discussion] consensus (was: NA masks in the next numpy release?)

On Oct 29, 2011, at 7:24 PM, Eric Firing wrote: > On 10/29/2011 12:57 PM, Charles R Harris wrote: >> >> >> On Sat, Oct 29, 2011 at 4:47 PM, Eric Firing > > wrote: >> >>On 10/29/2011 12:02 PM, Olivier Delalleau wrote: >> >>> >>> I haven't been following the disc

[Numpy-discussion] NumPy Governance

Hi everyone, There have been some wonderfully vigorous discussions over the past few months that have made it clear that we need some clarity about how decisions will be made in the NumPy community. When we were a smaller bunch of people it seemed easier to come to an agreement and things

Re: [Numpy-discussion] NumPy Governance

list. -Travis On Dec 3, 2011, at 9:42 PM, Matthew Brett wrote: > Hi Travis, > > On Sat, Dec 3, 2011 at 6:18 PM, Travis Oliphant wrote: >> >> Hi everyone, >> >> There have been some wonderfully vigorous discussions over the past few >> months that

Re: [Numpy-discussion] NumPy Governance

n Isaac > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthought.com 1-512-536-1057 http://www.enthought.com __

Re: [Numpy-discussion] numpy 1.7.0 release?

I like the idea. Is there resolution to the NA question? -- Travis Oliphant (on a mobile) 512-826-7480 On Dec 5, 2011, at 2:43 PM, Ralf Gommers wrote: > Hi all, > > It's been a little over 6 months since the release of 1.6.0 and the NA debate > has quieted down, so I&#

Re: [Numpy-discussion] Owndata flag

tempt to interpret it as > though it had an underlying truth." > -- Umberto Eco > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion --- Travis Oliphant Enthought, Inc. oliph...@enthou

Re: [Numpy-discussion] test code for user defined types in numpy

This is really excellent. I would like to take a stab at getting this pulled in to the code base --- and fixing the GIL issue --- if someone hasn't beat me to it. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Dec 20, 2011, at 9:24 PM, Geoffrey Irving wrote: > Hello, &

Re: [Numpy-discussion] Indexing empty dimensions with empty arrays

I agree with Dag, NumPy should provide consistent handling of empty arrays. It does require some work, but it should be at least declared a bug when it doesn't. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Dec 28, 2011, at 7:45 AM, Dag Sverre Seljebotn wrote: > On 12

Re: [Numpy-discussion] NumPy Governance

That was an extremely helpful and useful post. Thank you Ondrej for sharing it and taking the time to provide that insight. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Dec 29, 2011, at 12:51 AM, Ondrej Certik wrote: > On Mon, Dec 5, 2011 at 4:22 AM, Perry Greenfield wr

Re: [Numpy-discussion] Enum type

A categorical type (or enum type) is an important dtype to add to NumPy. It would be very nice if the option existed to make the categorical dtype "dynamic" in that the categories can grow as more data is added or inserted into the array. This would effectively allow binning of data on inser

Re: [Numpy-discussion] PyInt and Numpy's int64 conversion

>>> >>> No. All of the PyTypeObject objects for the NumPy array scalars are >>> explicitly part of the NumPy C API so you have no choice but to depend >>> on that (to get the best performance). If you want to ONLY check for >>> int64 at the C API level, I did a bit of digging and the relevant type

Re: [Numpy-discussion] Improving Python+MPI import performance

It is a straightforward thing to implement a "registry mechanism" for Python that by-passes imp.find_module (i.e. using sys.meta_path). You could imagine creating the registry file for a package or distribution (much like Dag described) and push that to every node during distribution. The

Re: [Numpy-discussion] Download page still points to SVN

I think the problem here is one of delegation and information. I'm not even sure how the web-pages get updated at this point. Does anyone on this list know?I think it would be a great idea to move to github pages for the NumPy project at least. -Travis On Jan 19, 2012, at 12:39 AM, Fer

Re: [Numpy-discussion] advanced indexing bug with huge arrays?

Can you determine where the problem is, precisely.In other words, can you verify that c is not getting filled in correctly? You are no doubt going to get overflow in the summation as you have a uint8 parameter. But, having that overflow be exactly '0' would be surprising. Can you verif

Re: [Numpy-discussion] numpy all unexpected result (generator)

I also agree that an exception should be raised at the very least. It might also be possible to make the NumPy any, all, and sum functions behave like the builtins when given a generator. It seems worth exploring at least. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jan 31

Re: [Numpy-discussion] numpy all unexpected result (generator)

under what conditions 'array' could correctly interpret a generator expression, but in the context of streaming or deferred arrays. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Jan 31, 2012, at 4:22 PM, Robert Kern wrote: > On Tue, Jan 31, 2012 at 22:17, Travis Ol

Re: [Numpy-discussion] Documentation question.

On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote: > On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris > wrote: > The macro PyArray_RemoveLargest has been replaced by PyArray_RemoveSmallest > (which seems strange), but I wonder if this documentation still makes sense. > > My impression about this c

Re: [Numpy-discussion] Documentation question.

Thanks! What a great doc page. -Travis On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote: > On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant wrote: > > On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote: > >> On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris >

Re: [Numpy-discussion] Documentation question.

Here is some information on it. http://marketingstartups.com/2009/05/28/the-first-six-steps-of-getting-your-startup-noticed/ -Travis On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote: > On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant wrote: > > On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrot

Re: [Numpy-discussion] Documentation question.

-Travis On Feb 1, 2012, at 8:31 PM, Mark Wiebe wrote: > On Wed, Feb 1, 2012 at 6:14 PM, Travis Oliphant wrote: > > On Feb 1, 2012, at 7:04 PM, Mark Wiebe wrote: > >> On Wed, Feb 1, 2012 at 3:29 PM, Charles R Harris >> wrote: >> The macro PyArray_RemoveLargest has

Re: [Numpy-discussion] Curious behavior of __radd__

This seems odd to me. Unraveling what is going on (so far): Let a = np.complex64(1j) and b = A() * np.complex64.__add__ is calling np.add * np.add(a, b) needs to search for an "add" loop that matches the input types and it finds one with signature ('O

Re: [Numpy-discussion] ufunc delegation to object method

Yes. This is the behavior. It was part of the original Numeric implementation.In the code generator file: numpy/core/code_generators/generate_umath.py ufuncs with a registered type of 'P' have this behavior. There is a long list of them. -Travis On Feb 2, 2012, at 12:04 AM,

Re: [Numpy-discussion] Curious behavior of __radd__

Hey Andreas, As previously described: what changes the type of np.complex64(1j) during the A() call is that when a is an array scalar it is converted to an object array because that is the only signature that matches. During this conversion, what is extracted from the object array is piped t

Re: [Numpy-discussion] Heads up and macro deprecation.

On Feb 2, 2012, at 12:58 PM, Ralf Gommers wrote: > > > On Thu, Feb 2, 2012 at 6:36 PM, Charles R Harris > wrote: > > > On Thu, Feb 2, 2012 at 9:58 AM, Bruce Southey wrote: > On 02/01/2012 02:53 PM, Charles R Harris wrote: >> >> Hi All, >> >> Two things here. >> >> 1) Some macros for thr

Re: [Numpy-discussion] Documentation question.

I see your time machine is in full working order :-) -- Travis Oliphant (on a mobile) 512-826-7480 On Feb 2, 2012, at 4:18 PM, Mark Wiebe wrote: > On Wed, Feb 1, 2012 at 7:13 PM, Travis Oliphant wrote: > Hey Mark, > > I spent some quality time with your iterator docs toni

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

release of June 2012. Thanks, Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Feb 4, 2012, at 11:37 AM, Charles R Harris wrote: > Hi All, > > In the discussion on deprecating old macros in 1.7 as part of pull request > 189 the issue of how to move numpy forward and st

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

t; >> >> On Sat, Feb 4, 2012 at 3:03 PM, Travis Oliphant wrote: >>> >>> We are spending a lot of time on NumPy and will be for the next few >>> months. I think that 1.8 will be a better long term release. We need a few >>> more fundamental features y

Re: [Numpy-discussion] dtype related deprecations

Fortunately that's not the case. All that Mark is advocating is not allowing changing the *itself* in place. You are still free to change the dtype of the array in order to change the field names without making a data copy. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On

Re: [Numpy-discussion] Download page still points to SVN

On Feb 7, 2012, at 4:02 AM, Pauli Virtanen wrote: > Hi, > > 06.02.2012 20:41, Ralf Gommers kirjoitti: > [clip] >> I've created https://github.com/scipy/scipy.github.com and gave you >> permissions on that. So with that for the built html and >> https://github.com/scipy/scipy.org-new for the sour

Re: [Numpy-discussion] Logical indexing and higher-dimensional arrays.

This comes up from time to time.This is an example of what is described at the top of page 84 of "Guide to NumPy". Also read Chapter 17 to get the explanation of how fancy indexing is implemented if you really want to understand the issues. When you mix fancy-indexing with "simple indexin

Re: [Numpy-discussion] Logical indexing and higher-dimensional arrays.

On Feb 7, 2012, at 12:24 PM, Sturla Molden wrote: > On 07.02.2012 19:17, Benjamin Root wrote: > > print x.shape >> (2, 3, 4) > print x[0, :, :].shape >> (3, 4) > print x[0, :, idx].shape >> (2, 3) > > That looks like a bug to me. The length of the first dimension should be > the sa

Re: [Numpy-discussion] Logical indexing and higher-dimensional arrays.

On Feb 8, 2012, at 8:29 AM, Sturla Molden wrote: > On 08.02.2012 06:01, Travis Oliphant wrote: > >> Recall that the shape of the output with fancy indexing is determined by >> broadcasting together the indexing objects and using that as the shape of >> the output: &

Re: [Numpy-discussion] Logical indexing and higher-dimensional arrays.

On Feb 8, 2012, at 11:17 AM, josef.p...@gmail.com wrote: > On Wed, Feb 8, 2012 at 10:29 AM, Sturla Molden wrote: >> On 08.02.2012 15:49, Travis Oliphant wrote: >> >>> This sort of thing would take time, but is not out of the question in my >>> mind because

Re: [Numpy-discussion] Logical indexing and higher-dimensional arrays.

On Feb 8, 2012, at 4:19 PM, Robert Kern wrote: > On Wed, Feb 8, 2012 at 22:11, Travis Oliphant wrote: >> >> On Feb 8, 2012, at 11:17 AM, josef.p...@gmail.com wrote: >> >>> On Wed, Feb 8, 2012 at 10:29 AM, Sturla Molden wrote: >>>> On 08.02.2012 15:4

Re: [Numpy-discussion] On making Numpy 1.7 a long term support release.

. Best, -Travis On Feb 10, 2012, at 3:25 AM, David Cournapeau wrote: > On Sun, Feb 5, 2012 at 7:19 AM, Ralf Gommers > wrote: >> >> >> On Sun, Feb 5, 2012 at 7:33 AM, Travis Oliphant wrote: >>> >>> I think supporting Python 2.5 and above is com

[Numpy-discussion] Commit rights to NumPy for Francesc Alted

I propose to give Francesc Alted commit rights to the NumPy project. Francesc will be working full time on NumPy for several months and it will enable him to participate in pull requests. Francesc Alted has been very active in the larger Python for Science community and has written PyTable

[Numpy-discussion] Migrating issues to GitHub

How to people feel about moving the issue tracking for NumPy to Github?It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://g

Re: [Numpy-discussion] Migrating issues to GitHub

, at 2:06 PM, Benjamin Root wrote: > > > On Saturday, February 11, 2012, Travis Oliphant wrote: > > How to people feel about moving the issue tracking for NumPy to Github? > > It looks like they have improved their issue tracking quite a bit and the > > workflow a

Re: [Numpy-discussion] Migrating issues to GitHub

a good opportunity for others who would like to get some experience with NumPy. -Travis On Feb 11, 2012, at 2:53 PM, Charles R Harris wrote: > > > On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant wrote: > This is good feedback. > > It looks like there are 2 concerns:

[Numpy-discussion] Issue Tracking

I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments.Both of these plans allow Open Source projects to have unlimited plans for free. YouTrack from JetBrains: http://www.jetbrains.com/youtrack/features/issue_tracking.html

Re: [Numpy-discussion] Indexing 2d arrays by column using an integer array

I think the following is what you want: neighborhoods[range(9),perf[neighbourhoods].argmax(axis=1)] -Travis On Feb 13, 2012, at 1:26 PM, William Furnass wrote: > np.array( [neighbourhoods[i][perf[neighbourhoods].argmax(axis=1)[i]] > for i in xrange(neighbourhoods.shape[0])] ) ___

Re: [Numpy-discussion] Issue Tracking

> > On Mon, Feb 13, 2012 at 12:12 AM, Travis Oliphant wrote: > I'm wondering about using one of these commercial issue tracking plans for > NumPy and would like thoughts and comments.Both of these plans allow Open > Source projects to have unlimited plans for free.

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

Hmmm. This seems like a regression. The scalar casting API was fairly intentional. What is the reason for the change? -- Travis Oliphant (on a mobile) 512-826-7480 On Feb 13, 2012, at 6:25 PM, Matthew Brett wrote: > Hi, > > I recently noticed a change in the upcasting rules

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

worked to stay true to the Numeric casting rules incorporating the changes to prevent scalar upcasting due to the absence of single precision Numeric literals in Python. We will need to look in detail at what has changed. I will write a test to do that. Thanks, Travis -- Travis Oliphant (on a

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

few bugs and regressions in the > release. Most of these quality standards are still informal, however, and > it's probably a good idea to write them down in a canonical location. It will > be especially helpful for newcomers, who can treat the standards as a > checklist before sub

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

resulted in very few bugs and regressions in the > release. Most of these quality standards are still informal, however, and > it's probably a good idea to write them down in a canonical location. It will > be especially helpful for newcomers, who can treat the standards as a > chec

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

d too long with all the possible discussions that can take place :-) ) Best regards, -Travis On Feb 13, 2012, at 10:31 PM, Mark Wiebe wrote: > On Mon, Feb 13, 2012 at 8:04 PM, Travis Oliphant wrote: > I disagree with your assessment of the subscript operator, but I'm sure we

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

On Feb 13, 2012, at 10:14 PM, Charles R Harris wrote: > > > On Mon, Feb 13, 2012 at 9:04 PM, Travis Oliphant wrote: > I disagree with your assessment of the subscript operator, but I'm sure we > will have plenty of time to discuss that. I don't think it's cor

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

> > > > No argument on any of this. It's just that this needs to happen at NumPy > > 2.0, not in the NumPy 1.X series. I think requiring a re-compile is > > far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6 > > release. That's my major point, and I'm surprised oth

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

> > > > No argument on any of this. It's just that this needs to happen at NumPy > > 2.0, not in the NumPy 1.X series. I think requiring a re-compile is > > far-less onerous than changing the type-coercion subtly in a 1.5 to 1.6 > > release. That's my major point, and I'm surprised oth

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

> > You might be right, Chuck. I would like to investigate more, however. > > What I fear is that there are *a lot* of users still on NumPy 1.3 and NumPy > 1.5. The fact that we haven't heard any complaints, yet, does not mean to > me that we aren't creating headache for people later who h

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

> > 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 > varies platform to platform. I think that confusion is a mo

[Numpy-discussion] Updated differences between 1.5.1 to 1.6.1

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

Re: [Numpy-discussion] _import_array()

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

Re: [Numpy-discussion] Updated differences between 1.5.1 to 1.6.1

re the initial board of the Foundation. But, I expect the Foundation directors to evolve over time. Best regards, -Travis > > regards, > > David > > On Tue, Feb 14, 2012 at 9:03 AM, Travis Oliphant wrote: >> For reference, here is the table that shows the actual c

Re: [Numpy-discussion] Change in scalar upcasting rules for 1.6.x?

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 >> current

Re: [Numpy-discussion] Typecasting changes from 1.5.1 to 1.6.1

> > 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

Re: [Numpy-discussion] [cython-users] Discussion with Guido van Rossum and (hopefully) core python-dev on scientific Python and Python3

>> >> - 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

Re: [Numpy-discussion] Numpy governance update - was: Updated differences between 1.5.1 to 1.6.1

>> >> 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

Re: [Numpy-discussion] Release management (was: Updated differences between 1.5.1 to 1.6.1)

> > 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

Re: [Numpy-discussion] Numpy governance update - was: Updated differences between 1.5.1 to 1.6.1

>> >> 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

Re: [Numpy-discussion] Numpy governance update - was: Updated differences between 1.5.1 to 1.6.1

> > 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

Re: [Numpy-discussion] Numpy governance update - was: Updated differences between 1.5.1 to 1.6.1

>> >> 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

Re: [Numpy-discussion] Download page still points to SVN

It certainly would help people keep the NumPy web-site up to date. Thanks Ognen. -Travis On Feb 15, 2012, at 7:18 AM, Ognen Duzlevski wrote: > On Wed, Feb 15, 2012 at 5:13 AM, Scott Sinclair > wrote: >> On 8 February 2012 00:03, Travis Oliphant wrote: >>> >>&

Re: [Numpy-discussion] Release management (was: Updated differences between 1.5.1 to 1.6.1)

On Feb 15, 2012, at 9:17 AM, Charles R Harris wrote: > > > On Tue, Feb 14, 2012 at 1: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 T

Re: [Numpy-discussion] PyArray_FromAny() steals a reference to PyArray_Descr* dtype

Yes, the PyArray_FromAny steals a reference to the dtype object. This is done so you can build one on the fly doing something like PyArray_DescrFromType(NPY_DOUBLE) inline with the PyArray_FromAny call. -Travis On Feb 15, 2012, at 4:23 PM, Larsen, Brian A wrote: > Hello all, > > the

Re: [Numpy-discussion] Numpy governance update

This has been a clarifying discussion for some people. I'm glad people are speaking up. I believe in the value of consensus and the value of users opinions.I want to make sure that people who use NumPy and haven't yet learned how to contribute, feel like they have a voice. I have alway

[Numpy-discussion] Proposed Roadmap Overview

Mark Wiebe and I have been discussing off and on (as well as talking with Charles) a good way forward to balance two competing desires: * addition of new features that are needed in NumPy * improving the code-base generally and moving towards a more maintainable NumPy I know th

Re: [Numpy-discussion] Numpy governance update

tt wrote: > Hi, > > Just for my own sake, can I clarify what you are saying here? > > On Thu, Feb 16, 2012 at 1:11 PM, Travis Oliphant wrote: >> I'm not a big fan of design-by-committee as I haven't seen it be very >> successful in creating new technologies. I

Re: [Numpy-discussion] Buildbot/continuous integration (was Re: Issue Tracking)

We never turn down good help like this. Thank's Chris. I have applied for an unlimited license for TeamCity for the NumPy project. I have heard good things about TeamCity, although getting the slaves cranking and staying cranking is the goal and not the CI architecture.If you know build

Re: [Numpy-discussion] Buildbot/continuous integration (was Re: Issue Tracking)

The OS X slaves (especially PPC) are very valuable for testing.We have an intern who could help keep the build-bots going if you would give her access to those machines. Thanks for being willing to offer them. -Travis On Feb 16, 2012, at 6:36 PM, Matthew Brett wrote: > Hi, > > On Thu,

Re: [Numpy-discussion] timezones and datetime64

etimes > > > In [47]: pydate(str(d)) == datetime.datetime(2014, 1, 1, tzinfo=tzutc()) > Out[47]: True > > In [48]: pydate(str(d)).replace(tzinfo=None) == datetime.datetime(2014, 1, > 1) > Out[48]: True > > > In this case it may be best to have numpy not try

Re: [Numpy-discussion] ufunc overrides

p, it is still pretty incomplete, it can be > found here: > > https://github.com/cowlicks/numpy/blob/ufunc-override/doc/neps/ufunc-overrides.rst > > _______ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.

Re: [Numpy-discussion] Permissions on Sourceforge

Done, for numpy. Someone else will have to help with scipy. > > -- > Robert Kern > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- Travis Oliphant Continuum Analytics, Inc. http://www.continuum.io ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Indexing changes in 1.9

This sounds like a great and welcome work and improvements. Does it make sense to also do something about the behavior of advanced indexing when slices are interleaved between lists and integers. I know that jay borque has some preliminary work to fix this. There are a some straightforward fixe

Re: [Numpy-discussion] Indexing changes in 1.9

exing code paths. Is their a roadmap for 1.9? Travis On Feb 3, 2014 1:26 PM, "Sebastian Berg" wrote: > On Sun, 2014-02-02 at 13:11 -0600, Travis Oliphant wrote: > > This sounds like a great and welcome work and improvements. > > > > Does it make sense to also do some

Re: [Numpy-discussion] It looks like Py 3.5 will include a dedicated infix matrix multiply operator

Congratulations Nathaniel! This is great news! Well done on starting the process and taking things forward. Travis On Mar 14, 2014 7:51 PM, "Nathaniel Smith" wrote: > Well, that was fast. Guido says he'll accept the addition of '@' as an > infix operator for matrix multiplication, once some de

Re: [Numpy-discussion] PEP 465 has been accepted / volunteers needed

Congratulations! This is definitely a big step for array-computing with Python. Working with the Python devs to implement a PEP can be a tremendous opportunity to increase your programming awareness and ability --- as well as make some good friends. This is a great way to get involved with both

Re: [Numpy-discussion] SciPy 2014 BoF NumPy Participation

ajor project > that was not really represented in the BoF sessions). > > Thanks! > > Kyle Manldi (and via proxy Matt McCormick) > > > > _______ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/

Re: [Numpy-discussion] big-bangs versus incremental improvements (was: Re: SciPy 2014 BoF NumPy Participation)

Believe me, I'm all for incremental changes if it is actually possible and doesn't actually cost more. It's also why I've been silent until now about anything we are doing being a candidate for a NumPy 2.0. I understand the challenges of getting people to change. But, features and solid improvem

Re: [Numpy-discussion] Custom dtypes without C -- or, a standard ndarray-like type

On Sun, Sep 21, 2014 at 6:50 PM, Stephan Hoyer wrote: > pandas has some hacks to support custom types of data for which numpy > can't handle well enough or at all. Examples include datetime and > Categorical [1], and others like GeoArray [2] that haven't make it into > pandas yet. > > Most of the

Re: [Numpy-discussion] Custom dtypes without C -- or, a standard ndarray-like type

ivision > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://

Re: [Numpy-discussion] Copyright status of NumPy binaries on Windows/OS X

gt; > Thanks! > Andrew Collette > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Travis Oliphant CEO Continuum Analytics, Inc. http://www.continuum.io

Re: [Numpy-discussion] Copyright status of NumPy binaries on Windows/OS X

easons to start with the development of a > dedicated mingw-w64 based compiler toolchain to support OpenBLAS / ATLAS > based binaries on windows. > > Cheers, > > carlkl > > > > 2014-10-08 1:32 GMT+02:00 Travis Oliphant : > >> Hey Andrew, >> >> You can us

Re: [Numpy-discussion] Copyright status of NumPy binaries on Windows/OS X

(two flavors). It should be straightforward to take those binaries and make conda (or wheel) packages out of them. A good mingw64 stack for Windows would be great and benefits many communities. On Wed, Oct 8, 2014 at 4:46 PM, Sturla Molden wrote: > Travis Oliphant wrote: > > > Micro

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

Obviously there are still a lot of details to work out, though. But > overall, there was widespread agreement that this is one of the #1 > pain points for our users (e.g. it's the single main request from > pandas), and fixing it is very high priority. > > Some features

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris wrote: > > > On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant > wrote: > >> Thanks for the write-up Nathaniel. There is a lot of great detail and >> interesting ideas here. >> >> >> > > Th

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

On Tue, Aug 25, 2015 at 3:58 PM, Charles R Harris wrote: > > > On Tue, Aug 25, 2015 at 1:00 PM, Travis Oliphant > wrote: > >> Thanks for the write-up Nathaniel. There is a lot of great detail and >> interesting ideas here. >> >> >> > > I th

Re: [Numpy-discussion] Notes from the numpy dev meeting at scipy 2015

ne in a >>> backwards-compatible way.) >>> >>> - We need to figure out what exactly the dtype methods should be, >>> and add them to the dtype class (possibly with backwards >>> compatibility shims for anyone who is accessing PyArray_Ar

<    1   2   3   4   5   6   7   8   >