From matthew.pitkin at glasgow.ac.uk Thu Feb 4 09:22:27 2016 From: matthew.pitkin at glasgow.ac.uk (Matthew Pitkin) Date: Thu, 4 Feb 2016 14:22:27 +0000 Subject: [SciPy-Dev] adding trapezoidal integration equivalent to logsumexp Message-ID: <56B35EA3.3010802@glasgow.ac.uk> Dear SciPy-dev list, I often require using trapezoidal integration of probability distribution functions (pdfs). For numerical reasons it is generally best to compute the logarithm of the pdfs, so integrating them whilst staying in log-space is generally required. Provided the steps between points are equal the scipy.misc.logsumexp function can be used for this, but I was wondering if a function specifically for this purpose (and following the usage of scipy.integrate.trapz function) might be more generally useful (called e.g. logtrapz)? I have my own code to do this, so if the list thinks this could be useful I can add it into scipy and create a pull request. Regards, Matt -- ----------------------------------------------------------- Matthew Pitkin School of Physics and Astronomy Kelvin Building University of Glasgow Glasgow, G12 8QQ Tel. no. +44 (0)141 330 7168 Mob. no. +44 (0)774 050 7792 e-mail matthew.pitkin at glasgow.ac.uk http://www.astro.gla.ac.uk/~matthew ----------------------------------------------------------- From thomas.haslwanter at gmail.com Thu Feb 4 13:15:03 2016 From: thomas.haslwanter at gmail.com (Thomas Haslwanter) Date: Thu, 4 Feb 2016 19:15:03 +0100 Subject: [SciPy-Dev] adding trapezoidal integration equivalent to logsumexp In-Reply-To: <56B35EA3.3010802@glasgow.ac.uk> References: <56B35EA3.3010802@glasgow.ac.uk> Message-ID: Why don't you use CDF? On Feb 4, 2016 3:22 PM, "Matthew Pitkin" wrote: > Dear SciPy-dev list, > > I often require using trapezoidal integration of probability distribution > functions (pdfs). For numerical reasons it is generally best to compute the > logarithm of the pdfs, so integrating them whilst staying in log-space is > generally required. Provided the steps between points are equal the > scipy.misc.logsumexp function can be used for this, but I was wondering if > a function specifically for this purpose (and following the usage of > scipy.integrate.trapz function) might be more generally useful (called e.g. > logtrapz)? I have my own code to do this, so if the list thinks this could > be useful I can add it into scipy and create a pull request. > > Regards, > > Matt > > -- > ----------------------------------------------------------- > Matthew Pitkin > School of Physics and Astronomy > Kelvin Building > University of Glasgow > Glasgow, G12 8QQ > > Tel. no. +44 (0)141 330 7168 > Mob. no. +44 (0)774 050 7792 > e-mail matthew.pitkin at glasgow.ac.uk > http://www.astro.gla.ac.uk/~matthew > ----------------------------------------------------------- > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.pitkin at glasgow.ac.uk Fri Feb 5 17:20:30 2016 From: matthew.pitkin at glasgow.ac.uk (Matthew Pitkin) Date: Fri, 5 Feb 2016 22:20:30 +0000 Subject: [SciPy-Dev] adding trapezoidal integration equivalent to logsumexp In-Reply-To: References: <56B35EA3.3010802@glasgow.ac.uk> Message-ID: <56B5202E.2080804@glasgow.ac.uk> I'm thinking about pdfs that I've calculated myself rather than pdfs of known distributions within scipy, so they won't have a defined CDF. Regards, Matt On 04/02/16 18:15, Thomas Haslwanter wrote: > > Why don't you use CDF? > > On Feb 4, 2016 3:22 PM, "Matthew Pitkin" > wrote: > > Dear SciPy-dev list, > > I often require using trapezoidal integration of probability > distribution functions (pdfs). For numerical reasons it is > generally best to compute the logarithm of the pdfs, so > integrating them whilst staying in log-space is generally > required. Provided the steps between points are equal the > scipy.misc.logsumexp function can be used for this, but I was > wondering if a function specifically for this purpose (and > following the usage of scipy.integrate.trapz function) might be > more generally useful (called e.g. logtrapz)? I have my own code > to do this, so if the list thinks this could be useful I can add > it into scipy and create a pull request. > > Regards, > > Matt > > -- > ----------------------------------------------------------- > Matthew Pitkin > School of Physics and Astronomy > Kelvin Building > University of Glasgow > Glasgow, G12 8QQ > > Tel. no. +44 (0)141 330 7168 > Mob. no. +44 (0)774 050 7792 > e-mail matthew.pitkin at glasgow.ac.uk > > http://www.astro.gla.ac.uk/~matthew > > ----------------------------------------------------------- > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev -- ----------------------------------------------------------- Matthew Pitkin School of Physics and Astronomy Kelvin Building University of Glasgow Glasgow, G12 8QQ Tel. no. +44 (0)141 330 7168 Mob. no. +44 (0)774 050 7792 e-mail matthew.pitkin at glasgow.ac.uk http://www.astro.gla.ac.uk/~matthew ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From astudillor at gmail.com Fri Feb 5 19:29:26 2016 From: astudillor at gmail.com (Reinaldo Astudillo) Date: Sat, 6 Feb 2016 01:29:26 +0100 Subject: [SciPy-Dev] Adding IDR(s) to scipy.sparse.linalg.isolve Message-ID: Hello folks, I would like to contribute to scipy adding IDR(s) method to the iterative method module scipy.sparse.linalg.isolve IDR(s) a short recurrences Krylov method that is very competitive with BiCGSTAB, gmres restart, BiCG among others. Some reference Peter Sonneveld and Martin B. van Gijzen, IDR(s): a family of simple and fast algorithms for solving large nonsymmetric linear systems. SIAM J. Sci. Comput. Vol. 31, No. 2, pp. 1035-1062, 2008 (copyright SIAM) Martin B. van Gijzen and Peter Sonneveld, Algorithm 913: An Elegant IDR(s) Variant that Efficiently Exploits Bi-orthogonality Properties. ACM Transactions on Mathematical Software, Vol. 38, No. 1, pp. 5:1-5:19, 2011 (copyright ACM) I have implemented it (https://github.com/astudillor/idrs_solver) and also I have checked my code using autop8p and pyflakes. Could you tell me how to continue? All the best Reinaldo -- _________________________________ Reinaldo A. Astudillo R. Delft Institute of Applied Mathematics Delft University of Technology Delft - The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sat Feb 6 15:26:34 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 6 Feb 2016 12:26:34 -0800 Subject: [SciPy-Dev] Multi-distribution Linux wheels - please test Message-ID: Hi, As some of you may have seen, Robert McGibbon and Nathaniel have just guided a PEP for multi-distribution Linux wheels past the approval process over on distutils-sig: https://www.python.org/dev/peps/pep-0513/ The PEP includes a docker image on which y'all can build wheels which match the PEP: https://quay.io/repository/manylinux/manylinux Now we're at the stage where we need stress-testing of the built wheels to find any problems we hadn't thought of. I've built numpy and scipy wheels here: https://nipy.bic.berkeley.edu/manylinux/ So, if you have a Linux distribution handy, we would love to hear from you about the results of testing these guys, maybe on the lines of: pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy python -c 'import numpy; numpy.test()' python -c 'import scipy; scipy.test()' These manylinux wheels should soon be available on pypi, and soon after, installable with latest pip, so we would like to fix as many problems as possible before going live. Cheers, Matthew From matthew.brett at gmail.com Sun Feb 7 00:52:02 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sat, 6 Feb 2016 21:52:02 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sat, Feb 6, 2016 at 9:28 PM, Nadav Horesh wrote: > Test platform: python 3.4.1 on archlinux x86_64 > > scipy test: OK > > OK (KNOWNFAIL=97, SKIP=1626) > > > numpy tests: Failed on long double and int128 tests, and got one error: > > Traceback (most recent call last): > File "/usr/lib/python3.5/site-packages/nose/case.py", line 198, in runTest > self.test(*self.arg) > File "/usr/lib/python3.5/site-packages/numpy/core/tests/test_longdouble.py", line 108, in test_fromstring_missing > np.array([1])) > File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 296, in assert_equal > return assert_array_equal(actual, desired, err_msg, verbose) > File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 787, in assert_array_equal > verbose=verbose, header='Arrays are not equal') > File "/usr/lib/python3.5/site-packages/numpy/testing/utils.py", line 668, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not equal > > (shapes (6,), (1,) mismatch) > x: array([ 1., -1., 3., 4., 5., 6.]) > y: array([1]) > > ---------------------------------------------------------------------- > Ran 6019 tests in 28.029s > > FAILED (KNOWNFAIL=13, SKIP=12, errors=1, failures=18 Great - thanks so much for doing this. Do you get a different error if you compile from source? If you compile from source, do you link to OpenBLAS? Thanks again, Matthew From njs at pobox.com Sun Feb 7 05:40:10 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 7 Feb 2016 02:40:10 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Feb 6, 2016 12:27 PM, "Matthew Brett" wrote: > > Hi, > > As some of you may have seen, Robert McGibbon and Nathaniel have just > guided a PEP for multi-distribution Linux wheels past the approval > process over on distutils-sig: > > https://www.python.org/dev/peps/pep-0513/ > > The PEP includes a docker image on which y'all can build wheels which > match the PEP: > > https://quay.io/repository/manylinux/manylinux This is the wrong repository :-) It moved, and there are two now: quay.io/pypa/manylinux1_x86_64 quay.io/pypa/manylinux1_i686 -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Feb 7 12:49:12 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 7 Feb 2016 10:49:12 -0700 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote: > On Feb 6, 2016 12:27 PM, "Matthew Brett" wrote: > > > > Hi, > > > > As some of you may have seen, Robert McGibbon and Nathaniel have just > > guided a PEP for multi-distribution Linux wheels past the approval > > process over on distutils-sig: > > > > https://www.python.org/dev/peps/pep-0513/ > > > > The PEP includes a docker image on which y'all can build wheels which > > match the PEP: > > > > https://quay.io/repository/manylinux/manylinux > > This is the wrong repository :-) It moved, and there are two now: > > quay.io/pypa/manylinux1_x86_64 > quay.io/pypa/manylinux1_i686 > I'm going to put out 1.11.0b3 today. What would be the best thing to do for testing? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Sun Feb 7 16:16:52 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 7 Feb 2016 13:16:52 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sun, Feb 7, 2016 at 9:49 AM, Charles R Harris wrote: > > > On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote: >> >> On Feb 6, 2016 12:27 PM, "Matthew Brett" wrote: >> > >> > Hi, >> > >> > As some of you may have seen, Robert McGibbon and Nathaniel have just >> > guided a PEP for multi-distribution Linux wheels past the approval >> > process over on distutils-sig: >> > >> > https://www.python.org/dev/peps/pep-0513/ >> > >> > The PEP includes a docker image on which y'all can build wheels which >> > match the PEP: >> > >> > https://quay.io/repository/manylinux/manylinux >> >> This is the wrong repository :-) It moved, and there are two now: >> >> quay.io/pypa/manylinux1_x86_64 >> quay.io/pypa/manylinux1_i686 > > > I'm going to put out 1.11.0b3 today. What would be the best thing to do for > testing? I'd say, don't worry about building linux wheels as part of the release cycle yet -- it'll still be a bit before they're allowed on pypi or pip will recognize the new special tag. So for now you can leave it to Matthew or someone to build test images and stick them up on a server somewhere, same as before :-) -n -- Nathaniel J. Smith -- https://vorpus.org From charlesr.harris at gmail.com Sun Feb 7 18:27:43 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 7 Feb 2016 16:27:43 -0700 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sun, Feb 7, 2016 at 2:16 PM, Nathaniel Smith wrote: > On Sun, Feb 7, 2016 at 9:49 AM, Charles R Harris > wrote: > > > > > > On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote: > >> > >> On Feb 6, 2016 12:27 PM, "Matthew Brett" > wrote: > >> > > >> > Hi, > >> > > >> > As some of you may have seen, Robert McGibbon and Nathaniel have just > >> > guided a PEP for multi-distribution Linux wheels past the approval > >> > process over on distutils-sig: > >> > > >> > https://www.python.org/dev/peps/pep-0513/ > >> > > >> > The PEP includes a docker image on which y'all can build wheels which > >> > match the PEP: > >> > > >> > https://quay.io/repository/manylinux/manylinux > >> > >> This is the wrong repository :-) It moved, and there are two now: > >> > >> quay.io/pypa/manylinux1_x86_64 > >> quay.io/pypa/manylinux1_i686 > > > > > > I'm going to put out 1.11.0b3 today. What would be the best thing to do > for > > testing? > > I'd say, don't worry about building linux wheels as part of the > release cycle yet -- it'll still be a bit before they're allowed on > pypi or pip will recognize the new special tag. So for now you can > leave it to Matthew or someone to build test images and stick them up > on a server somewhere, same as before :-) > Should I try putting the sources up on pypi? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sun Feb 7 18:29:43 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Sun, 7 Feb 2016 15:29:43 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sun, Feb 7, 2016 at 3:27 PM, Charles R Harris wrote: > > > On Sun, Feb 7, 2016 at 2:16 PM, Nathaniel Smith wrote: >> >> On Sun, Feb 7, 2016 at 9:49 AM, Charles R Harris >> wrote: >> > >> > >> > On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote: >> >> >> >> On Feb 6, 2016 12:27 PM, "Matthew Brett" >> >> wrote: >> >> > >> >> > Hi, >> >> > >> >> > As some of you may have seen, Robert McGibbon and Nathaniel have just >> >> > guided a PEP for multi-distribution Linux wheels past the approval >> >> > process over on distutils-sig: >> >> > >> >> > https://www.python.org/dev/peps/pep-0513/ >> >> > >> >> > The PEP includes a docker image on which y'all can build wheels which >> >> > match the PEP: >> >> > >> >> > https://quay.io/repository/manylinux/manylinux >> >> >> >> This is the wrong repository :-) It moved, and there are two now: >> >> >> >> quay.io/pypa/manylinux1_x86_64 >> >> quay.io/pypa/manylinux1_i686 >> > >> > >> > I'm going to put out 1.11.0b3 today. What would be the best thing to do >> > for >> > testing? >> >> I'd say, don't worry about building linux wheels as part of the >> release cycle yet -- it'll still be a bit before they're allowed on >> pypi or pip will recognize the new special tag. So for now you can >> leave it to Matthew or someone to build test images and stick them up >> on a server somewhere, same as before :-) > > > Should I try putting the sources up on pypi? Not specifically for manylinux - my current build recipe uses git in any case: https://github.com/matthew-brett/manylinux-builds/blob/master/build_numpies.sh Cheers, Matthew From njs at pobox.com Sun Feb 7 19:17:46 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 7 Feb 2016 16:17:46 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Feb 7, 2016 15:27, "Charles R Harris" wrote: > > > > On Sun, Feb 7, 2016 at 2:16 PM, Nathaniel Smith wrote: >> >> On Sun, Feb 7, 2016 at 9:49 AM, Charles R Harris >> wrote: >> > >> > >> > On Sun, Feb 7, 2016 at 3:40 AM, Nathaniel Smith wrote: >> >> >> >> On Feb 6, 2016 12:27 PM, "Matthew Brett" wrote: >> >> > >> >> > Hi, >> >> > >> >> > As some of you may have seen, Robert McGibbon and Nathaniel have just >> >> > guided a PEP for multi-distribution Linux wheels past the approval >> >> > process over on distutils-sig: >> >> > >> >> > https://www.python.org/dev/peps/pep-0513/ >> >> > >> >> > The PEP includes a docker image on which y'all can build wheels which >> >> > match the PEP: >> >> > >> >> > https://quay.io/repository/manylinux/manylinux >> >> >> >> This is the wrong repository :-) It moved, and there are two now: >> >> >> >> quay.io/pypa/manylinux1_x86_64 >> >> quay.io/pypa/manylinux1_i686 >> > >> > >> > I'm going to put out 1.11.0b3 today. What would be the best thing to do for >> > testing? >> >> I'd say, don't worry about building linux wheels as part of the >> release cycle yet -- it'll still be a bit before they're allowed on >> pypi or pip will recognize the new special tag. So for now you can >> leave it to Matthew or someone to build test images and stick them up >> on a server somewhere, same as before :-) > > > Should I try putting the sources up on pypi? +1 -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Mon Feb 8 01:15:13 2016 From: njs at pobox.com (Nathaniel Smith) Date: Sun, 7 Feb 2016 22:15:13 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On Sat, Feb 6, 2016 at 9:28 PM, Nadav Horesh wrote: > Test platform: python 3.4.1 on archlinux x86_64 > > scipy test: OK > > OK (KNOWNFAIL=97, SKIP=1626) > > > numpy tests: Failed on long double and int128 tests, and got one error: Could you post the complete output from the test suite somewhere? (Maybe gist.github.com) -n -- Nathaniel J. Smith -- https://vorpus.org From davidmenhur at gmail.com Mon Feb 8 06:29:58 2016 From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=) Date: Mon, 8 Feb 2016 12:29:58 +0100 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: On 6 February 2016 at 21:26, Matthew Brett wrote: > > pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy > python -c 'import numpy; numpy.test()' > python -c 'import scipy; scipy.test()' > All the tests pass on my Fedora 23 with Python 2.7, but it seems to be linking to the system openblas: numpy.show_config() lapack_opt_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c blas_opt_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c openblas_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c openblas_lapack_info: libraries = ['openblas'] library_dirs = ['/usr/local/lib'] define_macros = [('HAVE_CBLAS', None)] language = c blas_mkl_info: NOT AVAILABLE I can also reproduce Ogrisel's segfault. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Feb 8 13:21:19 2016 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 8 Feb 2016 10:21:19 -0800 Subject: [SciPy-Dev] [Numpy-discussion] Multi-distribution Linux wheels - please test In-Reply-To: References: Message-ID: Hi, On Mon, Feb 8, 2016 at 3:29 AM, Da?id wrote: > > On 6 February 2016 at 21:26, Matthew Brett wrote: >> >> >> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy >> python -c 'import numpy; numpy.test()' >> python -c 'import scipy; scipy.test()' > > > > All the tests pass on my Fedora 23 with Python 2.7, but it seems to be > linking to the system openblas: > > numpy.show_config() > lapack_opt_info: > libraries = ['openblas'] > library_dirs = ['/usr/local/lib'] > define_macros = [('HAVE_CBLAS', None)] > language = c numpy.show_config() shows the places that numpy found the libraries at build time. In the case of the manylinux wheel builds, I put openblas at /usr/local , but the place the wheel should be loading openblas from is /.libs. For example, I think you'll find that the numpy tests will still pass if you remove any openblas installation at /usr/local . Thanks for testing by the way, Matthew From ralf.gommers at gmail.com Tue Feb 9 16:15:02 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 9 Feb 2016 22:15:02 +0100 Subject: [SciPy-Dev] anyone for PyData Amsterdam? Message-ID: Hi all, There's a PyData conference in Amsterdam coming up next month (12-13 March), which I think hasn't been advertised on this list yet. That's around the corner for me, so I'll be there. Anyone else going? Would be great to meet up with some other Scipy contributors. Also, the call for proposals is still open: http://pydata.org/amsterdam2016/cfp/ Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Feb 9 21:09:51 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 9 Feb 2016 19:09:51 -0700 Subject: [SciPy-Dev] NumPy 1.11.0b3 released. Message-ID: Hi All, I'm pleased to announce the release of NumPy 1.11.0b3. This beta contains additional bug fixes as well as limiting the number of FutureWarnings raised by assignment to masked array slices. One issue that remains to be decided is whether or not to postpone raising an error for floats used as indexes. Sources may be found on Sourceforge and both sources and OS X wheels are availble on pypi. Please test, hopefully this will be that last beta needed. As a note on problems encountered, twine uploads continue to fail for me, but there are still variations to try. The wheeluploader downloaded wheels as it should, but could not upload them, giving the error message "HTTPError: 413 Client Error: Request Entity Too Large for url: https://www.python.org/pypi". Firefox also complains that http://wheels.scipy.org is incorrectly configured with an invalid certificate. Enjoy, Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From amankumarsingh17 at gmail.com Thu Feb 11 06:18:50 2016 From: amankumarsingh17 at gmail.com (aman kumar singh) Date: Thu, 11 Feb 2016 16:48:50 +0530 Subject: [SciPy-Dev] Participation as Developer fro SciPy Message-ID: Developers, I am Aman Kumar Singh,Senior Year,NIT Mizoram,India(Computer Science and Engineering).I am new to open source development. I like coding especially in Python and C++.I have 3 years of working experience in Python.I am very much interested in contributing to open source development especially in SciPy.I want to apply for Google Summer of Code 2016 in future.Can somebody help me out.I am ready to dedicate my full time to it once I get aware of the system fixing bugs and further contributing to big projects. I am left with very less time for GSoC and this time I want to be part of it.Please help me out. Thanking you, Aman Kumar Singh, NIT Mizoram, India -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeklant at gmail.com Thu Feb 11 17:29:41 2016 From: aeklant at gmail.com (Abraham Escalante) Date: Thu, 11 Feb 2016 17:29:41 -0500 Subject: [SciPy-Dev] Participation as Developer fro SciPy In-Reply-To: References: Message-ID: Hi Aman, Here is a post I wrote a few months ago (while I was participating in the GSoC 2015). I think you might find it useful. https://mail.scipy.org/pipermail/scipy-dev/2015-July/020855.html Cheers, Abraham 2016-02-11 6:18 GMT-05:00 aman kumar singh : > Developers, > > I am Aman Kumar Singh,Senior Year,NIT Mizoram,India(Computer Science > and Engineering).I am new to open source development. I like coding > especially in Python and C++.I have 3 years of working experience in > Python.I am very much interested in contributing to open source development > especially in SciPy.I want to apply for Google Summer of Code 2016 in > future.Can somebody help me out.I am ready to dedicate my full time to it > once I get aware of the system fixing bugs and further contributing to big > projects. > I am left with very less time for GSoC and this time I want to be > part of it.Please help me out. > > Thanking you, > Aman Kumar Singh, > NIT Mizoram, > India > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gilles.aouizerate at gmail.com Sat Feb 13 11:21:29 2016 From: gilles.aouizerate at gmail.com (Gilles Aouizerate) Date: Sat, 13 Feb 2016 17:21:29 +0100 Subject: [SciPy-Dev] ENH: addition of Rankine conversions in constants #5292 Message-ID: Hello Scipy developers, I recently committed a little enhancement of the scipy.constants module that dealt with temperature conversions between the Rankine scale and other scales (see #5292). It seems to me that this capability would be useful since many scientists and engineers (sadly) keep using the Rankine temperature scale, especially in thermodynamics. Rgommers answered that this was not a bad idea in principle, but that it would make the code kind of too heavy: too many temperature conversion functions in the module. Therefore he suggested adding a single function of the kind convert_temperature(value, old_scale, new_scale) rather than the several current functions. What do you think about that? If there is a consensus I could take care of that. cheers, Gilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfoxrabinovitz at gmail.com Sat Feb 13 13:55:48 2016 From: jfoxrabinovitz at gmail.com (Joseph Fox-Rabinovitz) Date: Sat, 13 Feb 2016 13:55:48 -0500 Subject: [SciPy-Dev] ENH: addition of Rankine conversions in constants #5292 In-Reply-To: References: Message-ID: That looks like a good idea. The multitude of old conversion functions could be either absorbed or made private that way. On Sat, Feb 13, 2016 at 11:21 AM, Gilles Aouizerate wrote: > Hello Scipy developers, > > I recently committed a little enhancement of the scipy.constants module that > dealt with temperature conversions between the Rankine scale and other > scales (see #5292). It seems to me that this capability would be useful > since many scientists and engineers (sadly) keep using the Rankine > temperature scale, especially in thermodynamics. > > Rgommers answered that this was not a bad idea in principle, but that it > would make the code kind of too heavy: too many temperature conversion > functions in the module. Therefore he suggested adding a single function of > the kind convert_temperature(value, old_scale, new_scale) rather than the > several current functions. > > What do you think about that? If there is a consensus I could take care of > that. > > cheers, > > Gilles > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > From tony at kelman.net Sun Feb 14 09:28:32 2016 From: tony at kelman.net (Tony Kelman) Date: Sun, 14 Feb 2016 14:28:32 +0000 (UTC) Subject: [SciPy-Dev] Docker images for cross compilation [was: win32 binaries and scipy 0.17.0 release] References: Message-ID: Matthew Brett gmail.com> writes: > > I could work through an example of this, maybe pick a Linux > > distribution to build from and a library to build and we could > > put together a Docker container that would have all the steps to > > produce a Windows DLL. > > That docker container would be extremely useful - what can I do to help? I was working on getting LLVM to cross-compile with cmake recently and threw together a couple of dockerfiles to start with at https://github.com/tkelman/docker-mingw LLVM is kind of a monster and unless you're working on Numba maybe not so relevant for you, but we can adjust these to other host distro and library combinations. Once mingwpy is ready I imagine we could make a project on the opensuse build service really easily that includes Carl's patches so you would just have to do the zypper equivalent of add-apt-repository in the not-yet-written Dockerfile.opensuse to get a cross-compiler version of mingwpy. I guess koji or launchpad could also work but I've used the opensuse build service before and it's pretty easy. I'd be happy to meet up somewhere around Berkeley and hack on this for an afternoon if we can find a time that works for multiple people. -Tony From tyler.je.reddy at gmail.com Sun Feb 14 11:43:18 2016 From: tyler.je.reddy at gmail.com (Tyler Reddy) Date: Sun, 14 Feb 2016 16:43:18 +0000 Subject: [SciPy-Dev] ENH: spherical Voronoi diagrams #5232 Message-ID: Hello, Nikolai and I have done the best we can with this pull request ( https://github.com/scipy/scipy/pull/5232). As it adds an entirely new functionality, an extra set of eyes to look it over would be much appreciated. The test coverage is > 90% and a large number of maintainer requests have been satisfied since Sept. 2015. One of the biggest challenges with the spherical Voronoi diagram on a sphere algorithm addition is the apparent lack of open source alternative implementations--this simultaneously increases the value of the contribution and makes it more difficult to verify its quality. Also, I think the mailing list may have been having issues when the initial emails were sent out. Thanks a lot! Tyler -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nicolas.Rougier at inria.fr Sun Feb 14 16:25:35 2016 From: Nicolas.Rougier at inria.fr (Nicolas P. Rougier) Date: Sun, 14 Feb 2016 22:25:35 +0100 Subject: [SciPy-Dev] ENH: spherical Voronoi diagrams #5232 In-Reply-To: References: Message-ID: <8CB8A5DB-50E3-47AD-8292-23ACB0BFE48E@inria.fr> Great work ! I could not resists and I had to test it. From my (naive) visual tests, it seems pretty good but I'm not a specialist: http://www.labri.fr/perso/nrougier/tmp/spherical-voronoi-1.png http://www.labri.fr/perso/nrougier/tmp/spherical-voronoi-2.png I tried different sizes (screenshots above use 5000 points) but not the degenerate cases. (Sources available from glumpy: https://github.com/glumpy/glumpy/blob/master/examples/spherical-voronoi.py) Nicolas > On 14 Feb 2016, at 17:43, Tyler Reddy wrote: > > Hello, > > Nikolai and I have done the best we can with this pull request (https://github.com/scipy/scipy/pull/5232). As it adds an entirely new functionality, an extra set of eyes to look it over would be much appreciated. The test coverage is > 90% and a large number of maintainer requests have been satisfied since Sept. 2015. > > One of the biggest challenges with the spherical Voronoi diagram on a sphere algorithm addition is the apparent lack of open source alternative implementations--this simultaneously increases the value of the contribution and makes it more difficult to verify its quality. > > Also, I think the mailing list may have been having issues when the initial emails were sent out. > > Thanks a lot! > Tyler > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev From orion at cora.nwra.com Mon Feb 15 12:33:59 2016 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 15 Feb 2016 10:33:59 -0700 Subject: [SciPy-Dev] ANN: scipy 0.17.0 release In-Reply-To: References: Message-ID: <56C20C07.3080404@cora.nwra.com> On 01/23/2016 05:51 AM, Evgeni Burovski wrote: > Hi, > > On behalf of the Scipy development team I am pleased to announce the > availability of Scipy 0.17.0. This release contains several new features, > detailed in the release notes below. 101 people contributed to this > release over the course of six months. > > This release requires Python 2.6, 2.7 or 3.2-3.4 and NumPy 1.6.2 or > greater. Source tarballs and release notes can be found at > https://github.com/scipy/scipy/releases/tag/v0.17.0. I'll note that http://www.scipy.org/scipylib/download.html#official-source-and-binary-releases still points to the sourceforge site which does not appear to be updated. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From evgeny.burovskiy at gmail.com Mon Feb 15 14:22:08 2016 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Mon, 15 Feb 2016 19:22:08 +0000 Subject: [SciPy-Dev] ANN: scipy 0.17.0 release In-Reply-To: <56C20C07.3080404@cora.nwra.com> References: <56C20C07.3080404@cora.nwra.com> Message-ID: > I'll note that > http://www.scipy.org/scipylib/download.html#official-source-and-binary-releases > still points to the sourceforge site which does not appear to be updated. Thanks Orion, https://github.com/scipy/scipy.org/pull/143 From eran.hof at gmail.com Wed Feb 17 04:54:13 2016 From: eran.hof at gmail.com (Eran Hof) Date: Wed, 17 Feb 2016 11:54:13 +0200 Subject: [SciPy-Dev] Q-function Message-ID: Dear scipy devs If I may suggest, there is an interest in adding a new error function to the scipy special functions. The Q-function (see please, https://en.wikipedia.org/wiki/Q-function). This function is of great interest and much in use within the communication engineering and error correcting coding communities. There is a 1:1 mapping from Q-function to erf function. However, in engineering, in contrast to statistics, most text book use the Q-function instead and this is the very first function a new to python engineer will try to look for. Also, the implementation is so fast, as Q(x) = 0.5 - 0.5 * erf (x / sqrt(2)). So why not having this function aboard? It will be used immediately by every communication engineer that adopts the scipy instead of Matlab. Also, inverse is easily implemented as well since Qinv(y) = sqrt(2) erfinv(1-2y). I think this small contribution may be of great service. Your comments are much appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From josevinicius at iecom.org.br Wed Feb 17 06:56:29 2016 From: josevinicius at iecom.org.br (=?UTF-8?B?Sm9zw6kgVmluw61jaXVz?=) Date: Wed, 17 Feb 2016 06:56:29 -0500 Subject: [SciPy-Dev] Q-function In-Reply-To: References: Message-ID: >From the Wikipedia page, we see that the Q-function is equal to the Gaussian Survival function (scipy.stats.norm.sf) as well. CVLattes: http://lattes.cnpq.br/3267230342393209 On Wed, Feb 17, 2016 at 4:54 AM, Eran Hof wrote: > Dear scipy devs > > If I may suggest, there is an interest in adding a new error function to > the scipy special functions. The Q-function (see please, > https://en.wikipedia.org/wiki/Q-function). This function is of great > interest and much in use within the communication engineering and error > correcting coding communities. > > There is a 1:1 mapping from Q-function to erf function. However, in > engineering, in contrast to statistics, most text book use the Q-function > instead and this is the very first function a new to python engineer will > try to look for. > > Also, the implementation is so fast, as Q(x) = 0.5 - 0.5 * erf (x / > sqrt(2)). So why not having this function aboard? It will be used > immediately by every communication engineer that adopts the scipy instead > of Matlab. > > Also, inverse is easily implemented as well since Qinv(y) = sqrt(2) > erfinv(1-2y). > > I think this small contribution may be of great service. > > Your comments are much appreciated. Thanks. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eran.hof at gmail.com Wed Feb 17 09:02:35 2016 From: eran.hof at gmail.com (Eran Hof) Date: Wed, 17 Feb 2016 16:02:35 +0200 Subject: [SciPy-Dev] Q-function In-Reply-To: References: Message-ID: Thanks Jose for your kind message. Indeed you are right. However, if there is a place for erf definition in the special functions of scipy, why not the Q thing? Even if not, maybe there is a place to add a note in the documentations. The trivial thing one new to scipy will do is to search for Q-function and then if not for erf or erfc. At least, this would be done by an immigrant from Matlab. I am rather new to scipy and just now learned from you the gizmo of the norm object (a really cool one, thanks a lot for your message). I must add that even in stackoverflow when searching for Q function in python I did not tackle with these sf and isf methods (maybe I'll post a question and you'll post the answer :-)). On Wed, Feb 17, 2016 at 1:56 PM, Jos? Vin?cius wrote: > From the Wikipedia page, we see that the Q-function is equal to the > Gaussian Survival function (scipy.stats.norm.sf) as well. > > CVLattes: http://lattes.cnpq.br/3267230342393209 > > On Wed, Feb 17, 2016 at 4:54 AM, Eran Hof wrote: > >> Dear scipy devs >> >> If I may suggest, there is an interest in adding a new error function to >> the scipy special functions. The Q-function (see please, >> https://en.wikipedia.org/wiki/Q-function). This function is of great >> interest and much in use within the communication engineering and error >> correcting coding communities. >> >> There is a 1:1 mapping from Q-function to erf function. However, in >> engineering, in contrast to statistics, most text book use the Q-function >> instead and this is the very first function a new to python engineer will >> try to look for. >> >> Also, the implementation is so fast, as Q(x) = 0.5 - 0.5 * erf (x / >> sqrt(2)). So why not having this function aboard? It will be used >> immediately by every communication engineer that adopts the scipy instead >> of Matlab. >> >> Also, inverse is easily implemented as well since Qinv(y) = sqrt(2) >> erfinv(1-2y). >> >> I think this small contribution may be of great service. >> >> Your comments are much appreciated. Thanks. >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> https://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goelakash.i.am at gmail.com Wed Feb 17 09:27:06 2016 From: goelakash.i.am at gmail.com (Akash Goel) Date: Wed, 17 Feb 2016 19:57:06 +0530 Subject: [SciPy-Dev] Q-function Message-ID: Maybe a mention of Q-function to the documentation of scipy.stats.norm.sf can be added (if its that important)? >>From the Wikipedia page, we see that the Q-function is equal to the Gaussian Survival function (scipy.stats.norm.sf) as well. >CVLattes: http://lattes.cnpq.br/3267230342393209 >>On Wed, Feb 17, 2016 at 4:54 AM, Eran Hof wrote: >> Dear scipy devs >> >> If I may suggest, there is an interest in adding a new error function to >> the scipy special functions. The Q-function (see please, >> https://en.wikipedia.org/wiki/Q-function). This function is of great >> interest and much in use within the communication engineering and error >> correcting coding communities. >> >> There is a 1:1 mapping from Q-function to erf function. However, in >> engineering, in contrast to statistics, most text book use the Q-function >> instead and this is the very first function a new to python engineer will >> try to look for. >> >> Also, the implementation is so fast, as Q(x) = 0.5 - 0.5 * erf (x / >> sqrt(2)). So why not having this function aboard? It will be used >> immediately by every communication engineer that adopts the scipy instead >> of Matlab. >> >> Also, inverse is easily implemented as well since Qinv(y) = sqrt(2) >> erfinv(1-2y). >> >> I think this small contribution may be of great service. >> >> Your comments are much appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesnwoods at gmail.com Wed Feb 17 09:28:27 2016 From: charlesnwoods at gmail.com (Nathan Woods) Date: Wed, 17 Feb 2016 07:28:27 -0700 Subject: [SciPy-Dev] New multidimensional integration package available in scikits Message-ID: I'd like to announce the availability of CyCuba, a Python wrapper?? to the Cuba library for multidimensional integration. The numerical evaluation of integrals is largely a solved problem these days, usually through the use of adaptive quadrature such as that found in Quadpack and other libraries. For multi-dimensional integrals, the solution has traditionally been to use iterated one-dimensional quadrature rules, but the costs associated with these can be prohibitively high, even in moderate (3-7) dimensions. The Cuba library (http://www.feynarts.de/cuba/?) implements several different deterministic and Monte Carlo algorithms for more efficient evaluation of multidimensional integrals, and is available under the GNU LGPL. CyCuba is a BSD-licensed Cython wrapper that provides access to the Cuba library from Python. It is my hope that this scikit will be useful to others who run into difficulties efficiently evaluating multidimensional integrals. If possible, I'd also like to include a reference to this project in the documentation for scipy.integrate.nquad. I'd love to get community involvement and feedback on this, as I think that a more-scalable, robust tool for multidimensional integration is needed in the scientific python community. The repository is located at https://github.com/scikit-cycuba/scikit-cycuba. Please check it out, and let me know what you think. Thanks, Nathan Woods -------------- next part -------------- An HTML attachment was scrubbed... URL: From eran.hof at gmail.com Wed Feb 17 09:57:21 2016 From: eran.hof at gmail.com (Eran Hof) Date: Wed, 17 Feb 2016 16:57:21 +0200 Subject: [SciPy-Dev] Q-function In-Reply-To: References: Message-ID: Enough people devoted plenty of their time to write papers about it: http://ieeexplore.ieee.org/search/searchresult.jsp?queryText=.QT.Q%20function.QT.&newsearch=true so I guess, a little comment in the documentation is in place. Adding to that, as said for Matlab immigrants, it be nice that when searching this function in scipy they'll get something. On Wed, Feb 17, 2016 at 4:27 PM, Akash Goel wrote: > Maybe a mention of Q-function to the documentation of scipy.stats.norm.sf > can be added (if its that important)? > > >>From the Wikipedia page, we see that the Q-function is equal to the > Gaussian Survival function (scipy.stats.norm.sf) as well. > > >CVLattes: http://lattes.cnpq.br/3267230342393209 > > >>On Wed, Feb 17, 2016 at 4:54 AM, Eran Hof wrote: > > >> Dear scipy devs > >> > >> If I may suggest, there is an interest in adding a new error function to > >> the scipy special functions. The Q-function (see please, > >> https://en.wikipedia.org/wiki/Q-function). This function is of great > >> interest and much in use within the communication engineering and error > >> correcting coding communities. > >> > >> There is a 1:1 mapping from Q-function to erf function. However, in > >> engineering, in contrast to statistics, most text book use the > Q-function > >> instead and this is the very first function a new to python engineer > will > >> try to look for. > >> > >> Also, the implementation is so fast, as Q(x) = 0.5 - 0.5 * erf (x / > >> sqrt(2)). So why not having this function aboard? It will be used > >> immediately by every communication engineer that adopts the scipy > instead > >> of Matlab. > >> > >> Also, inverse is easily implemented as well since Qinv(y) = sqrt(2) > >> erfinv(1-2y). > >> > >> I think this small contribution may be of great service. > >> > >> Your comments are much appreciated. Thanks. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Wed Feb 17 10:22:47 2016 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 17 Feb 2016 15:22:47 +0000 Subject: [SciPy-Dev] Q-function In-Reply-To: References: Message-ID: On Wed, Feb 17, 2016 at 2:57 PM, Eran Hof wrote: > > Enough people devoted plenty of their time to write papers about it: http://ieeexplore.ieee.org/search/searchresult.jsp?queryText=.QT.Q%20function.QT.&newsearch=true > > so I guess, a little comment in the documentation is in place. Adding to that, as said for Matlab immigrants, it be nice that when searching this function in scipy they'll get something. Absolutely, please do add this to the documentation. Documenting common aliases is greatly appreciated. To answer your question about why erf() but not Q, erf() is essentially the most normalized form of this function, so it can be implemented efficiently and numerically accurately more easily than Q directly. But once implemented, it is a good building block to implement the other variants like the Q function. You may then ask, quite astutely, why we also have erfc() which is just 1-erf(). The answer is that for different values, you want to use one or another approximation. In some regions, erfc() is implemented to call 1-erf(). In other regions, erf() is implemented to call 1-erfc()! They have disjoint regions in which their approximation is numerically accurate. Our underlying special function library implements both for this reason. It was easier just to expose both in scipy.special. Otherwise, I would also not feel particularly compelled to expose an erfc() even though it is also commonly encountered in the literature. -- Robert Kern -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Feb 18 08:31:22 2016 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 18 Feb 2016 15:31:22 +0200 Subject: [SciPy-Dev] Pull request workflow Message-ID: Hi, Just a quick comment on pull request workflow on scipy: - there's a "needs-work" label for PRs that have specific actionable changes required before OK for merging - there's a "needs-decision" label for PRs that are stalled on a design decision Unfortunately, Github UI does not indicate when new commits are added to PRs, potentially invalidating the "needs-work" label. It's also unrealistic to expect that the ~30 mails Github spews daily are read through and the labels updated manually. Luckily, with some scripting the relevant information on PRs with new commits and the labeling times can be retrieved from Github API. There's an automatic list here, provided on an as-is basis: https://pav.iki.fi/scipy-needs-work/ (Currently there are none, since I just went through them.) -- Pauli Virtanen From ralf.gommers at gmail.com Sun Feb 21 06:05:31 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 21 Feb 2016 12:05:31 +0100 Subject: [SciPy-Dev] removing pure python KDTree implementation Message-ID: Hi all, For a long time we've had both a Python (KDTree) and a Cython/C++ (cKDTree) version of a k-d tree structure in scipy.spatial. The cKDTree version reached feature-parity with KDTree in 0.12.0, and new features are being added regularly now. So keeping the orders of magnitude slower pure Python version seems to be a bit pointless - only adds to a maintenance burden and to giving users an unnecessary choice to make. So proposal: remove the pure Python code and make KDTree an alias for cKDTree. This can be done straight away. For the future it may also be desirable to get rid of the duplicate name. The issue then is which one to keep. KDTree is nicer, but it would require users who have picked the fast version now to change their code. So maybe just deprecate one in documentation, but keep both names working? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Feb 21 07:14:19 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 21 Feb 2016 13:14:19 +0100 Subject: [SciPy-Dev] Pull request workflow In-Reply-To: References: Message-ID: On Thu, Feb 18, 2016 at 2:31 PM, Pauli Virtanen wrote: > Hi, > > Just a quick comment on pull request workflow on scipy: > > - there's a "needs-work" label for PRs that have specific actionable > changes required before OK for merging > > - there's a "needs-decision" label for PRs that are stalled on a design > decision > > Unfortunately, Github UI does not indicate when new commits are added to > PRs, potentially invalidating the "needs-work" label. It's also > unrealistic to expect that the ~30 mails Github spews daily are read > through and the labels updated manually. > > Luckily, with some scripting the relevant information on PRs with new > commits and the labeling times can be retrieved from Github API. There's > an automatic list here, provided on an as-is basis: > https://pav.iki.fi/scipy-needs-work/ > (Currently there are none, since I just went through them.) > Quite useful, thanks Pauli! Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Sun Feb 21 08:41:56 2016 From: sturla.molden at gmail.com (Sturla Molden) Date: Sun, 21 Feb 2016 13:41:56 +0000 (UTC) Subject: [SciPy-Dev] removing pure python KDTree implementation References: Message-ID: <987688565477754463.585439sturla.molden-gmail.com@news.gmane.org> Ralf Gommers wrote: > Hi all, > > For a long time we've had both a Python (KDTree) and a Cython/C++ (cKDTree) > version of a k-d tree structure in scipy.spatial. The cKDTree version > reached feature-parity with KDTree in 0.12.0, and new features are being > added regularly now. So keeping the orders of magnitude slower pure Python > version seems to be a bit pointless - only adds to a maintenance burden and > to giving users an unnecessary choice to make. > > So proposal: remove the pure Python code and make KDTree an alias for > cKDTree. This can be done straight away. > > For the future it may also be desirable to get rid of the duplicate name. > The issue then is which one to keep. KDTree is nicer, but it would require > users who have picked the fast version now to change their code. So maybe > just deprecate one in documentation, but keep both names working? What about this? 1. make KDTree an alias for cKDTree 2. make KDTreeNode an alias for cKDTreeNode 3. keep all names working 4. only have KDTree and KDTreeNode in the documentation 5. keep kdtree.py for the test suite, but do not export its contents Sturla From ralf.gommers at gmail.com Sun Feb 21 18:11:14 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Feb 2016 00:11:14 +0100 Subject: [SciPy-Dev] welcome Eric Larson and Ian Henriksen to core team Message-ID: Hi all, On behalf of the Scipy developers I'd like to welcome Eric Larson and Ian Henriksen as members of the core dev team. Eric has been contributing for ~1.5 years, mostly to scipy.signal. He recently added upfirdn and polyphase resampling, and was one of the authors of the marathon PR on second-order-sections filtering (gh-3717). Ian has also been contributing for ~1.5 years, mostly to scipy.linalg. He is the author of the Cython API for BLAS/LAPACK. I'm looking forward to their continued contributions! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Sun Feb 21 20:37:46 2016 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 21 Feb 2016 20:37:46 -0500 Subject: [SciPy-Dev] welcome Eric Larson and Ian Henriksen to core team In-Reply-To: References: Message-ID: Welcome Eric and Ian! Thanks for your contributions so far; looking forward to many more. Warren On Sun, Feb 21, 2016 at 6:11 PM, Ralf Gommers wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Eric Larson and Ian > Henriksen as members of the core dev team. > > Eric has been contributing for ~1.5 years, mostly to scipy.signal. He > recently added upfirdn and polyphase resampling, and was one of the authors > of the marathon PR on second-order-sections filtering (gh-3717). > > Ian has also been contributing for ~1.5 years, mostly to scipy.linalg. He > is the author of the Cython API for BLAS/LAPACK. > > I'm looking forward to their continued contributions! > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Mon Feb 22 05:06:36 2016 From: rmcgibbo at gmail.com (Robert T. McGibbon) Date: Mon, 22 Feb 2016 02:06:36 -0800 Subject: [SciPy-Dev] welcome Eric Larson and Ian Henriksen to core team In-Reply-To: References: Message-ID: Great news! Congratulations all around. -Robert On Sun, Feb 21, 2016 at 5:37 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > Welcome Eric and Ian! Thanks for your contributions so far; looking > forward to many more. > > Warren > > > On Sun, Feb 21, 2016 at 6:11 PM, Ralf Gommers > wrote: > >> Hi all, >> >> On behalf of the Scipy developers I'd like to welcome Eric Larson and >> Ian Henriksen as members of the core dev team. >> >> Eric has been contributing for ~1.5 years, mostly to scipy.signal. He >> recently added upfirdn and polyphase resampling, and was one of the authors >> of the marathon PR on second-order-sections filtering (gh-3717). >> >> Ian has also been contributing for ~1.5 years, mostly to scipy.linalg. He >> is the author of the Cython API for BLAS/LAPACK. >> >> I'm looking forward to their continued contributions! >> >> Cheers, >> Ralf >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> https://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -- -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From shashankgandham at gmail.com Mon Feb 22 12:15:46 2016 From: shashankgandham at gmail.com (Shashank Gandham) Date: Mon, 22 Feb 2016 22:45:46 +0530 Subject: [SciPy-Dev] Where do I start? Message-ID: I am interested in contributing to numpy, I have never contributed to an open source project. How do I start? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gfyoung17 at gmail.com Mon Feb 22 12:38:51 2016 From: gfyoung17 at gmail.com (G Young) Date: Mon, 22 Feb 2016 17:38:51 +0000 Subject: [SciPy-Dev] Where do I start? In-Reply-To: References: Message-ID: First of all, awesome that you want to contribute! I myself am a relatively new contributor to NumPy, so I understand it can be a little scary to join a project as large as that! Here's what you should do: 1) Join the correct mailing lists. You emailed out to the SciPy mailing list by accident it seems. You can visit this link here to join the numpy-svn and numpy-discussion mailing lists. 2) Visit this link here and follow the links in that document to get more information about contributing! It provides an excellent overview on how to get started! If you have any other questions, feel free to post them on the numpy-discussion! Cheers, Greg On Mon, Feb 22, 2016 at 5:15 PM, Shashank Gandham wrote: > I am interested in contributing to numpy, I have never contributed to an > open source project. How do I start? > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Feb 22 16:18:48 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Feb 2016 22:18:48 +0100 Subject: [SciPy-Dev] removing pure python KDTree implementation In-Reply-To: <987688565477754463.585439sturla.molden-gmail.com@news.gmane.org> References: <987688565477754463.585439sturla.molden-gmail.com@news.gmane.org> Message-ID: On Sun, Feb 21, 2016 at 2:41 PM, Sturla Molden wrote: > Ralf Gommers wrote: > > Hi all, > > > > For a long time we've had both a Python (KDTree) and a Cython/C++ > (cKDTree) > > version of a k-d tree structure in scipy.spatial. The cKDTree version > > reached feature-parity with KDTree in 0.12.0, and new features are being > > added regularly now. So keeping the orders of magnitude slower pure > Python > > version seems to be a bit pointless - only adds to a maintenance burden > and > > to giving users an unnecessary choice to make. > > > > So proposal: remove the pure Python code and make KDTree an alias for > > cKDTree. This can be done straight away. > > > > For the future it may also be desirable to get rid of the duplicate name. > > The issue then is which one to keep. KDTree is nicer, but it would > require > > users who have picked the fast version now to change their code. So maybe > > just deprecate one in documentation, but keep both names working? > > > What about this? > > 1. make KDTree an alias for cKDTree > 2. make KDTreeNode an alias for cKDTreeNode > 3. keep all names working > 4. only have KDTree and KDTreeNode in the documentation > 5. keep kdtree.py for the test suite, but do not export its contents > That sounds good to me. Keeping the Python version as a fancy test class may be useful. The only thing that we should probably provide is a robust version comparator (anyway a good idea), so users can write this in a robust way: if scipy_version >= (0, 18, 0): KDTree() else: cKDTree() Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtaylor.debian at googlemail.com Mon Feb 22 16:39:30 2016 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Mon, 22 Feb 2016 22:39:30 +0100 Subject: [SciPy-Dev] removing pure python KDTree implementation In-Reply-To: References: <987688565477754463.585439sturla.molden-gmail.com@news.gmane.org> Message-ID: <56CB8012.5070407@googlemail.com> On 22.02.2016 22:18, Ralf Gommers wrote: > > > On Sun, Feb 21, 2016 at 2:41 PM, Sturla Molden > wrote: > > Ralf Gommers > wrote: > > Hi all, > > > > For a long time we've had both a Python (KDTree) and a Cython/C++ (cKDTree) > > version of a k-d tree structure in scipy.spatial. The cKDTree version > > reached feature-parity with KDTree in 0.12.0, and new features are being > > added regularly now. So keeping the orders of magnitude slower pure Python > > version seems to be a bit pointless - only adds to a maintenance burden and > > to giving users an unnecessary choice to make. > > > > So proposal: remove the pure Python code and make KDTree an alias for > > cKDTree. This can be done straight away. > > > > For the future it may also be desirable to get rid of the duplicate name. > > The issue then is which one to keep. KDTree is nicer, but it would require > > users who have picked the fast version now to change their code. So maybe > > just deprecate one in documentation, but keep both names working? > > > What about this? > > 1. make KDTree an alias for cKDTree > 2. make KDTreeNode an alias for cKDTreeNode > 3. keep all names working > 4. only have KDTree and KDTreeNode in the documentation > 5. keep kdtree.py for the test suite, but do not export its contents > > > That sounds good to me. Keeping the Python version as a fancy test class > may be useful. > > The only thing that we should probably provide is a robust version > comparator (anyway a good idea), so users can write this in a robust way: > > if scipy_version >= (0, 18, 0): > KDTree() > else: > cKDTree() > > Ralf > There is numpy.lib.NumpyVersion or scipy._lib._version.NumpyVersion which should work (and also written by you ;) ). Not sure why that is in private namespace in scipy, imo it makes sense to have that as a public alias like many other numpy functions in scipy. From ralf.gommers at gmail.com Mon Feb 22 16:39:41 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Feb 2016 22:39:41 +0100 Subject: [SciPy-Dev] welcome Andrew Nelson and Eric Quintero to core team Message-ID: Hi all, On behalf of the Scipy developers I'd like to welcome Andrew Nelson and Eric Quintero as members of the core dev team. Andrew has been contributing for ~2 years to scipy.optimize. He's the author of the differential_evolution global optimizer and adapted the ampgo testsuite functions to the benchmark suite (merged just last week) - https://github.com/scipy/scipy/pulls/andyfaff. Eric has been contributing for ~1 year to scipy.signal. He's the author of a number of the spectral analysis functions - https://github.com/scipy/scipy/pulls/e-q. I'm looking forward to their continued contributions! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Mon Feb 22 17:43:13 2016 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 22 Feb 2016 17:43:13 -0500 Subject: [SciPy-Dev] welcome Andrew Nelson and Eric Quintero to core team In-Reply-To: References: Message-ID: Welcome Eric and Andrew! Keep up the great work. Warren On Mon, Feb 22, 2016 at 4:39 PM, Ralf Gommers wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Andrew Nelson and > Eric Quintero as members of the core dev team. > > Andrew has been contributing for ~2 years to scipy.optimize. He's the > author of the differential_evolution global optimizer and adapted the ampgo > testsuite functions to the benchmark suite (merged just last week) - > https://github.com/scipy/scipy/pulls/andyfaff. > > Eric has been contributing for ~1 year to scipy.signal. He's the author of > a number of the spectral analysis functions - > https://github.com/scipy/scipy/pulls/e-q. > > I'm looking forward to their continued contributions! > > Cheers, > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Mon Feb 22 20:47:35 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Mon, 22 Feb 2016 18:47:35 -0700 Subject: [SciPy-Dev] Numpy 1.11.0rc1 released. Message-ID: Hi All, I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the issues discovered in 1.11.0b3 have been dealt with and this release can go on to become the official release. Source files and documentation can be found on Sourceforge , while source files and OS X wheels for Python 2.7, 3.3, 3.4, and 3.5 can be installed from Pypi. Please test thoroughly. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Feb 23 07:02:41 2016 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 23 Feb 2016 05:02:41 -0700 Subject: [SciPy-Dev] Numpy 1.11.0rc1 released. In-Reply-To: References: Message-ID: On Mon, Feb 22, 2016 at 6:47 PM, Charles R Harris wrote: > Hi All, > > I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the > issues discovered in 1.11.0b3 have been dealt with and this release can go > on to become the official release. Source files and documentation can be > found on Sourceforge > , while > source files and OS X wheels for Python 2.7, 3.3, 3.4, and 3.5 can be > installed from Pypi. Please test thoroughly. > Issues reported by Christoph at https://github.com/numpy/numpy/issues/7316. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidmenhur at gmail.com Tue Feb 23 10:36:29 2016 From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=) Date: Tue, 23 Feb 2016 16:36:29 +0100 Subject: [SciPy-Dev] [SciPy-User] Numpy 1.11.0rc1 released. In-Reply-To: References: Message-ID: I have tested numpy, scipy, sklearn, pandas and my own in house project. They all come out clean, with the exception of pandas, that goes from (SKIP=500, errors=3, failures=3) to (SKIP=499, errors=3, failures=9). Find output attached. The system is a Fedora 23 with Python 2.7. and GCC 5.3. On 23 February 2016 at 02:47, Charles R Harris wrote: > Hi All, > > I'm delighted to announce the release of Numpy 1.11.0rc1. Hopefully the > issues discovered in 1.11.0b3 have been dealt with and this release can go > on to become the official release. Source files and documentation can be > found on Sourceforge, while source files and OS X wheels for Python 2.7, > 3.3, 3.4, and 3.5 can be installed from Pypi. Please test thoroughly. > > Chuck > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > https://mail.scipy.org/mailman/listinfo/scipy-user > -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy10.4 Type: application/x-troff-man Size: 17937 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: numpy11 Type: application/octet-stream Size: 30770 bytes Desc: not available URL: From cimrman3 at ntc.zcu.cz Wed Feb 24 08:20:48 2016 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Wed, 24 Feb 2016 14:20:48 +0100 Subject: [SciPy-Dev] ANN: SfePy 2016.1 Message-ID: <56CDAE30.8030108@ntc.zcu.cz> I am pleased to announce release 2016.1 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 (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - major simplification of finite element field code - automatic checking of shapes of term arguments - improved mesh parametrization code and documentation - support for fieldsplit preconditioners of PETSc For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman on behalf of the SfePy development team --- Contributors to this release in alphabetical order: Robert Cimrman Vladimir Lukes From rlucente at pipeline.com Wed Feb 24 10:49:34 2016 From: rlucente at pipeline.com (Robert Lucente) Date: Wed, 24 Feb 2016 10:49:34 -0500 (GMT-05:00) Subject: [SciPy-Dev] BayesPy.Org Message-ID: <21827318.1456328974531.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> People are probably aware of BayesPy.Org but just in case. From toddrjen at gmail.com Thu Feb 25 06:07:18 2016 From: toddrjen at gmail.com (Todd) Date: Thu, 25 Feb 2016 12:07:18 +0100 Subject: [SciPy-Dev] removing pure python KDTree implementation In-Reply-To: References: <987688565477754463.585439sturla.molden-gmail.com@news.gmane.org> Message-ID: On Feb 22, 2016 10:18 PM, "Ralf Gommers" wrote: > > > > On Sun, Feb 21, 2016 at 2:41 PM, Sturla Molden wrote: >> >> Ralf Gommers wrote: >> > Hi all, >> > >> > For a long time we've had both a Python (KDTree) and a Cython/C++ (cKDTree) >> > version of a k-d tree structure in scipy.spatial. The cKDTree version >> > reached feature-parity with KDTree in 0.12.0, and new features are being >> > added regularly now. So keeping the orders of magnitude slower pure Python >> > version seems to be a bit pointless - only adds to a maintenance burden and >> > to giving users an unnecessary choice to make. >> > >> > So proposal: remove the pure Python code and make KDTree an alias for >> > cKDTree. This can be done straight away. >> > >> > For the future it may also be desirable to get rid of the duplicate name. >> > The issue then is which one to keep. KDTree is nicer, but it would require >> > users who have picked the fast version now to change their code. So maybe >> > just deprecate one in documentation, but keep both names working? >> >> >> What about this? >> >> 1. make KDTree an alias for cKDTree >> 2. make KDTreeNode an alias for cKDTreeNode >> 3. keep all names working >> 4. only have KDTree and KDTreeNode in the documentation >> 5. keep kdtree.py for the test suite, but do not export its contents > > > That sounds good to me. Keeping the Python version as a fancy test class may be useful. > > The only thing that we should probably provide is a robust version comparator (anyway a good idea), so users can write this in a robust way: > > if scipy_version >= (0, 18, 0): > KDTree() > else: > cKDTree() > > Ralf > If people want backwards compatibility, can't they just continue to use the cKDTree name? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Feb 26 15:50:00 2016 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 26 Feb 2016 21:50:00 +0100 Subject: [SciPy-Dev] PR for Scipy developers guide Message-ID: Hi all, https://github.com/scipy/scipy/pull/5424 adds a developers guide to the documentation. The PR was open for a while, but I've added some sections and hooked it up to the rest of the docs, so it's ready for review/merge. There are no proposals for changes in there, it's just documenting how we do things now. Still, it would be good to get a few pairs of eyes on it. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgodshall at enthought.com Fri Feb 26 13:11:23 2016 From: cgodshall at enthought.com (Courtenay Godshall (Enthought)) Date: Fri, 26 Feb 2016 18:11:23 -0000 Subject: [SciPy-Dev] ANN: SciPy (Scientific Python) 2016 Conference Call for Talk / Tutorial Proposals Open Until 3/25 Message-ID: <006f01d170c1$17790060$466b0120$@enthought.com> **SciPy 2016 Conference (Scientific Computing with Python) Announcement** *Call for Proposals: Submit Your Tutorial and Talk Ideas by March 25, 2015 at http://scipy2016.scipy.org. SciPy 2016, the 15th annual Scientific Computing with Python conference, will be held July 11-17, 2016 in Austin, Texas. SciPy is a community dedicated to the advancement of scientific computing through open source Python software for mathematics, science, and engineering. The annual SciPy Conference brings together over 650 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The full program will consist of 2 days of tutorials (July 11-12), 3 days of talks (July 13-15), and 2 days of developer sprints (July 16-17). More info is available on the conference website at http://scipy2016.scipy.org (where you can sign up for the mailing list); or follow @scipyconf on Twitter. We hope you'll join us - early bird registration is open until May 22, 2016 at http://scipy2016.scipy.org/ehome/146062/332936/?&& We encourage you to submit tutorial or talk proposals in the categories below; please also share with others who you'd like to see participate! Submit via the conference website: http://scipy2016.scipy.org. ---------------------------------------------------------------------------- ------------------------- *SUBMIT A SCIPY 2016 TUTORIAL PROPOSAL - DUE MARCH 21, 2016* ---------------------------------------------------------------------------- ------------------------- Details and submission here: http://scipy2016.scipy.org/ehome/146062/332967/?&& These sessions provide extremely affordable access to expert training, and consistently receive fantastic feedback from participants. We're looking for submissions on topics from introductory to advanced - we'll have attendees across the gamut looking to learn. Whether you are a major contributor to a scientific Python library or an expert-level user, this is a great opportunityto share your knowledge and stipends are available. ---------------------------------------------------------------------------- --------------------------------- **SUBMIT A SCIPY 2016 TALK / POSTER PROPOSAL - DUE MARCH 25, 2016* ---------------------------------------------------------------------------- --------------------------------- Details and submission here: http://scipy2016.scipy.org/ehome/146062/332968/?&& SciPy 2016 will include 3 major topic tracks and 8 mini-symposia tracks. Major topic tracks include: - Scientific Computing in Python - Python in Data Science (Big data and not so big data) - High Performance Computing Mini-symposia will include the applications of Python in: - Earth and Space Science - Engineering - Medicine and Biology - Social Sciences - Special Purpose Databases - Case Studies in Industry - Education - Reproducibility If you have any questions or comments, feel free to contact us at: scipy-organizers at scipy.org ----------------------------------------------------------- **SCIPY 2016 REGISTRATION IS OPEN** ----------------------------------------------------------- Please register early. SciPy early bird registration until May 22, 2016! Register at http://scipy2016.scipy.org. Plus, enter our t-shirt design contest to win a free registration. (Send a vector art file to scipy at enthought.com by March 31 to enter). -------------- next part -------------- An HTML attachment was scrubbed... URL: