Mailman 3 August 2015 - NumPy-Discussion

UTC-based datetime64
by Francesc Alted 02 Sep '15

02 Sep '15

Hi, We've found that NumPy uses the local TZ for printing datetime64 timestamps: In [22]: t = datetime.utcnow() In [23]: print t 2015-08-26 11:52:10.662745 In [24]: np.array([t], dtype="datetime64[s]") Out[24]: array(['2015-08-26T13:52:10+0200'], dtype='datetime64[s]') Googling for a way to print UTC out of the box, the best thing I could find is: In [40]: [str(i.item()) for i in np.array([t], dtype="datetime64[s]")] Out[40]: ['2015-08-26 11:52:10'] Now, is there a better way to specify that I want the datetimes printed always in UTC? Thanks, -- Francesc Alted

3 2

Numpty FFT.FFT slow with certain samples
by Joseph Codadeen 01 Sep '15

01 Sep '15

Hi, I am a numpy newbie. I have two wav files, one that numpy takes a long time to process the FFT. They was created within audacity using white noise and silence for gaps. my_1_minute_noise_with_gaps.wavmy_1_minute_noise_with_gaps_truncated.wav The files are very similar in the following way; 1. is white noise with silence gaps on every 15 second interval.2. is 1. but slightly shorter, i.e. I trimmed some ms off the end but it still has the last gap at 60s. The code I am using processes the file like this; framerate, data = scipy.io.wavfile.read(filepath) right = data[:, 0] # Align it to be efficient. if len(right) % 2 != 0: right = right[range(len(right) - 1)] noframes = len(right) fftout = np.fft.fft(right) / noframes # <<< I am timing this cmd Using timeit... my_1_minute_noise_with_gaps_truncated took 30.75620985s to process.my_1_minute_noise_with_gaps took 22307.13917s to process. Could someone tell me why this behaviour is happening please? Sorry I can't attach the files as this email gets bounced but you could easily create the files yourself.E.g my last gap width is 59.9995 - 1:00.0005, I repeat this every 15 seconds.My truncated file is 1:00.0015s long, non-truncated is 1:00.0833s long Thanks.

10 17

Cythonizing some of NumPy
by David Cournapeau 01 Sep '15

01 Sep '15

Hi there, Reading Nathaniel summary from the numpy dev meeting, it looks like there is a consensus on using cython in numpy for the Python-C interfaces. This has been on my radar for a long time: that was one of my rationale for splitting multiarray into multiple "independent" .c files half a decade ago. I took the opportunity of EuroScipy sprints to look back into this, but before looking more into it, I'd like to make sure I am not going astray: 1. The transition has to be gradual 2. The obvious way I can think of allowing cython in multiarray is modifying multiarray such as cython "owns" the PyMODINIT_FUNC and the module PyModuleDef table. 3. We start using cython for the parts that are mostly menial refcount work. Things like functions in calculation.c are obvious candidates. Step 2 should not be disruptive, and does not look like a lot of work: there are < 60 methods in the table, and most of them should be fairly straightforward to cythonize. At worse, we could just keep them as is outside cython and just "export" them in cython. Does that sound like an acceptable plan ? If so, I will start working on a PR to work on 2. David

2 2

1.10.0rc1
by Charles R Harris 27 Aug '15

27 Aug '15

Hi All, The silence after the 1.10 beta has been eerie. Consequently, I'm thinking of making a first release candidate this weekend. If you haven't yet tested the beta, please do so. It would be good to discover as many problems as we can before the first release. Chuck

5 15

Defining a white noise process using numpy
by Daniel Bliss 27 Aug '15

27 Aug '15

Hi all, Can anyone give me some advice for translating this equation into code using numpy? eta(t) = lim(dt -> 0) N(0, 1/sqrt(dt)), where N(a, b) is a Gaussian random variable of mean a and variance b**2. This is a heuristic definition of a white noise process. Thanks, Dan

