Mailman 3 July 2020 - NumPy-Discussion

Numpy FFT normalization options issue (addition of new option)
by cvav July 12, 2020

July 12, 2020

Issue #16126: https://github.com/numpy/numpy/issues/16126 PR #16476: https://github.com/numpy/numpy/pull/16476 numpy.fft docs (v1.18): https://numpy.org/doc/1.18/reference/routines.fft.html Hello all, I was advised to write on the numpy mailing list, after this week's community meeting led to some general discussions on the normalization schemes used in the FFT functions. My post has to do with issue #16126, which asks for the addition of a new option for the "norm" argument for the FFT functions; "norm" controls the way the forward (direct) and backward (inverse) transforms are normalized, and the two currently supported options are "norm=None" (default) and "norm=ortho". The "ortho" option uses the orthonormal Fourier basis functions, which translates to both the forward and backward transforms being scaled by 1/sqrt(n), where n is the number of Fourier modes (and data points). The default "None" option scales the forward transform by 1 (unscaled) and the backward by 1/n. The new added option, called for now "norm=inverse", is the exact opposite of the default option; i.e. it scales the forward transform by 1/n and the backward by 1. In terms of using the FFT for spectral methods or approximation problems, these are the three scaling schemes one encounters; the transform itself is the same, with only a constant factor being the difference. But having all three scaling options built in the fft and ifft functions makes the code cleaner and it's easier to stay consistent. I've submitted a PR for this change, and would be happy to get comments and feedback on the implementation and anything else that hasn't been considered. Thanks! Chris -- Sent from: http://numpy-discussion.10968.n7.nabble.com/

10 14

Collection of Questions for Explanations
by Saber Tooth July 11, 2020

July 11, 2020

Hi Mentors , In the last Docs meeting , we discussed about Explanations and ways we could use to gather relevant topics for which we could provide explanations . The light was shed upon mining of questions firstly from numpy communities via Discussion like groups , then move to other sources . We can mine such topics from the NumPy community via mining email threads of numpy-discussion(a)python.org for Questions . Apart from doing this I am thinking of opening an issue , the track of which will be kept by me and other contributors if they wish . We can write relevant topics for explanations over there . The link to this issue can be shared with numpy-discussion(a)python.org and other NumPy community forums , where contributors can comment their questions or queries which they wish to get documented . This way we can avoid multiple Github issues by using one Github issue , moreover this issue will populate queries from the community which will be visible to everyone and may give rise to ideas regarding explanations which we haven't thought about , in fact we can close other such issues later by moving their queries to this issue . In this manner we can have enough data within a month or two to document an Explanations page . Then we could frame explanations from this pool of data in this single Github issue , Do suggest your ideas/advice for the following and also if we should be doing something else . Thanks , Mrinal Tyagi

2 3

NumPy Sprint on the weekend
by Sebastian Berg July 10, 2020

July 10, 2020

Hi all, since there is the SciPy sprints going on we will also be joining the event and sprinting as well. The kickoff for the SciPy sprint session is at 9:00 CST (7:00 PST, 16:00 CET), with the start of the sprints around 9:30. We are gathering all information at the hackmd: https://hackmd.io/r4pcf4CQRMOUY2VXOWk5_Q so that we can be flexible with organization (e.g. which video software to use). Note that attendance may pick up only a few hours later, but we will try to be around most of the time. Currently, we have a few documentation fixed listed to be worked on, but it will be a good time to just chat or ask for help setting up a getting started. Another bigger topic is website translations, but more will be added certainly and input is welcome! If you plan on coming, feel free to write yourself into the hackmd so that we know when you are going to be around. Hope you drop in, if just to say hi! Cheers, Sebastian

1 0

NumPy Documentation Gallery structure
by Saber Tooth July 8, 2020

July 8, 2020

Hello Melissa and Ralf , I was just wondering if we haven't had much discussion on the structuring of tutorials , while we have had some discussion on Explanations . I have been analysing the Tutorials of some other communities too , say Matplotlib : they have basically structured the tutorials page like a Gallery where examples have been arranged in the order of experience level . Link to Matplotlib tutorials : https://matplotlib.org/3.2.2/tutorials/index.html Here is SunPy Documentation. They have tried to structure their How-TO examples in the same way like a Gallery . Link to SunPy Gallery Examples : https://docs.sunpy.org/en/v2.0.1/generated/gallery/index.html# Please have a Look , maybe we can also get some new ideas for our Documentation . I think it will help us to structure the Tutorials page of NumPy too . Thanks , Mrinal Tyagi

3 3

NumPy Community Meeting Wednesday
by Sebastian Berg July 7, 2020

July 7, 2020

Hi all, There will be a NumPy Community meeting Wednesday July 8th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

GSoD application technical limitations
by Saber Tooth July 7, 2020

July 7, 2020

