Mailman 3 February 2020 - SciPy-Dev

Re: [SciPy-Dev] Discontinued Rackspace Open Compute Discount
by Robert Lucente 05 Oct '20

05 Oct '20

Several CI services are free for open source projects although there are throughput limits https://about.gitlab.com https://github.com/features/actions https://travis-ci.org https://www.appveyor.com -----Original Message----- >From: Olivier Grisel <olivier.grisel(a)ensta.org> >Sent: Feb 8, 2020 11:30 AM >To: SciPy Developers List <scipy-dev(a)python.org> >Subject: [SciPy-Dev] Discontinued Rackspace Open Compute Discount > >Hi all, > >I received an email end of January that I just discovered today >telling me that the Rackspace Open Compute Discount grant we use to >host http://wheels.scipy.org for nightly builds and release management >of our community has been discontinued on December 31st 2019. > >I would like to take down the Rackspace hosted cloudfiles as soon as >possible but we need to find a replacement as this will break all the >CIs that rely on nightly wheels and also all the wheel release >infrastructure for several project in the ecosystem. > >Apparently the fees for January and the beginning of February already >sum to $936.51. This is a large cost because there were a bunch of >unused left-over block volumes that I already deleted. > >To host wheels for nightly builds and release automation, a possible >alternatives include using the github release pages but they are not >really designed for this kind of workflow. > >Alternatively there is a PyPI repo hosting feature in Azure Pipelines >in public preview but I am not sure how it works, if it's free for >open source projects and if we could use it as a replacement for the >Rackspace cloud storage we currently use to host >http://wheels.scipy.org . > >https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/pypi?view… > >Important: if you have uploaded any important files to one of the >cloud file storage / blob containers on Rackspace, please download a >copy as soon as possible. > >But please do not download things you do not really want to keep to >avoid adding any unnecessary bandwidth costs. If you have file write >permission on one of those containers, please delete the files you own >and do not need anymore. > >Feel free to join this room to discuss the matter interactively: >https://gitter.im/scikit-learn/nightly-build-hosting > >Feel free to reply to this email on the scipy-dev mailing list if you >have suggestions for setting up a free replacement. > >-- >Olivier >http://twitter.com/ogrisel - http://github.com/ogrisel >_______________________________________________ >SciPy-Dev mailing list >SciPy-Dev(a)python.org >https://mail.python.org/mailman/listinfo/scipy-dev

12 25

SciPy Contribution: Gammatone Filters in scipy.signal
by Shashaank Narayanan 23 May '20

23 May '20

Hello SciPy Team, I am new to this mailing list, and I am interested in contributing to SciPy. I would like to suggest a new feature to be added to the scipy.signal module: gammatone filters. Gammatone filters are becoming increasingly popular in the fields of digital signal processing and music analysis as it effectively models the auditory filters of the human auditory system. Currently, there are very few implementations of gammatone filters available for Python, and these implementations are not generalized to basic finite impulse response (FIR) and infinite impulse response (IIR) filters like SciPy has. I have written my own gammatone FIR filter using NumPy based on Malcolm Slaney's 1993 paper on the topic ( https://engineering.purdue.edu/~malcolm/apple/tr35/PattersonsEar.pdf). This paper was used for Matlab's implementation of gammatone filters. I am in the process of writing a gammatone IIR filter with NumPy and SciPy. Please let me know if this feature will fit with the scipy.signal module. Appreciate your time and guidance. Thanks, Shashaank

5 6

changing default for median_absolute_deviation
by Lucas Roberts 08 Mar '20

08 Mar '20

