|
| 1 | +# 2019-06-12 NumPy Development Meeting |
| 2 | + |
| 3 | +**Present:** Stéfan, Tyler, Ralf, Sebastian, Kriti, Hameer, Chuck, Matti, Robert |
| 4 | + |
| 5 | +## Follow-up from last meeting / discussions |
| 6 | +- Talk for SciPy2019 |
| 7 | + - We need data to show how the grant has affected the project |
| 8 | + - Tyler: I opened a [draft MR](https://gitlab.com/numpy/scipy2019-presentation-insidenumpy/merge_requests/2) for some git history metrics / plots, but needs improving / refinement, and doesn't touch the GitHub API like some of Nelle's stuff did |
| 9 | + - Nelle responded to a private mail and should provide some data soon |
| 10 | + - Talk so far is in [the repo](https://gitlab.com/numpy/scipy2019-presentation-insidenumpy)---note that this is a private repo |
| 11 | + - Long term sustainability of development (and continued funded development) is on our mind; Tyler is heading back to Los Alamos end of this week |
| 12 | +- 1.17 release upcoming: review PRs/Issues marked with [1.17 milestone](https://github.com/numpy/numpy/milestone/62). At last count there are 10 open PRs with the milestone, but none of them look critical to Tyler; maybe just start bumping issues at this point |
| 13 | + - Ralf wants [these two issues](https://github.com/numpy/numpy/pull/13019#issuecomment-467694625) brought up by Christoph Gohlke solved *before* 1.17, and Matti is working on them |
| 14 | +- [NEP template](https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst): needs to be updated to encourage better justification of changes, description of scope (motivation section: what, why, for whom, how); Any progress? |
| 15 | + - https://github.com/numpy/numpy/pull/13766 |
| 16 | +- Random generator work |
| 17 | + - How many BitGenerators to include: the general concensus is to include a minimum rather than a maximum, and to use PCG64 as the default. Matti will submit a PR to implement this decision. |
| 18 | + - Robert called in to highlight a few issues to take care of before the release: |
| 19 | + - A different API for seeding BitGenerators using SeedSeqObject - this would replace `seed` and `jumped`. The new API could live on the Generator and not the BitGenerator. |
| 20 | + - Independent stream handling infrastructure (better than `jumped`). |
| 21 | + - We have to decide on seeding mechanism before release, because this is public API. |
| 22 | + - Robert will start on this, it should be in the release, so we may need to wait for it a bit. |
| 23 | + - How many / which bit generators should be included by default? |
| 24 | + - Robert and Chuck favors minimal number; Mersenne Twister for legacy, and PCG64 :+1: |
| 25 | + - Another option proposed by Robert: only include what NumPy needs to be legacy compatible, and recommend that users go to SciPy (?) for other bit generators. Kevin's intent is not to maintain his RandomGen package (is this verified?). |
| 26 | + - MT19937: what do we want the constructor to do? The legacy version needs to maintain full stream compatibility, but we can use the new seeding algorithm otherwise. |
| 27 | + |
| 28 | +## Topics |
| 29 | + |
| 30 | +- [Weighted quantile PR](https://github.com/numpy/numpy/pull/9211) is still "stuck," and people have been commenting there recently again. We discussed this previously, but hard to move forward. |
| 31 | + - We will push this off till 1.18, maybe it needs a larger refactor including percentile? |
| 32 | + - might even be better suited to SciPy? |
| 33 | +- Are tests needed for [`histogram*d`](https://github.com/numpy/numpy/pull/13757) ? |
| 34 | + - Since this is a fix for array objects that implement `__array_function__` and use the dual behaviour of these functions, it is not clear that we can test it in NumPy itself. |
| 35 | + - Consensus is that we should merge it even without tests right now. |
| 36 | + |
| 37 | +## Additional Details |
| 38 | + |
| 39 | +- Tyler -- [weekly working notes](https://workflowy.com/s/june-12-2019/1aEL6bmb5TV3w3lK) |
| 40 | + |
| 41 | +- Matti |
| 42 | + - Still trying to resolve which BitGenerators should we |
| 43 | + include in random, [issue #13675](https://github.com/numpy/numpy/pull/13675) |
| 44 | + - learning numpy-wheels and associated repos |
| 45 | + - can we use docker on windows? |
| 46 | + - Will it make things simpler: |
| 47 | + - Ralf: no. |
| 48 | + - maybe a priority should be documentation and cleanup |
| 49 | + - allow builds on AzurePipelines |
| 50 | + - Ralf would like to see a gfortran / clang replacement for Windows |
| 51 | +- Sebastian |
| 52 | + - Start on PR to split think about simplifying dispatching in ufuncs https://github.com/numpy/numpy/pull/13736 |
| 53 | + - Discussion/mails to the list about promotion: |
| 54 | + - For myself tending towards "fixing" type hierarchy with uint7, etc. If it does not get too ugly, that should allow moving forward, etc. |
| 55 | +- Hameer |
| 56 | + - Someone seems interested in adding CSR/CSC to PyData/Sparse. Am trying to "rope them in". :smile: |
0 commit comments