Mailman 3 March 2022 - SciPy-Dev

Deprecate scipy.misc and Add scipy.datasets submodule
by Anirudh Dagar 07 Jan '24

07 Jan '24

Hi all, I just filed https://github.com/scipy/scipy/pull/15607 after an offline discussion with Ralf earlier this month. The summary of that PR is: This is a good time to get rid of the `scipy.misc` submodule since it houses only a handful of functions. As of today, most of the methods have already been deprecated from the `misc` module. They have generally moved under some other submodule. In this case, it is best to create a `scipy.datasets` submodule that can be home to the dataset functions (ascent, face, ecg). Adding a datasets submodule is not a new idea, and was proposed a couple of years ago by Warren (see https://github.com/scipy/scipy/pull/8707), but unfortunately, it never went ahead. Adding this submodule is not only sensible from an organizational/structural point of view but will also help reduce the wheel size of SciPy package. This is possible if we decouple the dataset files from the SciPy repository making use of Pooch to download and cache datasets kept in separate repos. See the PR for more details. I also filed https://github.com/scipy/scipy/issues/15608 Out of the 5 methods in `scipy.misc`, three dataset functions can be moved to this datasets submodule and will slowly be deprecated from misc. The question about the other two methods i.e (derivative, central_diff_weights) is up for discussion and I'd like to understand what will be the best way to deprecate them. Should we move them to a submodule like integrate (keeping derivative makes sense to me)? On the other hand, considering these two methods are not used extensively so one possibility is to deprecate both of them completely and remove them from SciPy. Please share your opinion/concerns, and comment if you see a potential issue with this. Cheers, Anirudh

4 10

New feature: fitting distributions to censored data.
by Warren Weckesser 29 Aug '22

29 Aug '22

Hey folks, A new enhancement for fitting probability distributions to censored data by maximum likelihood estimation is in progress in https://github.com/scipy/scipy/pull/13699 This is a feature in the statistics roadmap, and is part of the work for the CZI EOSS cycle 1 grant. Censored data is data where the true value of the measurement is unknown, but there is a known bound. The common terminology is: * left-censored: The true value is greater than some known bound. * right-censored: The true value is less than some known bound. * interval-censored: The true value is between known bounds. (By allowing the bounds to be +inf and -inf, we can think of all these cases as interval-censored.) In the PR, a new class, `CensoredData`, is defined to represent censored data. The `fit` method of the univariate continuous distributions is updated to accept an instance of `CensoredData`. The `CensoredData` class constructor accepts two arrays, `lower` and `upper`, to hold the known bounds of the data. (If `lower[i] == upper[i]`, it means that data value is not censored.) Because it is quite common for data to be encountered where the only censored values in the data set are either all right-censored or all left-censored, two convenience methods, `CensoredData.right_censored(x, censored)` and `CensoredData.left_censored(x, censored)`, are provide to create a `CensoredData` instance from an array of values and a corresponding boolean array that indicates if the value is censored. Here's a quick example, with data from https://www.itl.nist.gov/div898/handbook/apr/section4/apr413.htm. The data table shows 10 regular values and 10 right-censored values. The results reported there for fitting the two-parameter Weibull distribution (location fixed at 0) to that data are shape = 1.7208 scale = 606.5280 Here's the calculation using the proposed API in SciPy: In [55]: from scipy.stats import weibull_min, CensoredData Create the `CensoredData` instance: In [56]: x = np.array([54, 187, 216, 240, 244, 335, 361, 373, 375, 386] + [500]*10) In [57]: data = CensoredData.right_censored(x, x == 500) In [58]: print(data) CensoredData(20 values: 10 not censored, 10 right-censored) Fit `weibull_min` (with the location fixed at 0) to the censored data: In [59]: shape, loc, scale = weibull_min.fit(data, floc=0) In [60]: shape Out[60]: 1.720797180719942 In [61]: scale Out[61]: 606.527565269458 Matt Haberland has already suggested quite a few improvements to the PR. Additional comments would be appreciated. Warren

