From charlesr.harris at gmail.com Wed Dec 13 17:54:17 2017 From: charlesr.harris at gmail.com (Charles R Harris) Date: Wed, 13 Dec 2017 15:54:17 -0700 Subject: [SciPy-Dev] NumPy 1.14.0rc1 release Message-ID: Hi All, On behalf of the NumPy team, I am pleased to announce NumPy 1.14.0rc1. Numpy 1.14.0rc1 is the result of seven months of work and contains a large number of bug fixes and new features, along with several changes with potential compatibility issues. The major change that users will notice are the stylistic changes in the way numpy arrays and scalars are printed, a change that will affect doctests. See the release notes for details on how to preserve the old style printing when needed. A major decision affecting future development concerns the schedule for dropping Python 2.7 support in the runup to 2020. The decision has been made to support 2.7 for all releases made in 2018, with the last release being designated a long term release with support for bug fixes extending through the end of 2019. Starting from January, 2019 support for 2.7 will be dropped in all new releases. More details can be found in the relevant NEP . This release supports Python 2.7 and 3.4 - 3.6. Wheels for the pre-release are available on PyPI. Source tarballs, zipfiles, release notes, and the changelog are available on github . *Highlights* - The ``np.einsum`` function uses BLAS when possible - ``genfromtxt``, ``loadtxt``, ``fromregex`` and ``savetxt`` can now handle files with arbitrary Python supported encoding. - Major improvements to printing of NumPy arrays and scalars. *New functions* - ``parametrize``: decorator added to numpy.testing - ``chebinterpolate``: Interpolate function at Chebyshev points. - ``format_float_positional`` and ``format_float_scientific`` : format floating-point scalars unambiguously with control of rounding and padding. - ``PyArray_ResolveWritebackIfCopy`` and ``PyArray_SetWritebackIfCopyBase``, new C-API functions useful in achieving PyPy compatibity. *Contributors* A total of 101 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Alexey Brodkin + - Allan Haldane - Andras Deak + - Andrew Lawson + - Antoine Pitrou - Bernhard M. Wiedemann + - Bob Eldering + - Brandon Carter - CJ Carey - Charles Harris - Chris Lamb - Christoph Boeddeker + - Christoph Gohlke - Daniel Hrisca + - Daniel Smith - Danny Hermes - David Freese - David Hagen - David Linke + - David Schaefer + - Dillon Niederhut + - Egor Panfilov + - Emilien Kofman - Eric Wieser - Erik Bray + - Erik Quaeghebeur + - Garry Polley + - Gunjan + - Henke Adolfsson + - Hidehiro NAGAOKA + - Hong Xu + - Iryna Shcherbina + - Jaime Fernandez - James Bourbeau + - Jamie Townsend + - Jarrod Millman - Jean Helie + - Jeroen Demeyer + - John Goetz + - John Kirkham - John Zwinck - Jonathan Helmus - Joseph Fox-Rabinovitz - Joseph Paul Cohen + - Joshua Leahy + - Julian Taylor - J?rg D?pfert + - Keno Goertz + - Kevin Sheppard + - Kexuan Sun + - Konrad Kapp + - Kristofor Maynard + - Licht Takeuchi + - Lo?c Est?ve - Lukas Mericle + - Marten van Kerkwijk - Matheus Portela + - Matthew Brett - Matti Picus - Michael Lamparski + - Michael Odintsov + - Michael Schnaitter + - Michael Seifert - Mike Nolta - Nathaniel J. Smith - Nelle Varoquaux + - Nicholas Del Grosso + - Nico Schl?mer + - Oleg Zabluda + - Oleksandr Pavlyk - Pauli Virtanen - Pim de Haan + - Ralf Gommers - Robert T. McGibbon + - Roland Kaufmann - Sebastian Berg - Serhiy Storchaka + - Shitian Ni + - Spencer Hill + - Srinivas Reddy Thatiparthy + - Stefan Winkler + - Stephan Hoyer - Steven Maude + - SuperBo + - Thomas K?ppe + - Toon Verstraelen - Vedant Misra + - Warren Weckesser - Wirawan Purwanto + - Yang Li + - Ziyan + - chaoyu3 + - hemildesai + - k_kapp at yahoo.com + - nickdg + - orbit-stabilizer + - schnaitterm + - solarjoe - wufangjie + - xoviat + - ?lie Gouzien + Enjoy, Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From spq at case.edu Fri Dec 15 17:47:01 2017 From: spq at case.edu (Sean P. Quinn) Date: Fri, 15 Dec 2017 17:47:01 -0500 Subject: [SciPy-Dev] [code review] adding moyal distribution to stats Message-ID: Dear All, If it suits, I think the scipy.stats package can benefit from the addition of a new distribution: the Moyal function. My familiarity with it is from high-energy physics, but I've read it also finds use in a number of fields. It would be convenient to have a Python implementation, as it's already included in Mathematica. PR link: https://github.com/scipy/scipy/pull/8223 Cheers -- Sean P. Quinn, High Energy Astrophysics Group spq at cwru.edu | Office: 216 368 4407 | Web: hea.case.edu / auger.org / imogen.phys.cwru.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlucente at pipeline.com Sun Dec 17 13:48:44 2017 From: rlucente at pipeline.com (Robert Lucente - Pipeline.Com) Date: Sun, 17 Dec 2017 13:48:44 -0500 Subject: [SciPy-Dev] Is it true that scipy.linalg is always compiled with BLAS/LAPACK support? Message-ID: <016a01d37767$ab0fc2b0$012f4810$@pipeline.com> I am currently helping Tim W. prepare for a data science meetup in Pittsburgh. On the associated github page (https://github.com/timsetsfire/regression-from-scratch/blob/5f00d23bc83768e de39b60f46015869ddd848222/Regression%20from%20Scratch.ipynb) he states scipy.linalg vs numpy.linalg scipy.linalg contains all the functions in numpy.linalg. plus some other more advanced ones not contained in numpy.linalg Another advantage of using scipy.linalg over numpy.linalg is that it is always compiled with BLAS/LAPACK support, while for numpy this is optional. Therefore, the scipy version might be faster depending on how numpy was installed As a newbie, how would I go about trying to answer the above question myself? From robertmsare at gmail.com Sun Dec 17 19:05:02 2017 From: robertmsare at gmail.com (Robert Sare) Date: Sun, 17 Dec 2017 16:05:02 -0800 Subject: [SciPy-Dev] Is it true that scipy.linalg is always compiled with BLAS/LAPACK support? In-Reply-To: <016a01d37767$ab0fc2b0$012f4810$@pipeline.com> References: <016a01d37767$ab0fc2b0$012f4810$@pipeline.com> Message-ID: numpy.show_config() should print out the LA library paths for your installed version of numpy. Or you can use ldd to check what libraries are linked against numpy object files like $ ldd //numpy/core/_dotblas.so $ ldd //numpy/core/multiarray.so Best, Rob On 17 December 2017 at 10:48, Robert Lucente - Pipeline.Com < rlucente at pipeline.com> wrote: > I am currently helping Tim W. prepare for a data science meetup in > Pittsburgh. On the associated github page > (https://github.com/timsetsfire/regression-from- > scratch/blob/5f00d23bc83768e > de39b60f46015869ddd848222/Regression%20from%20Scratch.ipynb) he states > > scipy.linalg vs numpy.linalg > > scipy.linalg contains all the functions in numpy.linalg. plus some other > more advanced ones not contained in numpy.linalg > > Another advantage of using scipy.linalg over numpy.linalg is that it is > always compiled with BLAS/LAPACK support, while for numpy this is optional. > Therefore, the scipy version might be faster depending on how numpy was > installed > > As a newbie, how would I go about trying to answer the above question > myself? > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Sun Dec 17 20:32:44 2017 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 17 Dec 2017 17:32:44 -0800 Subject: [SciPy-Dev] Is it true that scipy.linalg is always compiled with BLAS/LAPACK support? In-Reply-To: <016a01d37767$ab0fc2b0$012f4810$@pipeline.com> References: <016a01d37767$ab0fc2b0$012f4810$@pipeline.com> Message-ID: On Sun, Dec 17, 2017 at 10:48 AM, Robert Lucente - Pipeline.Com wrote: > I am currently helping Tim W. prepare for a data science meetup in > Pittsburgh. On the associated github page > (https://github.com/timsetsfire/regression-from-scratch/blob/5f00d23bc83768e > de39b60f46015869ddd848222/Regression%20from%20Scratch.ipynb) he states > > scipy.linalg vs numpy.linalg > > scipy.linalg contains all the functions in numpy.linalg. plus some other > more advanced ones not contained in numpy.linalg > > Another advantage of using scipy.linalg over numpy.linalg is that it is > always compiled with BLAS/LAPACK support, while for numpy this is optional. > Therefore, the scipy version might be faster depending on how numpy was > installed This is technically true, but in practice it's extremely rare to find a numpy that doesn't have real BLAS/LAPACK. If you're using the official wheels, or conda, or getting it from a Linux distro, then it'll use the same BLAS/LAPACK as scipy. -n -- Nathaniel J. Smith -- https://vorpus.org From rlucente at pipeline.com Sun Dec 17 23:07:49 2017 From: rlucente at pipeline.com (Robert Lucente - Pipeline.Com) Date: Sun, 17 Dec 2017 23:07:49 -0500 Subject: [SciPy-Dev] Is it true that scipy.linalg is always compiled with BLAS/LAPACK support? Message-ID: <01d101d377b5$c5056f50$4f104df0$@pipeline.com> I am embarrassed, I just found https://docs.scipy.org/doc/scipy/reference/tutorial/linalg.html#scipy-linalg -vs-numpy-linalg -----Original Message----- From: Robert Lucente - Pipeline.Com [mailto:rlucente at pipeline.com] Sent: Sunday, December 17, 2017 1:49 PM To: 'scipy-dev at python.org' Cc: 'Robert Lucente Gmail Backup 1 (robert.backup.lucente at gmail.com)' Subject: Is it true that scipy.linalg is always compiled with BLAS/LAPACK support? I am currently helping Tim W. prepare for a data science meetup in Pittsburgh. On the associated github page (https://github.com/timsetsfire/regression-from-scratch/blob/5f00d23bc83768e de39b60f46015869ddd848222/Regression%20from%20Scratch.ipynb) he states scipy.linalg vs numpy.linalg scipy.linalg contains all the functions in numpy.linalg. plus some other more advanced ones not contained in numpy.linalg Another advantage of using scipy.linalg over numpy.linalg is that it is always compiled with BLAS/LAPACK support, while for numpy this is optional. Therefore, the scipy version might be faster depending on how numpy was installed As a newbie, how would I go about trying to answer the above question myself? From ilhanpolat at gmail.com Mon Dec 25 17:14:18 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Mon, 25 Dec 2017 23:14:18 +0100 Subject: [SciPy-Dev] Restructuring flapack.src.pyf file Message-ID: Dear all, First of all merry christmas, happy holidays, and all kinds of good stuff! 1) Since the last couple of days, I've been going through the LAPACK signature files regarding issue https://github.com/scipy/scipy/issues/8205 This is already confirmed by Intel MKL team ( https://software.intel.com/en-us/forums/intel-math-kernel-library/topic/753935) but still the LAPACK wrapper is very limited. It basically doesn't allow the full functionality. Above all, it's not possible to make a LWORK=-1 query which actually led to the original issue. In PR 6510 https://github.com/scipy/scipy/pull/6510 a similar attemt was made but seems stalled. In that one the signature of the wrapper changes. I've done a similar thing by freeing out all ins and outs. It seems to me that the signature change is inevitable but the question is how to handle this? In PR 6510, evr's are patched with decorators but I think this only complicates the matter as things get piled up. Should we rewrap the same LAPACK routine with different name instead, e.g., (d/s)syevr_full ? Excuse my lack of imagination. Or how do we deprecate a wrapper? ---------- 2) It looks like flapack.src.pyf file is getting exceedingly long and unstructured. Should we break it apart just like LAPACK documentation? In that case the files would be - flapack.ge.src.pyf(holding general matrix ?GEXXX routines ) - flapack.gb.src.pyf(holding general banded ?GBXXX routines ) - flapack.sy_he.src.pyf(holding symmetric/hermitian ?SYXXX/?HEXXX routines ) - flapack.po.src.pyf(holding pos def ?POXXX routines ) - flapack.gt.src.pyf(...) - flapack.pt.src.pyf(...) - flapack.other.src.pyf(...) and then all get included in the flapack.src.pyf. Since it's not possible to link to the signature, I don't think anybody would be affected by this (famous last words). Thoughts? ilhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Dec 25 17:58:14 2017 From: pav at iki.fi (pav at iki.fi) Date: Mon, 25 Dec 2017 22:58:14 +0000 Subject: [SciPy-Dev] Restructuring flapack.src.pyf file In-Reply-To: References: Message-ID: <3sm3kp.p1jh54.rthztg-qmf@smtp.gmail.com> Hi, Ilhan Polat kirjoitti tiistai 26. joulukuuta 2017: [clip] > I've done a similar thing by freeing out all ins and outs. It seems to me > that the signature change is inevitable but the question is how to handle > this? New function sounds best, maximally unimaginative new name is probably most appropriate. Not sure how well np.deprecate etc python level wrappers work on f2py. > 2) It looks like flapack.src.pyf file is getting exceedingly long and > unstructured. Should we break it apart just like LAPACK documentation? If you think that helps it significantly and is worthwhile use of your time then why not. (I suspect it's not particularly worthwhile but ymmv.) From ilhanpolat at gmail.com Tue Dec 26 08:40:12 2017 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Tue, 26 Dec 2017 14:40:12 +0100 Subject: [SciPy-Dev] Restructuring flapack.src.pyf file In-Reply-To: <3sm3kp.p1jh54.rthztg-qmf@smtp.gmail.com> References: <3sm3kp.p1jh54.rthztg-qmf@smtp.gmail.com> Message-ID: The situation, as usual, turns out a bit more involved In the discussion, https://github.com/scipy/scipy/issues/6502 Tiziano writes "Hi, I am the author of the original wrappers for those LAPACK routines. If I remember correctly, the reason for hiding the eigenvalues in an interval option was simply that the original implementation of scipy.linalg.eigh did not even allow to limit the number of eigenvalues/eigenvectors returned. I needed only the possiblity to define the indices of the eigenvalues and not the range, and the result is the option eigvals to scipy.linalg.eigh. I think that your wrapper is too generic. You should not allow setting from Python the values of things like lwork: a wrong value there and the user can generate a segfault from Python, which is a no-no." and I can see more LAPACK routines that are wrapped along this line. Having 8 more "xxxx_full" and "xxxx_full_lwork" routines doesn't seem to be elegant though I don't have any alternative yet. Maybe it is OK to have them for a few versions but I guess it would be nice if we have a parallel running deprecation plans for this issue. It looks like _np.deprecate works pretty OK. And we have four deprecations already in lapack.py e.g., cgegv = _np.deprecate(cgegv, old_name='cgegv', message=_dep_message) This will print a deprecation warning when it is called or docstring is printed. "DeprecationWarning: `dgegv` is deprecated! The `*gegv` family of routines has been deprecated in LAPACK 3.6.0 in favor of the `*ggev` family of routines.The corresponding wrappers will be removed from SciPy in a future release." So I would like to deprecate the routines abouve with a message "The *XXXXX family of routines will have a different signature in the future versions of SciPy. The new versions are now available as *XXXXX_full and will eventually replace the original *XXXXX family" Would you dis/agree? On Mon, Dec 25, 2017 at 11:58 PM, wrote: > Hi, > > Ilhan Polat kirjoitti tiistai 26. joulukuuta 2017: > [clip] > > I've done a similar thing by freeing out all ins and outs. It seems to me > > that the signature change is inevitable but the question is how to handle > > this? > > New function sounds best, maximally unimaginative new name is probably > most appropriate. > > Not sure how well np.deprecate etc python level wrappers work on f2py. > > > > 2) It looks like flapack.src.pyf file is getting exceedingly long and > > unstructured. Should we break it apart just like LAPACK documentation? > > If you think that helps it significantly and is worthwhile use of your > time then why not. (I suspect it's not particularly worthwhile but ymmv.) > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at python.org > https://mail.python.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cimrman3 at ntc.zcu.cz Fri Dec 29 07:47:17 2017 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Fri, 29 Dec 2017 13:47:17 +0100 Subject: [SciPy-Dev] ANN: SfePy 2017.4 Message-ID: I am pleased to announce release 2017.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (limited support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - basic support for penalty-based contacts - support for user-defined contexts in all solvers and preconditioners - new example: dispersion analysis of heterogeneous periodic materials For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Cheers, Robert Cimrman --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Lubos Kejzlar Jan Kopacka Vladimir Lukes Matyas Novak