Mailman 3 August 2016 - SciPy-Dev

dense output option in integrate.ode
by Evgeni Burovski 20 Feb '17

20 Feb '17

Hi David, Hi Jim, > I am new to SciPy-dev. Will the dense output option in scipy.integrate.ode > become available in 0.17.0? This is a feature already available in the > original FORTAN, but wasn't implemented in the wrapper. If the feature is sent as a pull request against the scipy master branch, the PR is reviewed by the maintainers of the integrate package and merged into master before the release split, then yes, it would be available in 0.17.0. So far I do not see any progress towards it. > I wrote these dense output extensions that you listed: > > https://github.com/jddmartin/scipy/tree/dense_output_from_dopri5_and_dop853 > https://github.com/jddmartin/dense_output_example_usage > > but I didn't issue any pull request to scipy. I sent this message to the > scipy developers list: > http://article.gmane.org/gmane.comp.python.scientific.devel/19635/ > explaining the changes. I was hoping for some feedback before issuing a > pull request. Ah, I see that the email likely fell through the cracks back in April. Sorry about that. You might want to ping that email thread once more or send a pull request on github (or both). <snip> Cheers, Evgeni

3 5

Scipy citations and article(s)
by Ralf Gommers 17 Aug '16

17 Aug '16

Hi all, On GitHub and off-list there has been some discussion on making Scipy releases citable and producing one or more papers. So here's a short summary for those who haven't seen that yet. Here's a proposal to use Zenodo to generate a DOI for every new Scipy release: https://github.com/scipy/scipy/issues/6446. Looks like everyone is in favor so far. Furthermore it looks like we want to produce at least an "abstract paper" for a new release, for example in Journal of Open Source Software ( http://joss.theoj.org). The main objective there being to provide a way for academics to receive the credit they deserve for contributing by being a co-author on a peer-reviewed paper that can be cited. Evgeni suggested to start a new repo for this under the scipy org, which makes sense to me. The name I propose is scipy-articles. Better ideas welcome of course. Barring objections I'll create that in a day or two. Cheers, Ralf

2 1

scipy.sparse: add save and load functions for sparse matrices
by Joscha Reimer 15 Aug '16

15 Aug '16

Hallo, I would like to propose a new save and load functionality for sparse matrices in SciPy. So far, the scipy.io.savemat/loadmat functions allow to save and load sparse matrices in MATLAB file format (version 4 and 5). However, this has some serious drawbacks. Big (sparse) matrices are not storable in a mat file (version 4 and 5) since maximal 2^31 bytes per variable are supported. Besides sparse matrices are stored in a mat file always in csc matrix format. Thus, the original matrix format is not preserved. If another matrix format is used, the format has to be converted from the original format to csc before saving and back to the original format after loading. For large matrices this can take a lot of time. In addition, the indices must be sorted in a mat file. Which can take a lot of additional time. Since the sparse matrices are always stored in csc format, the advantages of other matrix formats regarding disk consumption can not be exploited. For example, some suitable block matrices can be stored with much less disk consumption in bsr matrix format as in csc matrix format. I propose to store directly the data arrays of the sparse matrics together with the matrix format in one file using NumPys savez and savez_compressed functions. The reconstruction while loading is then possible without much effort. This can be done easily for the (csc, csr, bsr, dia and coo) formats. (The remaining dok and lil formats should only be used for construction sparse matrices anyway and than be converted to another matrix format.) This would allow to store big sparse matrices and to benefit from the advantages of the different matrix formats. A pull request (for the csc, csr and bsr matrix formats) is here: https://github.com/scipy/scipy/pull/6394 Best regards, Joscha Reimer

1 0

Policy for minimum numpy version
by Eric Quintero 11 Aug '16

11 Aug '16

Hi All, In gh-6058 <https://github.com/scipy/scipy/pull/gh-6058>, I’ve run into a test failure because a numpy function was not available in version 1.7 (the function being np.fft.rfftfreq). This is easy enough to work around, but I wonder when we should decide to move up the minimum required numpy version. Debian stable currently offers numpy 1.8.2. Ubuntu 12.04 LTS (which is EOL next April) is stuck on 1.6.1, so they’re already left behind. Ubuntu 14.04 LTS has 1.8.2. Has anyone ran into compatibility issues with 1.7 before? In _lib._numpy_compat, there is another 1.7 workaround in place for np.testing.assert_warns. -Eric Q.

6 9

change in 0.8 to fmin
by josef.pktd＠gmail.com 10 Aug '16

10 Aug '16

