Mailman 3 October 2021 - SciPy-Dev

New feature: fitting distributions to censored data.
by Warren Weckesser Aug. 29, 2022

Aug. 29, 2022

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 April 13, 2022

April 13, 2022

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

Re: [SciPy-Dev] Sensitivity analysis module proposal (Robert Kern)
by Pamphile Roy Nov. 29, 2021

Nov. 29, 2021

Hi all, First things first, there are too many things to discuss and email is not appropriate. I propose to make a call with people interested next week or the week after. Let me know if we can do this and what time would work so I can put together a doodle. Some replies on specific points: Let me preface this by saying that I am not gaining anything from working on SciPy. I have no project related to SA at the moment and nothing is planned. I am only giving some personal time and have zero financial support for my time. SALib into SciPy: I proposed this following your input Robert. You said that if the maintainers of this library would be willing to do so, then we could discuss. I am very happy to see that they would actually be willing to do this and help. Funding: I can only disagree. Yes, being part of SciPy does not open directly a line of credit, but it does indirectly help. Art Owen already told me that he is using the fact that he helped us on stats.qmc to get some fundings. And I am certain some of us also use this with their current employers. Bus factor: We are way pass the bus factor. There is the team behind SALib, me, and I already got interest from people like Sergei Kucherenko (one of the pillar of SA). And if we go that way, I am 100% sure Saltelli (another pillar) will be interested (I worked with him on a tooling project). People like them are willing to contribute only because it’s SciPy. We had this discussion at MCM2021 when I presented SciPy’s QMC module to the QMC community. Researchers, at least from the communities I know and talked with, do not want to contribute to something that is uncertain or linked to a particular group. With SciPy they see an opportunity to have a large impact across a wide range of fields. And also it’s the assurance to have a long term impact. Why SA? How is this important? SA is becoming a major field. Not only by itself, but other fields are starting to use its methods. Things like Shapley values in AI, importance factor, etc. In most engineering field, it’s now mandatory to assess uncertainties. Hence there is a real need for tooling. There are mature libraries in the field. OpenTURNS, UQLab and Dakota are the most used among practitioners. And they are all not independent and open as we are (explains partially why people like Sergei or Saltelli are not contributors). I will not go here about why I think these library should not be used. I really don’t get the push back on this one. It’s about adding a few method in stats at most and the benefits would be arguably huge compared to some functions/sub modules we added recently. Behind it, there would be the most renown people of the field and that could give another great exposure for SciPy. We will talk of SciPy at new conferences, etc. My presentation of QMC had a great impact in the QMC community. I had 4 concrete proposal of collaboration just during the conference. We went from not being in one field to be the recommended tool by a community. SciPy is at the foundation of the scientific ecosystem in Python and not having basic tooling a about uncertainty/SA that other higher lever packages could rely on is a puzzle for me. As I said at the beginning, let’s have a talk to decide what’s in the best interest of SciPy. Cheers, Pamphile > On 3 Sep 2021, at 03:35, Robert Kern <robert.kern(a)gmail.com> wrote: > > >> On Thu, Sep 2, 2021 at 3:30 PM William Usher <wusher(a)kth.se> wrote: > >> Hi Robert, >> >> Thanks for the response. You raise good points. >> >>>> Obviously, that you are interested in the proposal assuages some of that, but I'm still unclear on why you are interested in this. What is the benefit that you think everyone will get by absorbing SALib into scipy? It still looks to me like a mostly-lateral move that will merely be disruptive to your dependent projects more than anything else. >> >> The real value of SALib is in providing a consistent interface to a (large) suite of sensitivity analysis methods which allows users to easily switch between those methods. >> >> We (as maintainers) could benefit from reducing duplication of code and implementations, such has Sobol’ sequence generation, LHS, and could contribute some of the more general sample generation implementations where appropriate (many are linked directly to the SA implementations and not useful outside of that). > > I definitely think anything that could plausibly fall in the purview of scipy.stats.qmc would be a good target for convergence. If you can't use scipy.stats.qmc due to missing functionality (and not just that you don't want to require that recent version of scipy), then let's see how we can shore it up. I think that where your sampling methods overlap with design of experiments in general might also be a fruitful place for scipy.stats to grow/absorb some community-wide functionality. > >> We think the scientific community as a whole would benefit from the greater exposure a SciPy implementation of SA would bring - as a large community-led effort - it could provide a neutral forum for further development of these methods. This would likely come at some “cost” to the successful “cottage industry” we’ve established and grown (SALib is getting lots of citations and use). > > That is gold. I am having trouble understanding why you would contemplate anything that might place that at risk. If I were dictator here, I would reject you out of hand for your own good. ;-) > >> I think a key argument against integration is that it may reduce the agility with which we can add new methods to our SA suite (although this could be mitigated with careful design). >> >> I think you raise an important point about our dependent projects, and particularly how we would continue to support legacy releases if developer resources were focussed on a SciPy integration? >> >> An attraction is the possibility of funding to support the development of SA within SciPy. Like all open-source projects, we suffer from resourcing issues, and are predominantly volunteer-driven from the academic community. And while we are technically a “multi-developer” community, we’re only a few bus accidents (or career changes) away from being a lone-maintainer. > > > That's more required bus accidents than many parts of scipy. :-) > > I'm afraid that contributing into scipy doesn't unlock a pot of funds. I'm out of the grant-writing game, but I suspect that the difference between applying for funds on your own and arguing for allocation from competing needs inside of scipy is mostly a push. Have you considered applying to NumFocus? I occasionally look at their accepted and rejected projects, and I'd lump you in with the former, IMO. You're doing important work, playing well with other projects in the ecosystem, and have at least the seed kernel of sustainable community development so that funds are likely to actually sustain development. > > -- > Robert Kern > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev(a)python.org > https://mail.python.org/mailman/listinfo/scipy-dev