Hi scipy-dev, Looking for guidance if the change warrants ignoring deprecation policy or if I should create a deprecation warning for existing behavior to change defaults in median_absolute_deviation() PR: https://github.com/scipy/scipy/pull/11431 [CONTEXT] In this PR: https://github.com/scipy/scipy/pull/9637 the median_absolute_deviation() function was added to scipy.stats the function takes in a scale argument that allows for a robust estimator of the scale (robust to outliers). The choice of scale constant assuming normal input data seemed reasonable to me at the time. However, in this PR: https://github.com/scipy/scipy/issues/11090 a few thought otherwise and we came to the conclusion that the default scale should be 1 which would also ensure internal consistency with the stats.iqr() function (similar signature and functionality). I've opened a PR to change the defaults here: https://github.com/scipy/scipy/pull/11431 and pinged those on the 11090 issue. [ON DEPRECATION]: [REASON FOR] Main reason to not follow deprecation policy are: 1. Following deprecation policy would maintain existing confusing behavior for up to 1 year from now. 2. Function released in 1.3.0 so somewhat new 3. Seems the default is confusing users and is non-obvious and inconsistent with iqr() default [REASON NOT] 1. Some users may depend on existing default 2. Defaults with normal scaling exist in several places (c.f. 11090 issue comments) 3. Deprecation warning needs to be done to give fair warning of the change. [COMMENTS] I haven't much experience here with deprecations, when to do it vs consider a defect so would appreciate any guidance. If we think the deprecation cycle should follow, should I leave the PR and open a separate deprecation PR? https://github.com/scipy/scipy/pull/11431 Alternately could revert changes and convert to a deprecation warning PR. Thanks in advance. -- -Lucas

2 1

Disable rpaths in shared objects when cross compiling
by Greg Anders 01 Mar '20

01 Mar '20

Hi all, I'm cross compiling Scipy in Yocto Linux for an embedded platform. I'm able to compile Scipy, but Yocto is giving me warnings because the shared objects are linked with the -rpath flag using absolute paths on the build host. I'd like to disable the -rpath flag when linking the shared objects, but I'm not sure how to do that. I've dug through the numpy.distutils code and I found the following in the CCompiler_customize_cmd function: if allow('rpath'): self.set_runtime_library_dirs(cmd.rpath) So it *looks* like if I can pass 'rpath' into the optional `ignore` paramater to the `customize_cmd` function, numpy will not use the -rpath flag when linking. However, it's not clear to me how to _use_ the `ignore` parameter of `customize_cmd`. All usages of `customize_cmd` in build_ext.py only use a single parameter, so `ignore` is always set to the default value of an empty tuple. Is there an easier way to disable rpaths than patching numpy.distutils to path `ignore=('rpath')` as a second parameter to `customize_cmd`? Thanks! Greg

2 1

Choosing the result of dtype for integration
by yotam vaknin 29 Feb '20

29 Feb '20

Hello list, I hope I'm now visiting a very old topic, but I wanted to suggest a simple change to the integration mechanism. At this moment, the dtype of the result of an integration is the dtype of the initial condition. For example, when using ״solve_ivp" to solve the initial value problem y0=np.array([1,0] ) dy/dt= -i H@y0 which is a very a standard calculation in Quantum Mechanics, the integrator will return nonsense, since the process involves complex numbers, and the initial conditions were (wrongly assigned to be) real. The solution is of course y0=np.array([1,0], dtype=complex), but this is very hard to figure out to new users coming from, for e.g., Matlab. I wanted to suggest that instead of choosing the dtype using the initial condition, that the resulting dtype will be the dtype of the derivative (or better yet, derivative*dt + initial condition). This will solve the problem, and introduce minimal confusing. Thanks for all of your great work! Regards, Yotam Vaknin

2 4

ENH: Implement a Quadratic Assignment Problem Solver
by Ali Saad-Eldin 27 Feb '20

27 Feb '20