4 7

proposal to use SciPy project funds for build and CI improvements
by Ralf Gommers 13 Apr '22

13 Apr '22

Hi all, I'd like to make a proposal to use some project funds to make faster progress on moving to a new build system and improving our CI timeout issues. Because this is the first such proposal, let me first deal with the meta issue of _how_ to deal with this. At the start of the year I co-wrote NEP 48 (https://numpy.org/neps/nep-0048-spending-project-funds.html) to have a framework for NumPy for spending project funds. I'd like to follow that NEP also for SciPy. So I'll make the proposal here, in accordance with that NEP, and then the other thing is to figure out where to put it up as a PR (or wiki page, or ...). For that my proposal is: create a new repo called something like `project-mgmt`, where we can put such proposals as well as meeting minutes, presentations, and other content. And have a single summary page in Markdown format with a list of all proposals made, linking out to the full proposals. On to the actual proposal, keeping in mind https://numpy.org/neps/nep-0048-spending-project-funds.html#defining-fundab… . Title: Accelerating the move to Meson as the SciPy build system Cost: $12,000 Time duration: 3 months Team members: Matthew Brett (funded), Ralf Gommers (unfunded), Gagandeep Singh (unfunded), Smit Lunagariya (funded) Context: 1. Multiple people recently told me that our current build system and CI issues are a pain point for working on SciPy. We have CI timeouts on our main repo, scipy-wheels is a pain, conda-forge is also timing out on aarch64 and ppc64le build. And I've found myself spending a whole day or weekend several times in the past months to fix broken CI jobs due to build/packaging issues. 2. About 4 months ago, I wrote an RFC to move to Meson as a build system, see https://github.com/scipy/scipy/issues/13615. Since then I have spent a lot of time on this, and also used Quansight Labs funding to get one of my colleagues, Gagandeep Singh, to help me move this forward faster (and he has been super helpful). Getting a Linux + OpenBLAS dev build is close to done (16 of 20 modules complete, all that's left is `misc`, `io`, `integrate` and `signal` - probably those can be completed in the coming week). 3. Doing everything else, like adding support for Windows/aarch64/MKL/ILP64/etc. is still a lot of work. There's a tracking issue at https://github.com/rgommers/scipy/issues/22. Some of this stuff is pretty specialized, e.g., building wheels, and Fortran-on-Windows. It will take a long time to complete if it's just me spending time on the weekends. 4. Matthew Brett is available to help soon. He has written multibuild and dealt with build/packaging topics for a long time, so I think he would be able to make progress quickly. He wants to work on this topic as an independent contractor (I won't add rates here, that's for the core team to look at - but they're very reasonable). The overall goals of this effort are: 1. Get a (mostly) feature-complete Meson based build system in place by the end of October, so we can ship it in the 1.8.0 release. If all goes well, get rid of the `numpy.distutils` based build 1 release later. 2. Resolve all our CI timeout issues. If the build system alone isn't enough (it should be though), analyze the remaining issues and figure out how to tackle whatever is still problematic. The deliverables are, in order of priority: 1. Add capability to build release artifacts (wheels, sdist). I did some initial tests at the start with mesonpep517, but I have no idea if it works for SciPy and what bugs are lurking there. 2. macOS support 3. Add support for things we need to a dev.py interface (basically, like runtests.py in that it can do everything, like building docs, running benchmarks, etc.) 4. Contribute a few things we need, or that would make the build setup better, to Meson. For example, I think we'd want to be able to use `py3.install_sources` on generated targets. Of course I'm still new-ish to Meson, so it could well be that after making a proposal on the Meson issue tracker, another solution will be preferred. 5. Windows support 6. Improve build dependency detection and configuration - in particular BLAS/LAPACK flavors. 7. Clean up as many build warnings as possible, and silence the rest. The goal is to have a CI job that is completely silent (passes with `-Werror`). 8. Optimize build time further, including on CI (e.g., reuse build cache between jobs). I'd like to use 75% of the funds to pay Matthew, and 25% of the funds to take on a talented intern, Smit Lunagariya. He is comfortable working in Python, C and C++, and will be able to help with deliverables 7 and 8, as well as with testing and other tasks. Overall I'm not certain that this amount of funds is enough to complete every last deliverable on this list; it's hard to estimate. But we should certainly get close, and be able to ship a Meson build in 1.8.0. For a quick sketch of the benefits: - On my machine the build time is currently 13 minutes with numpy.distutils and 90 seconds with Meson - The build log goes from >10,000 lines (mostly noise) to ~100 lines (mostly configuration info). Why should this be a funded activity? For two reasons: (1) build and CI issues are probably the number one maintenance issue we have, and (2) most people find working on build/CI boring and painful, and hence it doesn't happen with volunteer-only activities. Even regular maintenance of our CI is hard - recently jobs have been broken for 1-2 weeks at a time a couple of times. And the scipy-wheels repo is in even worse shape. My proposal is to designate this topic as high priority, let the core team approve the compensation levels for the funded people, and get the work started. For reporting on progress and to have some accountability about how we spent the funds, I propose a short report (say 1 page, giving a status update and linking the main PRs made or issues closed) when half the funds are spent, and another such report at the end. In addition I'll plan to write a small development grant for this when the next call for that opens up, because I think we want Matthew to continue working on this after this $12,000 has been spent. I'd like to get everything as good as it can be, so other projects can easily adopt Meson as well - to also achieve my not-so-secret goal of not having to integrate numpy.distutils capabilities into setuptools once distutils is removed from Python. Thoughts? Cheers, Ralf