Hello Melissa , Today I was writing my GSoD proposal application , while I tried to copy / paste my exact Google docs proposal in the application description , but even after clearing all the formatting , the application form is stating that the " response is too large , try shortening some answers " Now many people have complained regarding this issue on the season of docs channel , so it means the issue is upsetting everyone . So I wanted to request if it's fine I also mention the link to my google docs Proposal where it is explained in much more detail. In application I have almost shortened half of my proposal therefore it has started to lose its minute explanatory details . Thanks , Mrinal Tyagi

2 1

Parlez-vous français?
by Inessa Pawson July 6, 2020

July 6, 2020

As most of you know, the inaugural NumPy community survey <https://umdsurvey.umd.edu/jfe/form/SV_8bJrXjbhXf7saAl> is currently underway. Fabrice Silva kindly offered his help to translate the survey questionnaire into French to maximize the participation of NumPy users and developers from the French-speaking countries. He has already completed his part of the translation (in less than 24 hours!). We are looking for another French-speaking volunteer to finalize the translation process of this document. If you are available, please email me at inessa(a)albuscode.org. -- Every good wish, Inessa Pawson NumPy survey team inessa(a)albuscode.org

1 0

ANN: SciPy 1.5.1
by Tyler Reddy July 4, 2020

July 4, 2020

Hi all, On behalf of the SciPy development team I'm pleased to announce the release of SciPy 1.5.1, which is a bug fix release. Sources and binary wheels can be found at: https://pypi.org/project/scipy/ and at: https://github.com/scipy/scipy/releases/tag/v1.5.1 One of a few ways to install this release with pip: pip install scipy==1.5.1 ========================== SciPy 1.5.1 Release Notes ========================== SciPy 1.5.1 is a bug-fix release with no new features compared to 1.5.0. In particular, an issue where DLL loading can fail for SciPy wheels on Windows with Python 3.6 has been fixed. Authors ======= * Peter Bell * Loïc Estève * Philipp Thölke + * Tyler Reddy * Paul van Mulbregt * Pauli Virtanen * Warren Weckesser A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. This list of names is automatically generated, and may not be fully complete. Issues closed for 1.5.1 -------------------------------- * `#9108 <https://github.com/scipy/scipy/issues/9108>`__: documentation: scipy.spatial.KDTree vs. scipy.spatial.cKDTree * `#12218 <https://github.com/scipy/scipy/issues/12218>`__: Type error in stats.ks_2samp when alternative != 'two-sided- * `#12406 <https://github.com/scipy/scipy/issues/12406>`__: DOC: Docstring in stats.anderson function not properly formatted * `#12418 <https://github.com/scipy/scipy/issues/12418>`__: Regression in hierarchy.dendogram Pull requests for 1.5.1 -------------------------------- * `#12280 <https://github.com/scipy/scipy/pull/12280>`__: BUG: Fixes gh-12218, TypeError converting int to float inside... * `#12336 <https://github.com/scipy/scipy/pull/12336>`__: BUG: KDTree should reject complex input points * `#12344 <https://github.com/scipy/scipy/pull/12344>`__: MAINT: Don't use numpy's aliases of Python builtin objects. * `#12407 <https://github.com/scipy/scipy/pull/12407>`__: DOC: Fix docstring for dist param in anderson function * `#12410 <https://github.com/scipy/scipy/pull/12410>`__: CI: Run the Azure Windows Python36 32bit tests with mode 'fast' * `#12421 <https://github.com/scipy/scipy/pull/12421>`__: Fix regression in scipy 1.5.0 in dendogram when labels is a numpy... * `#12462 <https://github.com/scipy/scipy/pull/12462>`__: MAINT: move distributor_init import after __config__ import Checksums ========= MD5 ~~~ b71e8115d61c604cc65e5ecc556131f6 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 0190c11f75ed28a7e56050182ca95a18 scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl c4dd717a3a0c3fe64380039e4fda663f scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl baad02c954e85e7fd3d4a9fd49fc6359 scipy-1.5.1-cp36-cp36m-win32.whl 9edc3a9aedf6bffccb17101c905126d0 scipy-1.5.1-cp36-cp36m-win_amd64.whl 83479a6de66a6bc2da0990fa71cf3cec scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl f2d5c8713b087545c5ec19cc8e46212c scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl 6a18a9636342574ae55d3a80136c550c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 5da68faf5b32c539d1cb5390df010cc8 scipy-1.5.1-cp37-cp37m-win32.whl 2ca8c59a6712e91ac78b8540ab694b53 scipy-1.5.1-cp37-cp37m-win_amd64.whl cceb059d0cf6a70e62452deb5571ba00 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 8a65b30ccd72409704d3300922da2b7f scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 00181f52a7917d1c3d50e42a76a6df96 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 2aa8b6ddceaebe7b33d71dbad0e208cc scipy-1.5.1-cp38-cp38-win32.whl a626585d08b0991c8f2df0caacdf9997 scipy-1.5.1-cp38-cp38-win_amd64.whl f6986798b7d22ffc5f80b749d7ec27ca scipy-1.5.1.tar.gz e126a1a0ff954b924a8273faa7437fe3 scipy-1.5.1.tar.xz 3bce82b23d45d1a96ee270f23176746a scipy-1.5.1.zip SHA256 ~~~~~~ 058e84930407927f71963a4ad8c1dc96c4d2d075636a68578195648c81f78810 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl 7908c85854c5b5b6d3ce7fefafac1ca3e23ff9ac41edabc2d46ae5dc9fa070ac scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl 8302d69fb1528ea7c7f2a1ea640d354c981b6eb8192d1c175349874209397604 scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl 35d042d6499caf1a5d171baed0ebf01eb665b7af2ad98a8ff1b0e6e783654540 scipy-1.5.1-cp36-cp36m-win32.whl 5e0bb43ff581811ab7f27425f6b96c1ddf7591ccad2e486c9af0b910c18f7185 scipy-1.5.1-cp36-cp36m-win_amd64.whl b4858ccbd88f4b53950fb9fc0069c1d9fea83d7cff2382e1d8b023d3f4883014 scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl eb46d8b5947ca27b0bc972cecfba8130f088a83ab3d08c1a6033d9070b3046b3 scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl fff15df01bef1243468be60c55178ed7576270b200aab08a7ffd5b8e0bbc340c scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl 81859ed3aad620752dd2c07c32b5d3a80a0d47c5e3813904621954a78a0ae899 scipy-1.5.1-cp37-cp37m-win32.whl c05c6fe76228cc13c5214e9faf5f2a871a1da54473bc417ab9da310d0e5fff8b scipy-1.5.1-cp37-cp37m-win_amd64.whl 71742889393a724dfce755b6b61228677873d269a4234e51ddaf08b998433c91 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl 9323d268775991b79690f7b9a28a4e8b8c4f2b160ed9f8a90123127314e2d3c1 scipy-1.5.1-cp38-cp38-manylinux1_i686.whl 06b19a650471781056c1a2172eeeeb777b8b516e9434005dd392a4559e0938b9 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl 57a0f2be3063dbe1e3daf31ec9005576e8fd1022a28159d0db71d14566899d16 scipy-1.5.1-cp38-cp38-win32.whl c06e731aa46c0dfc563cc636155758178ebc019ef78b9b0f4370effe2ac0f0e6 scipy-1.5.1-cp38-cp38-win_amd64.whl 039572f0ca9578a466683558c5bf1e65d442860ec6e13307d528749cfe6d07b8 scipy-1.5.1.tar.gz 0728bd66a5251cfeff17a72280ae5a40ec14add217f94868d1415b3c469b610a scipy-1.5.1.tar.xz 6dfa9d1e718588f48731e865674b3270130f7736d6c7dc5ceaeb048f55ed793a scipy-1.5.1.zip