Hello! I would like to add a Quadratic Approximation Problem (QAP)<https://en.wikipedia.org/wiki/Quadratic_assignment_problem> solver function, by implementing the Fast Approximate QAP (FAQ) algorithm<https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0121…> (Vogelstein, 2015). QAP is a combinatorial optimization problem, and the FAQ algorithm can be applied to solve special cases of QAP, including the Graph Matching Problem (GMP) and the Traveling Salesman Problem (TSP). Since the QAP is a combinatorial optimization problem, I'd like to have the FAQ implementation exposed through scipy.optimize. The module would accept parameters such as permutation initialization type (single barycenter initialization, or several initializations "close" to the barycenter), maximum Frank-Wolfe iterations, and whether you would like to solve a special case of the QAP (such as GMP). The module would fit with the two cost matrices in the objective function, returning the score (minimized objection function value) and indices of the optimal permutation matrix from the objective function. The implementation will also give the option to include seeds I have already implemented FAQ in GraSPy<https://github.com/neurodata/graspy/blob/master/graspy/match/faq.py>, and proof of effectiveness can be found here<https://graspy.neurodata.io/tutorials/matching/faq.html> . Best, Ali Saad-Eldin

6 10

[Newbie] Information regarding GSoC
by Shubham Mishra 24 Feb '20

24 Feb '20

Hello, Newbie here. Is Scipy participating in GSoC this year? I am curious to work under Scipy for GSoC if it is possible. Can someone mentor me regarding this? Thanking you, Yours sincerely, Shubham Mishra (Github handle: grapheo12)

2 4

participating in GSoC'20?
by Ralf Gommers 24 Feb '20

24 Feb '20

Hi all, It's that time of the year again already. Do we want to participate in this years' Google Summer of Code? Last year was quite successful (Peter's work on scipy.fft). We do need some volunteers to mentors though, and ideally also someone to admin (I'm pretty swamped). Any takers? Any good topic ideas? Cheers, Ralf

2 2

scipy.linalg.svd for n-dimensional arrays in stacked format
by Melissa Mendonça 18 Feb '20

18 Feb '20

Hello all, I just came across this today. While we generally encourage users to use scipy.linalg instead of numpy.linalg, I realized that numpy.linalg.svd works for general n-dimensional arrays in "stacked format" (see [1, 2]) while scipy.linalg.svd does not. Example: ========================= >>> import numpy as np >>> from scipy.linalg import svd >>> A = np.random.rand(2,3,4) >>> U, s, Vt = np.linalg.svd(A) # works fine >>> W, sigma, Yt = svd(A) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) <ipython-input-6-fc853a2e096f> in <module> ----> 1 W, sigma, Yt = svd(A) /opt/miniconda/envs/normal/lib/python3.7/site-packages/scipy/linalg/decomp_svd.py in svd(a, full_matrices, compute_uv, overwrite_a, check_finite, lapack_driver) 109 a1 = _asarray_validated(a, check_finite=check_finite) 110 if len(a1.shape) != 2: --> 111 raise ValueError('expected matrix') 112 m, n = a1.shape 113 overwrite_a = overwrite_a or (_datacopied(a1, a)) ValueError: expected matrix ========================= My question is if this is a design decision or a missing feature. If this is an interesting funcionality that should be added to SciPy, I can look into it. Thanks, -- Melissa Weber Mendonça [1] In the docs for numpy.linalg.svd: "If `a` has more than two dimensions, then broadcasting rules apply, as explained in :ref:`routines.linalg-broadcasting`. This means that SVD is working in "stacked" mode: it iterates over all indices of the first ``a.ndim - 2`` dimensions and for each combination SVD is applied to the last two indices. The matrix `a` can be reconstructed from the decomposition with either ``(u * s[..., None, :]) @ vh`` or ``u @ (s[..., None] * vh)``. (The ``@`` operator can be replaced by the function ``np.matmul`` for python versions below 3.5.) [2] https://numpy.org/devdocs/reference/generated/numpy.linalg.svd.html

2 1

contributing to Scipy
by Aakash kaushik 17 Feb '20

17 Feb '20

hey everyone my name is Aakash Kaushik, i am new here and also to the open source world. i have used Scipy a lot in my projects and wanted to contribute to it i know python with beginner level and have background in machine learning, is there any issues i can contribute with?

2 1