Mailman 3 August 2018 - SciPy-Dev

Proposal for some new fitting routines
by Joseph Fox-Rabinovitz Aug. 22, 2018

Aug. 22, 2018

I have added a function for fitting exponential and power curves. This seems to be a fairly common problem (e.g., see the list of selections from stack exchange below). The algorithm I have implemented here is objectively better than the common solution of fitting to log(y) because it requires no up-front knowledge of the intercept, or any other estimations. Assuming that this PR is acceptable, I would like to get some criticism on where I chose to put it in the directory structure. My thought was to create a separate module for such common non-iterative optimizations. I am also unsure of whether my citation of the original work is formatted properly. I would like to make sure that the author gets the credit and publicity they deserve. The paper is mentioned (by the author) in answers to [1] and [2] below. List of relevant stack exchange questions: [1]: https://stackoverflow.com/questions/3938042/fitting-exponential-decay-with-… [2]: https://math.stackexchange.com/questions/1337601/fit-exponential-with-const… [3]: https://math.stackexchange.com/questions/350754/fitting-exponential-curve-t… [4]: https://math.stackexchange.com/questions/1999069/fit-curve-exponential-mayb… [5]: https://mathematica.stackexchange.com/questions/87645/exponential-fit-to-da… [6]: https://stackoverflow.com/questions/48099026/exponential-curve-fit-will-not… [7]: https://stackoverflow.com/questions/50683768/exponent-curve-fitting-in-pyth… [8]: https://stackoverflow.com/questions/49565152/curve-fit-an-exponential-decay… [9]: https://stackoverflow.com/questions/21420792/exponential-curve-fitting-in-s… Regards, - Joe

2 3

Re: [SciPy-Dev] SciPy-Dev Digest, Vol 178, Issue 18
by Matt Newville Aug. 22, 2018

Aug. 22, 2018