1 0

reseed random generator (1.19)
by Neal Becker July 4, 2020

July 4, 2020

Consider the following: from numpy.random import default_rng rs = default_rng() Now how do I re-seed the generator? I thought perhaps rs.bit_generator.seed(), but there is no such attribute. Thanks, Neal -- *Those who don't understand recursion are doomed to repeat it*

5 16

Google Summer of Docs Faq and Tutorial Proposed Structure .
by Ben Nathanson July 4, 2020

July 4, 2020

Let me first say I'm a volunteer and not a member of the group that will evaluate proposals. But I can tell you how I would choose. A right-sized proposal is stronger than an overambitious one. I'd scale back and pick a single target. From your listed experience, this would be your first significant docs work. Before you can overhaul an entire site, you need to get a feel for the pace of the work. The review process alone guarantees the site can't be transformed in three months. For argument's sake, let's say you focus on mining the internet for how-to subjects. This is not a bad GSoD idea, because it's open-ended: No matter how fast you write, you'll never exhaust the supply of topics, and if work proceeds more slowly than you'd hoped, you will have established a methodology, and any how-tos we get are more than we have now. Apart from appropriate scope, a proposal needs credibility. GSoD tech writers are a coveted resource, so a project wants to be confident that the writer they pick will deliver the goods. We're scientists and engineers, yourself included, so we look for evidence. Put evidence in your proposal. Assuming you pick how-tos, show the NumPy team how thoroughly you've considered the issues, explain your methodology and its strengths and shortcomings, and, most importantly, give samples of how-tos you've transformed. It's like a job interview, but harder: Not only do you have to provide the answers, you have to anticipate the questions. Does that mean you have to do work upfront that you might do during GSoD? Yes. You're staking capital. The more you put on the table, the more confident the team can be in your sincerity and skill. That said, you do stand to lose it all if someone else is chosen. That can happen even if you send in a proposal that everyone agrees looks good. Your effort will not be a waste; you'll have developed skill in drafting a competitive proposal -- useful in grant writing, calls for papers, and next year's GSoD. Again, this is peer review, not official guidance. And to be clear, I myself am not participating in GSoD; I thought I might but chose instead to simply volunteer.

1 1