4 7

Request to work on Object-oriented design of digital filtering in scipy.signal
by Dhruv Vats Nov. 27, 2021

Nov. 27, 2021

Hello, My name is Dhruv Vats, and I'm in the final year of my engineering studies, majoring in Electronics and Communications. While browsing the GSoC ideas page of SciPy, I came across this <https://github.com/scipy/scipy/wiki/GSoC-2021-project-ideas#object-oriented…> project, which, from what I checked, went unallocated this year. The project lists Digital Signal Processing as a requirement, and while my coursework (DSP, Communications Systems, Control Theory, etc.) has given me a decent familiarity with the subject, I further got to use its concepts during my GSoC project this year <https://summerofcode.withgoogle.com/projects/#5521109757198336>, which involved investigating, implementing and integrating the DPSS multitaper periodogram into Stingray <https://github.com/StingraySoftware/stingray>, using scipy.signal at its core. Therefore, if the context is correct, I would like to request permission to work on this and would love the opportunity to further discuss the project, such as, - What the first steps should be? - What parts of code should I start looking at? - How can it be divided into smaller, more manageable tasks? - What the result could look like? (A brief description is provided on the ideas page.) And most importantly, - How do *you* guys see this coming together? This is my first time posting to the mailing list, so hoping it wasn't too blunt. Humble regards, Dhruv Vats

8 8

Questions/suggestions for bootstrap docs
by Jesse Livezey Nov. 2, 2021

Nov. 2, 2021

Hi all, I was trying to use the scipy.stats.bootstrap function and wasn't sure that I was understanding the format of the `data` argument. Happy to make a PR if I'm understanding things correctly and can improve the docs. The docs say: > Each element of data is a sample from an underlying distribution. I think I'm confused about what the elements of `data` mean versus the dimension of the arrays that make up the iterable `data`. It's also not clear which things are assumed to be a "sample from an underlying distribution", e.g., each element of `data` or the elements of the arrays in `data`. Based on the examples, it seems like bootstrap can be used in these scenarios - A 1d array of data, x, with a statistic that takes a single argument like `np.mean`. In this case, data=(x,) - A set of (paired) 1d arrays of data, (x, y), with a statistic that takes multiple arguments, like `pearsonr`. In this case, data=(x, y) I think this scenario is possible based on the examples, but I wasn't sure based on the docs - An Nd array of data, x, with a statistic that you want to compute along an axis, and return bootstrap statistics for each element of the other dimensions. For instance, if you want to bootstrap multiple datasets at once. In this case, data=(x,) with x.ndim > 1. I'm not clear if bootstrap can be used in this scenario - `statistic` is implicitly computed along multiple axes, and requires a vector of features per sample (e.g., R^2 from fitting a linear model from bootstrapped multivariate samples) *Is my understanding of these things correct?:* - len(data) should be equal to the number of args required by `statistic`? Is there any other reason to have len(data) > 1? - Assuming `statistic` can be computed along an axis, it has to return an array of statistics with exactly 1 fewer dimensions than the input arrays. For instance, if x is 2d, np.mean(x, axis=-1) returns a 1d array of means and is allowed, but multiclass logistic regression would take in 2d arrays (x, y) but return a scalar (accuracy) which would not be allowed. Thanks for any help, Jesse -- Jesse Livezey he/him/his

4 3

directional derivatives in Wolfe line search
by Sara Fridovich-Keil Oct. 29, 2021

Oct. 29, 2021