Hi All, On Tue, Aug 21, 2018 at 10:01 PM <scipy-dev-request(a)python.org> wrote: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)python.org > > You can reach the person managing the list at > scipy-dev-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. NumPy 1.15.1 released. (Charles R Harris) > 2. Proposal for some new fitting routines (Joseph Fox-Rabinovitz) > 3. Re: Proposal for some new fitting routines (josef.pktd(a)gmail.com) > > > Message: 2 > Date: Tue, 21 Aug 2018 22:12:49 -0400 > From: Joseph Fox-Rabinovitz <jfoxrabinovitz(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: [SciPy-Dev] Proposal for some new fitting routines > Message-ID: > < > CAAa1KPZ76rECAtBNF_cNMgpQD2eE1YiZgo9notpUSpGA-_yO6Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I had sent out an email about a PR proposing an exponential and a power fit > function, but I did not specify the PR number. The PR is #9158. > > Regards, > > - Joe > > > On Mon, Aug 20, 2018, 3:40 PM Joseph Fox-Rabinovitz < > jfoxrabinovitz(a)gmail.com> wrote: > > > I have added a function for fitting exponential and power curves. This > > seems to > > be a fairly common problem (e.g., see the list of selections from stack > > exchange > > below). The algorithm I have implemented here is objectively better than > > the > > common solution of fitting to log(y) because it requires no up-front > > knowledge > > of the intercept, or any other estimations. > > > > Assuming that this PR is acceptable, I would like to get some criticism > on > > where > > I chose to put it in the directory structure. My thought was to create a > > separate > > module for such common non-iterative optimizations. > > > > I am also unsure of whether my citation of the original work is formatted > > properly. I would like to make sure that the author gets the credit and > > publicity they > > deserve. The paper is mentioned (by the author) in answers to [1] and [2] > > below. > > > My impression is that these are fine procedures to have readily available, but that they might not be a great fit for scipy.optimize since the basic algorithm is non-iterative. That is, the procedures seems closer to scipy.stats.linregress and so it might make more sense having them scipy.stats, perhaps calling the routines scipy.stats.expregress and .powregress. It would be very helpful to make the output a closer match to those of linregress, especially including the standard errors and correlation coefficients if possible. Since the algorithms are non-iterative, I'm not sure it makes a lot of sense to have these become the exponential and power-law fit methodsin lmfit (there are existing exponential and power-law models there already), but I would be inclined to use these algorithms (whether they go into scipy or not) to produce initial guesses for these models. Hope that helps (and thanks for asking!), --Matt Newville

1 0

NumPy 1.15.1 released.
by Charles R Harris Aug. 21, 2018

Aug. 21, 2018

Hi All, On behalf of the NumPy team, I am pleased to announce the release of NumPy 1.15.1. This is a bugfix release for bugs and regressions reported following the 1.15.0 release. Noticeable fixes are - The annoying but harmless RuntimeWarning that "numpy.dtype size changed" has been suppressed. The long standing suppression was lost in the transition to pytest. - The update to Cython 0.28.3 exposed a problematic use of a gcc attribute used to prefer code size over speed in module initialization, possibly resulting in incorrect compiled code. This has been fixed in latest Cython but has been disabled here for safety. - Support for big-endian and ARMv8 architectures has been improved. The Python versions supported by this release are 2.7, 3.4-3.7. The wheels are linked with OpenBLAS v0.3.0, which should fix some of the linalg problems reported for NumPy 1.14. Wheels for this release can be downloaded from PyPI <https://pypi.org/project/numpy/1.15.1/>, source archives are available from Github <https://github.com/numpy/numpy/releases/tag/v1.15.1>. *Compatibility Note* The NumPy 1.15.x OS X wheels released on PyPI no longer contain 32-bit binaries. That will also be the case in future releases. See #11625 <https://github.com/numpy/numpy/issues/11625> for the related discussion. Those needing 32-bit support on the Mac should look elsewhere or build from source. *Contributors* A total of 7 people contributed to this release. People with a "+" by their names contributed a patch for the first time. * Charles Harris * Chris Billington * Elliott Sales de Andrade + * Eric Wieser * Jeremy Manning + * Matti Picus * Ralf Gommers *Pull requests merged* A total of 24 pull requests were merged for this release. * `#11647 <https://github.com/numpy/numpy/pull/11647>`__: MAINT: Filter Cython warnings in ``__init__.py`` * `#11648 <https://github.com/numpy/numpy/pull/11648>`__: BUG: Fix doc source links to unwrap decorators * `#11657 <https://github.com/numpy/numpy/pull/11657>`__: BUG: Ensure singleton dimensions are not dropped when converting... * `#11661 <https://github.com/numpy/numpy/pull/11661>`__: BUG: Warn on Nan in minimum,maximum for scalars * `#11665 <https://github.com/numpy/numpy/pull/11665>`__: BUG: cython sometimes emits invalid gcc attribute * `#11682 <https://github.com/numpy/numpy/pull/11682>`__: BUG: Fix regression in void_getitem * `#11698 <https://github.com/numpy/numpy/pull/11698>`__: BUG: Make matrix_power again work for object arrays. * `#11700 <https://github.com/numpy/numpy/pull/11700>`__: BUG: Add missing PyErr_NoMemory after failing malloc * `#11719 <https://github.com/numpy/numpy/pull/11719>`__: BUG: Fix undefined functions on big-endian systems. * `#11720 <https://github.com/numpy/numpy/pull/11720>`__: MAINT: Make einsum optimize default to False. * `#11746 <https://github.com/numpy/numpy/pull/11746>`__: BUG: Fix regression in loadtxt for bz2 text files in Python 2. * `#11757 <https://github.com/numpy/numpy/pull/11757>`__: BUG: Revert use of `console_scripts`. * `#11758 <https://github.com/numpy/numpy/pull/11758>`__: BUG: Fix Fortran kind detection for aarch64 & s390x. * `#11759 <https://github.com/numpy/numpy/pull/11759>`__: BUG: Fix printing of longdouble on ppc64le. * `#11760 <https://github.com/numpy/numpy/pull/11760>`__: BUG: Fixes for unicode field names in Python 2 * `#11761 <https://github.com/numpy/numpy/pull/11761>`__: BUG: Increase required cython version on python 3.7 * `#11763 <https://github.com/numpy/numpy/pull/11763>`__: BUG: check return value of _buffer_format_string * `#11775 <https://github.com/numpy/numpy/pull/11775>`__: MAINT: Make assert_array_compare more generic. * `#11776 <https://github.com/numpy/numpy/pull/11776>`__: TST: Fix urlopen stubbing. * `#11777 <https://github.com/numpy/numpy/pull/11777>`__: BUG: Fix regression in intersect1d. * `#11779 <https://github.com/numpy/numpy/pull/11779>`__: BUG: Fix test sensitive to platform byte order. * `#11781 <https://github.com/numpy/numpy/pull/11781>`__: BUG: Avoid signed overflow in histogram * `#11785 <https://github.com/numpy/numpy/pull/11785>`__: BUG: Fix pickle and memoryview for datetime64, timedelta64 scalars * `#11786 <https://github.com/numpy/numpy/pull/11786>`__: BUG: Deprecation triggers segfault Cheers, Charles Harris

1 0

Improve Scipy's Stable PDF FFT Implementation
by Blair Azzopardi Aug. 17, 2018

Aug. 17, 2018

Hi I've written a short paper exploring optimising our Stable probability density FFT implementation. In my original PR (7374) I introduced a method by Mitnik. However, there is a better approach by Wang that significantly improves accuracy. Wang's method can be generalized using standard techniques improving accuracy even more but at the cost of CPU time. I felt I should write to the dev mailing list as I'm not sure if implementing what I feel is a generalized approach might not be established enough within the academic community for inclusion in Scipy. Although, that said, Wang's approach is cited by several other papers so shouldn't be a problem. The paper can be found in my github repository below. I'd like to submit to Arxiv but can't without an endorsement; perhaps someone here might be willing to help there. https://github.com/bsdz/docs/blob/master/papers/Stable%20Probability%20Dens… So, I plan to raise at least another PR to replace the FFT implementation of Mitnik with Wang's. A couple of questions that come to mind: 1) Is it worth me just introducing the general solution that defaults to Wang's? 2) Is it worth placing the general FFT characteristic function code into a separate module for approximating other integrals using FFT? If so, where would be a good place? Blair