Was there a change related to starting values or stepsize in the latest release in Nelder-Mead fmin? I only saw changes related to convergence criteria in browsing the scipy.optimize history. I'm getting a test failure in statsmodels where the solution has the opposite sign from before. https://github.com/statsmodels/statsmodels/issues/3128#issuecomment-2386732… AFAICS, flipping the sign to negative is still a valid solution. The parameters correspond to the standard deviation and only the square (covariance matrix) is used. However, the starting values are 0.1 and all previous versions of scipy produce positive parameters, i.e. positive standard deviations. The optimization for the test case is pretty deep inside one of the models, and it's not easy to figure out what might be going on. (There are two more statsmodels test failures related to scipy optimize, but I haven't looked at the details yet.) Josef

2 2

[ANN] Mayavi-4.5.0 release
by Prabhu Ramachandran 08 Aug '16

08 Aug '16

Hello, We are pleased to announce Mayavi-4.5.0. Mayavi is a general purpose, cross-platform Python package for 2-D and 3-D scientific data visualization. Mayavi integrates seamlessly with numpy and provides a convenient Pythonic wrapper for the VTK API. It provides a high-level visualization API that sits on top of the powerful VTK (http://www.vtk.org) library. It provides a stand-alone UI to help visualize your data. Mayavi is easy to extend and embed in your own dialogs and UIs. For more information see here: http://docs.enthought.com/mayavi/mayavi/index.html New features ------------- - Jupyter notebook support: Adds basic support for displaying Mayavi images or interactive x3d scenes. For more information see here http://docs.enthought.com/mayavi/mayavi/tips.html#using-mayavi-in-jupyter-n… - Add support for recording movies and animating timesteps. - Support for the new matplotlib colorschemes. - This release improves the experimental Python 3 support from the previous release. This release should work with VTK-5.x, VTK-6.x, and 7.x. For more details on the full set of changes see: http://docs.enthought.com/mayavi/mayavi/auto/changes.html#mayavi-4-5-0 More than 50 pull requests were merged since the last release. We are thankful to Gregory R. Lee, Ioannis Tziakos, Kit Yan Choi, Patrick Snape, Prabhu Ramachandran, Ryan Pepper, SiggyF, Stefano Borini, and daytonb for their contributions towards this release. Contributions from Ioannis Tziakos, Kit Yan Choi and Stefano Borini are funded and supported by the SimPhoNy project, an EU-project funded by the 7th Framework Programme (Project number 604005) under the call NMP.2013.1.4-1. cheers, Mayavi Developers

1 0

Scipy linked to openblas
by Victor Rodriguez 05 Aug '16

05 Aug '16

Hi I am part of the Clear Linux (clearlinux.org) OS project . I wonder how to link scipy to openblas. I have read in some parts that if numpy is linked to openblas by default scipy gets linked. However I wonder if there is any specific way to tell scipy to be linked agains openblas library. This is our config log gcc -pthread /tmp/tmp2f_4k1/tmp/tmp2f_4k1/source.o -L/usr/lib64 -lopenblas -o /tmp/tmp2f_4k1/a.out libraries openblas not found in ['', ''] Runtime library openblas was not found. Ignoring FOUND: libraries = ['openblas', 'openblas'] library_dirs = ['/usr/lib64'] language = c define_macros = [('HAVE_CBLAS', None)] FOUND: libraries = ['openblas', 'openblas'] library_dirs = ['/usr/lib64'] language = c define_macros = [('HAVE_CBLAS', None)] Running from scipy source directory. Splitting linalg.interpolative Fortran source files blas_opt_info: blas_mkl_info: libraries mkl,vml,guide not found in ['/usr/lib64', '/usr/lib', '/usr/lib/'] NOT AVAILABLE openblas_info: libraries openblas not found in ['', ''] Runtime library openblas was not found. Ignoring libraries gfortran not found in ['', ''] Runtime library gfortran was not found. Ignoring FOUND: libraries = ['openblas', 'gfortran', 'openblas', 'gfortran'] library_dirs = ['/usr/lib64'] language = c define_macros = [('HAVE_CBLAS', None)] FOUND: libraries = ['openblas', 'gfortran', 'openblas', 'gfortran'] library_dirs = ['/usr/lib64'] language = c define_macros = [('HAVE_CBLAS', None)] This is due to the fact that our openblas is linked to avx technology and it boost the performance of math funtions form numpy and R: https://01.org/blogs/2016/improving-python-performance-scientific-tools-and… Thanks for the help Victor Rodriguez

2 2

Numpy 1.11.2
by Charles R Harris 04 Aug '16

04 Aug '16

Hi All, I would like to release Numpy 1.11.2rc1 this weekend. It will contain a few small fixes and enhancements for windows and the last Scipy release. If there are any pending PRs that you think should go in or be backported for this release, please speak up. Chuck

1 0

Changing termination conditions for differential evolution
by Andrew Nelson 02 Aug '16

02 Aug '16

The issue at https://github.com/scipy/scipy/issues/6382 discusses termination of the differential evolution solver. At the moment termination occurs when: np.std(population_energies) / np.abs(np.mean(population_energies)) < tol. However, if the mean of the population_energies is 0, then this unnecessarily extends the number of iterations that the solver carries out. I propose to change this behaviour to: If `tol` is a tuple (rtol, atol) then terminate when np.std(population_energies) <= (atol + rtol * np.abs(np.mean(population_energies))). However, if `tol` is a single float then the existing behaviour will be honoured. Thoughts, comments? _____________________________________ Dr. Andrew Nelson _____________________________________

1 0