3 2

[DRAFT] numpy governance document
by Nathaniel Smith 27 Aug '15

27 Aug '15

Hi all, Here's a first draft of a governance document for NumPy. A few people have seen sneak peeks and have suggested possibly reorganizing it either by taking some of the "how consensus works" stuff out into a separate document, or alternatively keeping that stuff in the foreground and moving some of the more legalistic bits into footnotes or something. I think there's some value in having a single document that sorta lays out everything a new contributor needs to know, both how things work normally and how they work when we need to fall back on formal processes, and have tried to make the different aspects fit together better in this draft, but I'm happy to reorganize however if that's what people want -- I just figured that I should at least get this out so the content is available for discussion, even if the form isn't perfect yet :-). In case it's useful for context, large chunks of text are taken from the Jupyter/IPython project's IPEP 29: https://github.com/ipython/ipython/wiki/IPEP-29:-Project-Governance There are some random tweaks throughout, but the parts that are mostly new are the "Summary", "Consensus-based decision making by the community", and "Council decision making" sections. -n --------------------- The purpose of this document is to formalize the governance process used by the NumPy project in both ordinary and extraordinary situations, and to clarify how decisions are made and how the various elements of our community interact, including the relationship between open source collaborative development and work that may be funded by for-profit or non-profit entities. Summary ======= NumPy is a community-owned and community-run project. To the maximum extent possible, decisions about project direction are made by community consensus (but note that "consensus" here has a somewhat technical meaning that might not match everyone's expectations -- see below). Some members of the community additionally contribute by serving on the NumPy steering council, where they are responsible for facilitating the establishment of community consensus, for stewarding project resources, and -- in extreme cases -- for making project decisions if the normal community-based process breaks down. The Project =========== The NumPy Project (The Project) is an open source software project affiliated with the 501(c)3 NumFocus Foundation. The goal of The Project is to develop open source software for array-based computing in Python, and in particular the `numpy` package, along with related software such as `f2py` and the NumPy Sphinx extensions. The Software developed by The Project is released under the BSD (or similar) open source license, developed openly and hosted on public GitHub repositories under the `numpy` GitHub organization. The Project is developed by a team of distributed developers, called Contributors. Contributors are individuals who have contributed code, documentation, designs or other work to the Project. Anyone can be a Contributor. Contributors can be affiliated with any legal entity or none. Contributors participate in the project by submitting, reviewing and discussing GitHub Pull Requests and Issues and participating in open and public Project discussions on GitHub, mailing lists, and other channels. The foundation of Project participation is openness and transparency. Here is a list of the current Contributors to the main NumPy repository: [https://github.com/numpy/numpy/graphs/contributors](https://github.com/nump… The Project Community consists of all Contributors and Users of the Project. Contributors work on behalf of and are responsible to the larger Project Community and we strive to keep the barrier between Contributors and Users as low as possible. The Project is formally affiliated with the 501(c)3 NumFOCUS Foundation ([http://numfocus.org](http://numfocus.org)), which serves as its fiscal sponsor, may hold project trademarks and other intellectual property, helps manage project donations and acts as a parent legal entity. NumFOCUS is the only legal entity that has a formal relationship with the project (see Institutional Partners section below). Governance ========== This section describes the governance and leadership model of The Project. The foundations of Project governance are: - Openness & Transparency - Active Contribution - Institutional Neutrality Consensus-based decision making by the community ------------------------------------------------ Normally, all project decisions will be made by consensus of all interested Contributors. The primary goal of this approach is to ensure that the people who are most affected by and involved in any given change can contribute their knowledge in the confidence that their voices will be heard, because thoughtful review from a broad community is the best mechanism we know of for creating high-quality software. The mechanism we use to accomplish this goal may be unfamiliar for those who are not experienced with the cultural norms around free/open-source software development. We provide a summary here, and highly recommend that all Contributors additionally read [Chapter 4: Social and Political Infrastructure](http://producingoss.com/en/producingoss.html#social-infrast… of Karl Fogel's classic *Producing Open Source Software*, and in particular the section on [Consensus-based Democracy](http://producingoss.com/en/producingoss.html#consensus-democracy), for a more detailed discussion. In this context, consensus does *not* require: - that we wait to solicit everybody's opinion on every change, - that we ever hold a vote on anything, - or that everybody is happy or agrees with every decision. For us, what consensus means is that we entrust *everyone* with the right to veto any change if they feel it necessary. While this may sound like a recipe for obstruction and pain, this is not what happens. Instead, we find that most people take this responsibility seriously, and only invoke their veto when they judge that a serious problem is being ignored, and that their veto is necessary to protect the project. And in practice, it turns out that such vetoes are almost never formally invoked, because their mere possibility ensures that Contributors are motivated from the start to find some solution that everyone can live with -- thus accomplishing our goal of ensuring that all interested perspectives are taken into account. How do we know when consensus has been achieved? In principle, this is rather difficult, since consensus is defined by the absence of vetos, which requires us to somehow prove a negative. In practice, we use a combination of our best judgement (e.g., a simple and uncontroversial bug fix posted on GitHub and reviewed by a core developer is probably fine) and best efforts (e.g., all substantive API changes must be posted to the mailing list in order to give the broader community a chance to catch any problems and suggest improvements; we assume that anyone who cares enough about NumPy to invoke their veto right should be on the mailing list). If no-one bothers to comment on the mailing list after a few days, then it's probably fine. And worst case, if a change is more controversial than expected, or a crucial critique is delayed because someone was on vacation, then it's no big deal: we apologize for misjudging the situation, [back up, and sort things out](http://producingoss.com/en/producingoss.html#version-control-relaxatio…. If one does need to invoke a formal veto, then it should consist of: - an unambiguous statement that a veto is being invoked, - an explanation of why it is being invoked, and - a description of what conditions (if any) would convince the vetoer to withdraw their veto. If all proposals for resolving some issue are vetoed, then the status quo wins by default. In the worst case, if a Contributor is genuinely misusing their veto in an obstructive fashion to the detriment of the project, then they can be ejected from the project by consensus of the Steering Council -- see below. Steering Council ---------------- The Project will have a Steering Council that consists of Project Contributors who have produced contributions that are substantial in quality and quantity, and sustained over at least one year. The overall role of the Council is to ensure, with input from the Community, the long-term well-being of the project, both technically and as a community. During the everyday project activities, council members participate in all discussions, code review and other project activities as peers with all other Contributors and the Community. In these everyday activities, Council Members do not have any special power or privilege through their membership on the Council. However, it is expected that because of the quality and quantity of their contributions and their expert knowledge of the Project Software and Services that Council Members will provide useful guidance, both technical and in terms of project direction, to potentially less experienced contributors. The Steering Council and its Members play a special role in certain situations. In particular, the Council may, if necessary: - Make decisions about the overall scope, vision and direction of the project. - Make decisions about strategic collaborations with other organizations or individuals. - Make decisions about specific technical issues, features, bugs and pull requests. They are the primary mechanism of guiding the code review process and merging pull requests. - Make decisions about the Services that are run by The Project and manage those Services for the benefit of the Project and Community. - Update policy documents such as this one. - Make decisions when regular community discussion doesn’t produce consensus on an issue in a reasonable time frame. However, the Council's primary responsibility is to facilitate the ordinary community-based decision making procedure described above. If we ever have to step in and formally override the community for the health of the Project, then we will do so, but we will consider reaching this point to indicate a failure in our leadership. ### Council decision making If it becomes necessary for the Steering Council to produce a formal decision, then they will use a form of the [Apache Foundation voting process](https://www.apache.org/foundation/voting.html). This is a formalized version of consensus, in which +1 votes indicate agreement, -1 votes are vetoes (and must be accompanied with a rationale, as above), and one can also vote fractionally (e.g. -0.5, +0.5) if one wishes to express an opinion without registering a full veto. These numeric votes are also often used informally as a way of getting a general sense of people's feelings on some issue, and should not normally be taken as formal votes. A formal vote only occurs if explicitly declared, and if this does occur then the vote should be held open for long enough to give all interested Council Members a chance to respond -- at least one week. In practice, we anticipate that for most Steering Council decisions (e.g., voting in new members) a more informal process will suffice. ### Council membership To become eligible to join the Steering Council, an individual must be a Project Contributor who has produced contributions that are substantial in quality and quantity, and sustained over at least one year. Potential Council Members are nominated by existing Council members and voted upon by the existing Council after asking if the potential Member is interested and willing to serve in that capacity. The Council will be initially formed from the set of existing Core Developers who, as of late 2015, have been significantly active over the last year. When considering potential Members, the Council will look at candidates with a comprehensive view of their contributions. This will include but is not limited to code, code review, infrastructure work, mailing list and chat participation, community help/building, education and outreach, design work, etc. We are deliberately not setting arbitrary quantitative metrics (like “100 commits in this repo”) to avoid encouraging behavior that plays to the metrics rather than the project’s overall well-being. We want to encourage a diverse array of backgrounds, viewpoints and talents in our team, which is why we explicitly do not define code as the sole metric on which council membership will be evaluated. If a Council member becomes inactive in the project for a period of one year, they will be considered for removal from the Council. Before removal, inactive Member will be approached to see if they plan on returning to active participation. If not they will be removed immediately upon a Council vote. If they plan on returning to active participation soon, they will be given a grace period of one year. If they don’t return to active participation within that time period they will be removed by vote of the Council without further grace period. All former Council members can be considered for membership again at any time in the future, like any other Project Contributor. Retired Council members will be listed on the project website, acknowledging the period during which they were active in the Council. The Council reserves the right to eject current Members, if they are deemed to be actively harmful to the project’s well-being, and attempts at communication and conflict resolution have failed. This requires the consensus of the remaining Members. [We also have to decide on the initial membership for the Council. While the above text makes pains to distinguish between "committer" and "Council Member", in the past we've pretty much treated them as the same. So to keep things simple and deterministic, I propose that we seed the Council with everyone who has reviewed/merged a pull request since Jan 1, 2014, and move those who haven't used their commit bit in >1.5 years to the emeritus list. Based on the output of git log --grep="^Merge pull request" --since 2014-01-01 | grep Author: | sort -u I believe this would give us an initial Steering Council of: @argriffing, Sebastian Berg, Jaime Fernández del Río, Ralf Gommers, Charles Harris, Nathaniel Smith, Julian Taylor, and Pauli Virtanen (assuming everyone on that list is interested/willing to serve).] ### Conflict of interest It is expected that the Council Members will be employed at a wide range of companies, universities and non-profit organizations. Because of this, it is possible that Members will have conflict of interests. Such conflict of interests include, but are not limited to: - Financial interests, such as investments, employment or contracting work, outside of The Project that may influence their work on The Project. - Access to proprietary information of their employer that could potentially leak into their work with the Project. All members of the Council shall disclose to the rest of the Council any conflict of interest they may have. Members with a conflict of interest in a particular issue may participate in Council discussions on that issue, but must recuse themselves from voting on the issue. ### Private communications of the Council Unless specifically required, all Council discussions and activities will be public and done in collaboration and discussion with the Project Contributors and Community. The Council will have a private mailing list that will be used sparingly and only when a specific matter requires privacy. When private communications and decisions are needed, the Council will do its best to summarize those to the Community after eliding personal/private/sensitive information that should not be posted to the public internet. ### Subcommittees The Council can create subcommittees that provide leadership and guidance for specific aspects of the project. Like the Council as a whole, subcommittees should conduct their business in an open and public manner unless privacy is specifically called for. Private subcommittee communications should happen on the main private mailing list of the Council unless specifically called for. ### NumFOCUS Subcommittee The Council will maintain one narrowly focused subcommittee to manage its interactions with NumFOCUS. - The NumFOCUS Subcommittee is comprised of 5 persons who manage project funding that comes through NumFOCUS. It is expected that these funds will be spent in a manner that is consistent with the non-profit mission of NumFOCUS and the direction of the Project as determined by the full Council. - This Subcommittee shall NOT make decisions about the direction, scope or technical direction of the Project. - This Subcommittee will have 5 members, 4 of whom will be current Council Members and 1 of whom will be external to the Steering Council. No more than 2 Subcommitee Members can report to one person through employment or contracting work (including the reportee, i.e. the reportee + 1 is the max). This avoids effective majorities resting on one person. [Initially, the NumFOCUS subcommittee will consist of: Chuck Harris, Ralf Gommers, Nathaniel Smith, and ???? as internal members, and Thomas Caswell as external member.] Institutional Partners and Funding ================================== The Steering Council are the primary leadership for the project. No outside institution, individual or legal entity has the ability to own, control, usurp or influence the project other than by participating in the Project as Contributors and Council Members. However, because institutions can be an important funding mechanism for the project, it is important to formally acknowledge institutional participation in the project. These are Institutional Partners. An Institutional Contributor is any individual Project Contributor who contributes to the project as part of their official duties at an Institutional Partner. Likewise, an Institutional Council Member is any Project Steering Council Member who contributes to the project as part of their official duties at an Institutional Partner. With these definitions, an Institutional Partner is any recognized legal entity in the United States or elsewhere that employs at least 1 Institutional Contributor of Institutional Council Member. Institutional Partners can be for-profit or non-profit entities. Institutions become eligible to become an Institutional Partner by employing individuals who actively contribute to The Project as part of their official duties. To state this another way, the only way for a Partner to influence the project is by actively contributing to the open development of the project, in equal terms to any other member of the community of Contributors and Council Members. Merely using Project Software in institutional context does not allow an entity to become an Institutional Partner. Financial gifts do not enable an entity to become an Institutional Partner. Once an institution becomes eligible for Institutional Partnership, the Steering Council must nominate and approve the Partnership. If an existing Institutional Partner no longer has a contributing employee, they will be given a 1 year grace period for remaining employees to begin contributing. An Institutional Partner is free to pursue funding for their work on The Project through any legal means. This could involve a non-profit organization raising money from private foundations and donors or a for-profit company building proprietary products and services that leverage Project Software and Services. Funding acquired by Institutional Partners to work on The Project is called Institutional Funding. However, no funding obtained by an Institutional Partner can override the Steering Council. If a Partner has funding to do NumPy work and the Council decides to not pursue that work as a project, the Partner is free to pursue it on their own. However in this situation, that part of the Partner’s work will not be under the NumPy umbrella and cannot use the Project trademarks in a way that suggests a formal relationship. Institutional Partner benefits are: - Acknowledgement on the NumPy websites, in talks and T-shirts. - Ability to acknowledge their own funding sources on the NumPy websites, in talks and T-shirts. - Ability to influence the project through the participation of their Council Member. - Council Members invited to NumPy Developer Meetings. Existing Institutional Partners: - UC Berkeley (Nathaniel Smith) Acknowledgements ================ Substantial portions of this document were ~~inspired~~ stolen wholesale from the Jupyter/IPython project's governance document, [IPEP 29](https://github.com/ipython/ipython/wiki/IPEP-29:-Project-Governance). -- Nathaniel J. Smith -- http://vorpus.org

2 3

testing numpy with downstream testsuites (was: Re: Notes from the numpy dev meeting at scipy 2015)
by Nathaniel Smith 26 Aug '15

26 Aug '15

[Popping this off to its own thread to try and keep things easier to follow] On Tue, Aug 25, 2015 at 9:52 AM, Nathan Goldbaum <nathan12343(a)gmail.com> wrote: >> - Lament: it would be really nice if we could get more people to >> test our beta releases, because in practice right now 1.x.0 ends >> up being where we actually the discover all the bugs, and 1.x.1 is >> where it actually becomes usable. Which sucks, and makes it >> difficult to have a solid policy about what counts as a >> regression, etc. Is there anything we can do about this? > > Just a note in here - have you all thought about running the test suites for > downstream projects as part of the numpy test suite? I don't think it came up, but it's not a bad idea! The main problems I can foresee are: 1) Since we don't know the downstream code, it can be hard to interpret test suite failures. OTOH for changes we're uncertain of we already do often end up running some downstream test suites by hand, so it can only be an improvement on that... 2) Sometimes everyone including downstream agrees that breaking something is actually a good idea and they should just deal, but what do you do then? These both seem solvable though. I guess a good strategy would be to compile a travis-compatible wheel of $PACKAGE version $latest-stable against numpy 1.x, and then in the 1.(x+1) development period numpy would have an additional travis run which, instead of running the numpy test suite, instead does: pip install . pip install $PACKAGE-$latest-stable.whl python -c 'import package; package.test()' # adjust as necessary ? Where $PACKAGE is something like scipy / pandas / astropy / ... matplotlib would be nice but maybe impractical...? Maybe someone else will have objections but it seems like a reasonable idea to me. Want to put together a PR? Asides from fame and fortune and our earnest appreciation, your reward is you get to make sure that the packages you care about are included so that we break them less often in the future ;-). -n -- Nathaniel J. Smith -- http://vorpus.org