2 2

Universal Method to Sort Complex Information Found | Quanta Magazine
by Neal Becker Aug. 15, 2018

Aug. 15, 2018

https://www.quantamagazine.org/universal-method-to-sort-complex-information…

1 0

Compiling scipy on macOS with conda environment
by Andrew Nelson Aug. 15, 2018

Aug. 15, 2018

Hi all, I've been having issues compiling scipy/master on macOS in a Python 3.6 conda based environment (numpy 1.15). I'm getting a whole load of undefined symbols, and the tail end of the build log is below. I've managed to get around the problem by setting LDFLAGS (based on https://groups.google.com/a/continuum.io/forum/#!topic/conda/cwqTbwQAyW0): export LDFLAGS="$LDFLAGS -undefined dynamic_lookup -bundle" I have no idea why this works. Not sure why the problem comes about, but I thought people might be interested in knowing what the solution could be. /usr/local/bin/gfortran -Wall -g -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/_fftpackmodule.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/drfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zrfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zfftnd.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/src/dct.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/src/dst.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/fortranobject.o -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/../../.. -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/../../.. -Lbuild/temp.macosx-10.9-x86_64-3.6 -ldfftpack -lfftpack -lgfortran -o build/lib.macosx-10.9-x86_64-3.6/scipy/fftpack/_ fftpack.cpython-36m-darwin.so Undefined symbols for architecture x86_64: "_PyArg_ParseTupleAndKeywords", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o ... "_PyBytes_FromString", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyCapsule_GetPointer", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyCapsule_AsVoidPtr in fortranobject.o "_PyCapsule_New", referenced from: _fortran_getattr in fortranobject.o _F2PyCapsule_FromVoidPtr in fortranobject.o "_PyCapsule_Type", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyCapsule_Check in fortranobject.o "_PyComplex_Type", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyDict_DelItemString", referenced from: _fortran_setattr in fortranobject.o "_PyDict_GetItemString", referenced from: _fortran_getattr in fortranobject.o "_PyDict_New", referenced from: _PyFortranObject_New in fortranobject.o _PyFortranObject_NewAsAttr in fortranobject.o _fortran_setattr in fortranobject.o "_PyDict_SetItemString", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o _PyFortranObject_New in fortranobject.o _fortran_getattr in fortranobject.o _fortran_setattr in fortranobject.o "_PyErr_Clear", referenced from: _int_from_pyobj in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o _fortran_getattr in fortranobject.o _fortran_repr in fortranobject.o _F2PyCapsule_FromVoidPtr in fortranobject.o _F2PyCapsule_AsVoidPtr in fortranobject.o "_PyErr_Format", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_call in fortranobject.o _check_and_fix_dimensions in fortranobject.o "_PyErr_NewException", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyErr_NoMemory", referenced from: _fortran_getattr in fortranobject.o "_PyErr_Occurred", referenced from: _PyInit__fftpack in _fftpackmodule.o _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o ... "_PyErr_Print", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o "_PyErr_SetString", referenced from: _PyInit__fftpack in _fftpackmodule.o _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_cfft in _fftpackmodule.o _f2py_rout__fftpack_rfft in _fftpackmodule.o ... "_PyExc_AttributeError", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_setattr in fortranobject.o "_PyExc_ImportError", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyExc_RuntimeError", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_call in fortranobject.o "_PyExc_TypeError", referenced from: _fortran_call in fortranobject.o _array_from_pyobj in fortranobject.o "_PyExc_ValueError", referenced from: _array_from_pyobj in fortranobject.o _check_and_fix_dimensions in fortranobject.o "_PyImport_ImportModule", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyLong_AsLong", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyMem_Free", referenced from: _fortran_dealloc in fortranobject.o _fortran_getattr in fortranobject.o "_PyMem_Malloc", referenced from: _fortran_getattr in fortranobject.o "_PyModule_Create2", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyModule_GetDict", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyNumber_Long", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyOS_snprintf", referenced from: _fortran_getattr in fortranobject.o "_PyObject_GenericGetAttr", referenced from: _fortran_getattr in fortranobject.o "_PyObject_GetAttrString", referenced from: _PyInit__fftpack in _fftpackmodule.o _int_from_pyobj in _fftpackmodule.o _fortran_repr in fortranobject.o "_PySequence_Check", referenced from: _int_from_pyobj in _fftpackmodule.o "_PySequence_GetItem", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyType_IsSubtype", referenced from: _int_from_pyobj in _fftpackmodule.o _array_from_pyobj in fortranobject.o "_PyType_Type", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyUnicode_Concat", referenced from: _fortran_getattr in fortranobject.o "_PyUnicode_FromFormat", referenced from: _fortran_repr in fortranobject.o "_PyUnicode_FromString", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_getattr in fortranobject.o _fortran_repr in fortranobject.o "_PyUnicode_FromStringAndSize", referenced from: _fortran_getattr in fortranobject.o "_Py_BuildValue", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o ... "__PyObject_New", referenced from: _PyFortranObject_New in fortranobject.o _PyFortranObject_NewAsAttr in fortranobject.o "__Py_NoneStruct", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_cfft in _fftpackmodule.o _f2py_rout__fftpack_rfft in _fftpackmodule.o _f2py_rout__fftpack_crfft in _fftpackmodule.o ... "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Undefined symbols for architecture x86_64: "_PyArg_ParseTupleAndKeywords", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o ... "_PyBytes_FromString", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyCapsule_GetPointer", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyCapsule_AsVoidPtr in fortranobject.o "_PyCapsule_New", referenced from: _fortran_getattr in fortranobject.o _F2PyCapsule_FromVoidPtr in fortranobject.o "_PyCapsule_Type", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyCapsule_Check in fortranobject.o "_PyComplex_Type", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyDict_DelItemString", referenced from: _fortran_setattr in fortranobject.o "_PyDict_GetItemString", referenced from: _fortran_getattr in fortranobject.o "_PyDict_New", referenced from: _PyFortranObject_New in fortranobject.o _PyFortranObject_NewAsAttr in fortranobject.o _fortran_setattr in fortranobject.o "_PyDict_SetItemString", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o _PyFortranObject_New in fortranobject.o _fortran_getattr in fortranobject.o _fortran_setattr in fortranobject.o "_PyErr_Clear", referenced from: _int_from_pyobj in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o _fortran_getattr in fortranobject.o _fortran_repr in fortranobject.o _F2PyCapsule_FromVoidPtr in fortranobject.o _F2PyCapsule_AsVoidPtr in fortranobject.o "_PyErr_Format", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_call in fortranobject.o _check_and_fix_dimensions in fortranobject.o "_PyErr_NewException", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyErr_NoMemory", referenced from: _fortran_getattr in fortranobject.o "_PyErr_Occurred", referenced from: _PyInit__fftpack in _fftpackmodule.o _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o ... "_PyErr_Print", referenced from: _PyInit__fftpack in _fftpackmodule.o _F2PyDict_SetItemString in fortranobject.o "_PyErr_SetString", referenced from: _PyInit__fftpack in _fftpackmodule.o _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_cfft in _fftpackmodule.o _f2py_rout__fftpack_rfft in _fftpackmodule.o ... "_PyExc_AttributeError", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_setattr in fortranobject.o "_PyExc_ImportError", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyExc_RuntimeError", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_call in fortranobject.o "_PyExc_TypeError", referenced from: _fortran_call in fortranobject.o _array_from_pyobj in fortranobject.o "_PyExc_ValueError", referenced from: _array_from_pyobj in fortranobject.o _check_and_fix_dimensions in fortranobject.o "_PyImport_ImportModule", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyLong_AsLong", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyMem_Free", referenced from: _fortran_dealloc in fortranobject.o _fortran_getattr in fortranobject.o "_PyMem_Malloc", referenced from: _fortran_getattr in fortranobject.o "_PyModule_Create2", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyModule_GetDict", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyNumber_Long", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyOS_snprintf", referenced from: _fortran_getattr in fortranobject.o "_PyObject_GenericGetAttr", referenced from: _fortran_getattr in fortranobject.o "_PyObject_GetAttrString", referenced from: _PyInit__fftpack in _fftpackmodule.o _int_from_pyobj in _fftpackmodule.o _fortran_repr in fortranobject.o "_PySequence_Check", referenced from: _int_from_pyobj in _fftpackmodule.o "_PySequence_GetItem", referenced from: _int_from_pyobj in _fftpackmodule.o "_PyType_IsSubtype", referenced from: _int_from_pyobj in _fftpackmodule.o _array_from_pyobj in fortranobject.o "_PyType_Type", referenced from: _PyInit__fftpack in _fftpackmodule.o "_PyUnicode_Concat", referenced from: _fortran_getattr in fortranobject.o "_PyUnicode_FromFormat", referenced from: _fortran_repr in fortranobject.o "_PyUnicode_FromString", referenced from: _PyInit__fftpack in _fftpackmodule.o _fortran_getattr in fortranobject.o _fortran_repr in fortranobject.o "_PyUnicode_FromStringAndSize", referenced from: _fortran_getattr in fortranobject.o "_Py_BuildValue", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfft_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_zfftnd_cache in _fftpackmodule.o _f2py_rout__fftpack_destroy_drfft_cache in _fftpackmodule.o ... "__PyObject_New", referenced from: _PyFortranObject_New in fortranobject.o _PyFortranObject_NewAsAttr in fortranobject.o "__Py_NoneStruct", referenced from: _f2py_rout__fftpack_zfft in _fftpackmodule.o _f2py_rout__fftpack_drfft in _fftpackmodule.o _f2py_rout__fftpack_zrfft in _fftpackmodule.o _f2py_rout__fftpack_zfftnd in _fftpackmodule.o _f2py_rout__fftpack_cfft in _fftpackmodule.o _f2py_rout__fftpack_rfft in _fftpackmodule.o _f2py_rout__fftpack_crfft in _fftpackmodule.o ... "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status error: Command "/usr/local/bin/gfortran -Wall -g -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/_fftpackmodule.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/drfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zrfft.o build/temp.macosx-10.9-x86_64-3.6/scipy/fftpack/src/zfftnd.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/src/dct.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/src/dst.o build/temp.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/build/src.macosx-10.9-x86_64-3.6/scipy/fftpack/fortranobject.o -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0 -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/../../.. -L/usr/local/gfortran/lib/gcc/x86_64-apple-darwin16/6.3.0/../../.. -Lbuild/temp.macosx-10.9-x86_64-3.6 -ldfftpack -lfftpack -lgfortran -o build/lib.macosx-10.9-x86_64-3.6/scipy/fftpack/_ fftpack.cpython-36m-darwin.so" failed with exit status 1