5 6

Bump minimum required LAPACK/BLAS version to 3.7.1
by Ilhan Polat 09 Apr '22

09 Apr '22

Dear all, As discussed in [1] and elsewhere extensively for the past roadblocks we have encountered, it finally seems like we can bump the minimum required LAPACK/BLAS version to 3.7.1. A preliminary search over the major Linux distros show that CentOS 7 and OpenSUSE Leap are the only ones that doesn't come with the liblapack with version number lower than 3.7.1. Windows and OSX can already use whichever version they need. However this doesn't mean that these systems are not going to be supported. For building SciPy you would need OpenBLAS/MKL anyways and those are independent from the system-wide liblapack machinery. Thus it doesn't seem like a roadblock. Many SciPy users who install pip or conda way don't even notice this but I would like to probe for a reason which this bump might cause an issue in some edge-case system. In turn this will finally allow us to get rid of past version issues and to get rid of certain legacy code. Please share your thoughts, Best, ilhan [1] https://github.com/scipy/scipy/issues/5266

2 1

SciPy Community Meeting on Wed, Feb 16 at 8PM UTC
by Melissa Mendonça 30 Mar '22

30 Mar '22

Hello, all! The next SciPy Community Meeting will happen this week, on* Wednesday February 16, at 8 pm UTC*. Here's the hackmd we are using to take notes: https://hackmd.io/pyhudrC5TgSwdJtpPldHgQ If you wish to join on Zoom, use this link: https://us06web.zoom.us/j/6345425936 Cheers, Melissa p.s. Here's a handy link where you can get the meeting time in your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=SciPy+Community+M… <https://www.timeanddate.com/worldclock/fixedtime.html?msg=SciPy+Community+M…>

3 5

Add QMCEngine.integers
by Pamphile Roy 28 Mar '22

28 Mar '22