4 3

SHA256 mismatch on SourceForge downloads
by Antoine Pitrou 26 Aug '15

26 Aug '15

Hello, The SourceForge download page for 1.10.0b1 mentions: 89e467cec774527dd254c1e039801726db1367433053801f0d8bc68deac74009 numpy-1.10.0b1.tar.gz But after downloading the file I get: $ sha256sum numpy-1.10.0b1.tar.gz 855695405092686264dc8ce7b3f5c939a6cf1a5639833e841a5bb6fb799cd6a8 numpy-1.10.0b1.tar.gz Also, since SouceForge doesn't provide any HTTPS downloads (it actually redirects HTTPS to HTTP (*)), this all looks a bit pointless. (*) seems like SourceForge is becoming a poster child of worst practices... Regards Antoine.

3 2

Python extensions for Python 3.5 - useful info...
by Fernando Perez 26 Aug '15

26 Aug '15

Just an FYI for the upcoming Python release, a very detailed post from Steve Dower, the Microsoft developer who is now in charge of the Windows releases for Python, on how the build process will change in 3.5 regarding extensions: http://stevedower.id.au/blog/building-for-python-3-5/ Cheers, f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail

1 0

py2/py3 pickling
by Chris Laumann 25 Aug '15

25 Aug '15

Hi all- Is there documentation about the limits and workarounds for py2/py3 pickle/np.save/load compatibility? I haven't found anything except developer bug tracking discussions (eg. #4879 in github numpy). The kinds of errors you get can be really obscure when save/loading complicated objects or pickles containing numpy scalars. It's really unclear to me why the following shouldn't work -- it doesn't have anything apparent to do with string handling and unicode. Run in py2: import pickle import numpy as np a = np.float64(0.99) pickle.dump(a, open('test.pkl', 'wb')) And then in py3: import pickle import numpy as np b = pickle.load(open('test.pkl', 'rb')) And you get: UnicodeDecodeError: 'ascii' codec can't decode byte 0xae in position 0: ordinal not in range(128) If you force encoding='bytes' in the load, it works. Is this explained anywhere? Best, C

4 5