2 2

Cython optimize root finders
by Mark Alexander Mikofski Aug. 14, 2018

Aug. 14, 2018

Hi, After some previous discussion, I have implemented or wrapped some root finders from optimize in Cython for users who need performance improvements or low level control. See https://github.com/scipy/scipy/pull/8431#issuecomment-412699499 I would appreciate anyone's comments. Thanks, Mark

1 0

minor update to CoC
by Ralf Gommers Aug. 12, 2018

Aug. 12, 2018

Hi all, On the NumPy mailing list there was/is a long discussion about adopting a CoC. In particular, the same one as SciPy. People are in agreement on that but wanted one clarification - that the list of categories in the diversity statement was appended with a sentence saying that being in such a category does not excuse bad behavior. We would like to keep the SciPy and NumPy CoC's in sync, so that addition is being made at https://github.com/scipy/scipy/pull/9109 first. The exact addition is: ", to the extent that these do not conflict with this code of conduct." I plan to merge that PR soon, if there's any objection please comment. Cheers, Ralf

2 1

scikit prefix for microscopy file I/O library?
by Magnus Nord Aug. 9, 2018

Aug. 9, 2018

I'm one of the developers in the HyperSpy project, which is an open source python library for analysing multidimensional data, with a focus on electron microscopy. We're in the processes of splitting the project into smaller pieces, to i) make the code a bit more manageable, ii) make it easier for other projects to use specific functionalities without having to install a lot of extra dependencies. The current focus is moving the file reading/writing functionality to its own library, which includes readers for many types of proprietary electron microscopy file formats. The plan is to keep the GPLv3 license, and only depend on the more standard scientific python stack (numpy, ...). However, we've been having some issues in deciding on a name for the library, and someone suggested using a scikit- prefix (scikit-microscopyIO?, scikit-microscopy-io?). So I'm wondering if a scikit prefix would be appropriate for a library focused on file I/O of microscopy data? Discussion on this in the HyperSpy issue tracker: https://github.com/hyperspy/hyperspy/issues/1978 Magnus