Hi everyone, In https://github.com/scipy/scipy/pull/15865 <https://github.com/scipy/scipy/pull/15865> I propose to add a function to sample integers from any QMCEngine. The interface is similar to NumPy’s np.random.Generator.integers with the difference that the bounds are not named the same. This is because in the QMC submodule we have scale which use another convention. I could modify both to match: high, low from NumPy if wanted. (Using the deprecation wrapper from Matt in scale then). While the function is very simple, it’s also a way to tell the user that it does work like that with QMC and you would not lose convergence properties. We also discussed the possibility to add a parameter `integrality` to QMCEngine.random (or create another function) to be able to do mixed sampling: integers or floats on some dimensions. This PR does not do anything in that regard and we need to discuss more the API. If you have any ideas, that would be great. You are welcome to join the discussion :) Cheers, Pamphile

1 0

Extend MINRES to solve complex symmetric systems
by 赵刚 28 Mar '22

28 Mar '22

Dear all, I submitted a PR (#15838) where MINRES is extended to solve complex symmetric systems https://github.com/scipy/scipy/pull/15838 Generally, MINRES is an important linear iterative method for real symmetric problems and Hermitian problems. In the original code, MINRES only supports the solution of real symmetric systems. Now, MINRES is also provided for solving complex symmetric equations. Welcome to review this PR and discuss it together. Hope you like it, thanks. Best Regards, Gang (zhaog6)

1 0

Fit `nbinom` with integer or real `n`?
by Matt Haberland 28 Mar '22

28 Mar '22

Hi team, Now that `scipy.stats.fit` is available to fit distributions with integer parameters, there is sometimes a question of whether a parameter should be restricted to integers or not. For instance, the parameter `n` of the negative binomial distribution is implemented (meaningfully) for non-integer `n`, but whether this is desirable is context-dependent. Users might wish for `fit` to find the best integer `n`, or they might want the best real `n`. Currently, `fit` relies on information defined for each distribution to determine which parameters are integral and which or not, so two options stand out. * Add an option (e.g. `integrality`) to `fit` that would allow the user to override the default for any parameter of any distribution. * Define separate distributions - one version which would accept reals for the parameter and one which would accept only integers. I'd prefer not to complicate the `fit` API if this isn't a very common need, and I think it would be slightly easier to add separate distributions if there are only a few of these cases. ("Pascal" is a pretty standard name for the negative binomial distribution with an integer restriction, for instance.) But I thought I'd ask the list before submitting a PR either way. If you have an opinion, please join the discussion in gh-15769. ( https://github.com/scipy/scipy/pull/15769) Thanks! Matt -- Matt Haberland Assistant Professor BioResource and Agricultural Engineering 08A-3K, Cal Poly

1 0

Google Season of Docs
by Melissa Mendonça 25 Mar '22

25 Mar '22

Hi all! I wrote drafts for both the NumPy and SciPy projects for Google Season of Docs. You'll notice they are very similar - the Google person responsible for the program suggested this may have a better chance of success instead of sending one proposal for the two projects. Here they are for review and feedback: NumPy: https://hackmd.io/@melissawm/r1yuKepbc SciPy: https://hackmd.io/@melissawm/HJqey27f9 The deadline for submission is March 25th. Feel free to add comments, corrections and suggestions. Thanks! - Melissa p.s. If you are interested in being a mentor (or co-mentor), please reach out so I can list you in the project.

2 2

Change definition of stats.circvar to the one agreed upon in the literature?
by Matt Haberland 22 Mar '22

22 Mar '22

Hi team, In circular statistics, the conventional definition of variance is not the square of the standard deviation. The definition of circular variance originally implemented in SciPy was the one agreed upon by the literature, but it was changed without technical review somewhere along the way. I've revived gh-5747 (https://github.com/scipy/scipy/pull/5747), which intends to revert the change in definition. The main question is whether this should be considered a correction, which might not require a deprecation, or if we need to maintain backward compatibility for the nonstandard definition, which has been part of SciPy for 10 years. If there are no concerns, the plan would be to merge the PR as a bug fix and announce the backward incompatibility in the release notes. I'd appreciate your feedback! Thanks, Matt -- Matt Haberland Assistant Professor BioResource and Agricultural Engineering 08A-3K, Cal Poly

1 0