Hi SciPy-Dev, I have been using scipy.optimize.fmin_bfgs on some derivative-free benchmark problems, and noticed that whenever the Wolfe line search requires a directional derivative, the current implementation estimates the entire gradient via finite differencing, and then computes the directional derivative by taking the inner product of the gradient and the search direction. In my experiments, replacing this full gradient estimation with a single extra function evaluation to estimate the directional derivative directly, is faster. The key places this happens in the code are: https://github.com/scipy/scipy/blob/701ffcc8a6f04509d115aac5e5681c538b5265a… <https://github.com/scipy/scipy/blob/701ffcc8a6f04509d115aac5e5681c538b5265a…> https://github.com/scipy/scipy/blob/701ffcc8a6f04509d115aac5e5681c538b5265a… <https://github.com/scipy/scipy/blob/701ffcc8a6f04509d115aac5e5681c538b5265a…> Both of the Wolfe line search implementations take an input function fprime that computes/estimates the full gradient, even though only derphi, the directional derivative, is used. What I’d like to do is have an option for fprime to be either provided or not provided to the Wolfe line search. If the objective has a nice/cheap gradient then the current behavior is fine (passing the gradient function as fprime, and computing directional derivatives with an inner product), but if the objective is derivative-free then derphi should be computed with finite differencing along the search direction (just one extra function evaluation) instead of using fprime. Do people agree this would be a good change? If so I can make a pull request. Best, Sara

4 10

A naming survey for get_array_bandwidth
by Ilhan Polat Oct. 21, 2021

Oct. 21, 2021

Dear all, We just merged https://github.com/scipy/scipy/pull/14701 for the following 3 funcs get_array_bandwidth issymmetric ishermitian The first name is admittedly not very good and we want to change it. So far we would like to find a name that gives the connotation of "I'll return how many sub and super diagonals that are nonzero for a 2D array" In that regard we are thinking the following candidates but please add yours too get_bandwidth nonzero_diags count_nonzero_diags count_bands bandcount It would be great if you can cast your vote this week best, ilhan

4 4

NumPy 1.21.3 released
by Charles R Harris Oct. 20, 2021

Oct. 20, 2021

Hi All, On behalf of the NumPy team I am pleased to announce the release of NumPy 1.21.3. NumPy 1.21.3 is a maintenance release that fixes a few bugs discovered after the 1.21.2 release. It also provides 64 bit Python 3.10.0 wheels. Note a few oddities about the Python 3.10 wheels: - There are no 32 bit wheels for Windows, Mac, or Linux. - The Mac Intel builds are only available in universal2 wheels. The Python versions supported in this release are 3.7-3.10. If you want to compile your own version using gcc-11 you will need to use gcc-11.2+ to avoid problems. Wheels can be downloaded from PyPI <https://pypi.org/project/numpy/1.21.3/>; source archives, release notes, and wheel hashes are available on Github <https://github.com/numpy/numpy/releases/tag/v1.21.3>. Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. A recent version of pip is needed to install the universal2 macos wheels. *Contributors* A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Aaron Meurer - Bas van Beek - Charles Harris - Developer-Ecosystem-Engineering + - Kevin Sheppard - Sebastian Berg - Warren Weckesser *Pull requests merged* A total of 8 pull requests were merged for this release. - #19745: ENH: Add dtype-support to 3 ```generic``/``ndarray`` methods - #19955: BUG: Resolve Divide by Zero on Apple silicon + test failures... - #19958: MAINT: Mark type-check-only ufunc subclasses as ufunc aliases... - #19994: BUG: np.tan(np.inf) test failure - #20080: BUG: Correct incorrect advance in PCG with emulated int128 - #20081: BUG: Fix NaT handling in the PyArray_CompareFunc for datetime... - #20082: DOC: Ensure that we add documentation also as to the dict for... - #20106: BUG: core: result_type(0, np.timedelta64(4)) would seg. fault. Cheers, Charles Harris

1 0

Updated website
by Jarrod Millman Oct. 20, 2021

Oct. 20, 2021

Hi, I submitted a PR to update the scipy.org website: https://github.com/scipy/scipy.org/pull/413 This PR does two main things: 1. Makes https://scipy.org just about SciPy the library. In particular, I've removed the more general ecosystem stuff and replaced https://scipy.org with https://scipy.org/scipylib. 2. Uses the numpy.org theme. The rough plan is to merge this PR soonish and then to iteratively improve the site going forward. I will continue updating and helping out with the site for the foreseeable future. You can see a preview of the new site here: https://deploy-preview-413--loving-hopper-c72a13.netlify.app/ Best regards, Jarrod

3 2

Understanding scipy.stats.boxcox
by Keith Sloan Oct. 16, 2021

Oct. 16, 2021

I have the following questions about scipy.stats.boxcox and looking for pointers guidance. I would like to implement something similar to boxcox but with the following differences. 1) I would like to use a different transformation function from w=(y^x - 1) / x 2) I would separate from 1) like to have the target be other than a Normal/Gaussian distribution, I am thinking of a Plank function for a Blackbody I had a quick look at https://github.com/scipy/scipy/blob/master/scipy/stats/_continuous_distns.py but was still lacking enlightenment, so would welcome some pointers Thanks

5 4