3 6

Re: [SciPy-Dev] Review of PR 8293 - sampling of random variates
by Christoph Baumgarten Aug. 5, 2018

Aug. 5, 2018

A good source on the ratio of uniforms method is the book by Devroye: "non-uniform random variate generation" or the original paper "Computer Computer Generation of Random Variables using the ratio of uniform deviates" by kinderman / monahan. <scipy-dev-request(a)python.org> schrieb am Sa., 4. Aug. 2018, 18:03: > Send SciPy-Dev mailing list submissions to > scipy-dev(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/scipy-dev > or, via email, send a message with subject or body 'help' to > scipy-dev-request(a)python.org > > You can reach the person managing the list at > scipy-dev-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-Dev digest..." > > > Today's Topics: > > 1. Re: Review of PR 8293 - sampling of random variates (Neal Becker) > 2. Re: Backwards Compatibility for low level LAPACK routines > (Ralf Gommers) > 3. Re: Backwards Compatibility for low level LAPACK routines > (Pauli Virtanen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 4 Aug 2018 07:44:06 -0400 > From: Neal Becker <ndbecker2(a)gmail.com> > To: SciPy Developers List <scipy-dev(a)python.org> > Subject: Re: [SciPy-Dev] Review of PR 8293 - sampling of random > variates > Message-ID: > < > CAG3t+pF_5GMXGDJUJF-Z8n2iRHvTSpwG6_b4y1dMWSqwKS_29w(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Don't know about this particular code, but unuran is pretty comprehensive, > and there's a good book from the author. > > On Fri, Aug 3, 2018, 5:37 PM Phillip Feldman <phillip.m.feldman(a)gmail.com> > wrote: > > > The ability to sample random variates from a distribution where only the > > density is available seems quite useful. Is there a reference that > > describes the method? > > > > Phillip > > > > On Thu, Aug 2, 2018 at 11:43 PM, Christoph Baumgarten < > > christoph.baumgarten(a)gmail.com> wrote: > > > >> PR 8293 introduces a method to sample random variates for more complex > >> distributions to scipy.stats (such as hyperbolic distributions and the > >> generalized inverse gaussian (see PR 8681)). I think the PR is in good > >> shape, it would be great if it could be merged soon since i could then > >> continue to work on adding new distributions. The PR has been open for 7 > >> months now. If someone could continue the review, that would bei great. > >> Thanks! > >> > >> _______________________________________________ > >> SciPy-Dev mailing list > >> SciPy-Dev(a)python.org > >> https://mail.python.org/mailman/listinfo/scipy-dev > >> > >> > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev(a)python.org > > https://mail.python.org/mailman/listinfo/scipy-dev > > >

2 1