From ralf.gommers at gmail.com Mon Sep 1 06:36:25 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 1 Sep 2014 12:36:25 +0200 Subject: [SciPy-Dev] EuroSciPy sprint report Message-ID: Hi all, We had a great sprint at EuroSciPy yesterday, with about 20 people working on Scipy and about 25 more on scikit-learn, scikit-image and Vispy. The result at the end of the day for Scipy was: - 24 pull requests submitted - 20 pull requests merged - 17 issues closed - 2 new issues created A couple of highlights: - Fred Ludlow implemented bitwise operations on sparse matrices (PR 3941) - Julian Taylor implemented releasing the GIL from filter and interpolation functions in ndimage (PR 3943) - Aaren O'Leary implemented API changes needed before integrating discrete wavelets into scipy (issue 3931). - Chris Kerr removed linpack_lite from scipy.integrate (PR 3916). (done right before the sprint actually, but removing 15000 lines of Fortran code is worth a mention anyway!). It was great to see a lot of new contributors as well as meet people who have been contributing for a while face-to-face. Thanks a lot to everyone who contributed, and especially to Pietro for the excellent organization! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.martinot-lagarde at m4x.org Wed Sep 3 19:51:36 2014 From: joseph.martinot-lagarde at m4x.org (Joseph Martinot-Lagarde) Date: Thu, 04 Sep 2014 01:51:36 +0200 Subject: [SciPy-Dev] 'norm' keyword for FFT functions Message-ID: I have an old PR [1] to fix #2142 [2]. The idea is to have a new keyword for all fft functions to define the normalisation of the fft: - if 'norm' is None (the default), the normalisation is the current one: fft() is not normalized ans ifft is normalized by 1/n. - if norm is "ortho", the direct and inverse transforms are both normalized by 1/sqrt(n). The results are then unitary. The keyword name and value is consistent with scipy.fftpack.dct. Do you feel that it should be merged ? Joseph [1] https://github.com/numpy/numpy/pull/3883 [2] https://github.com/numpy/numpy/issues/2142 From joseph.martinot-lagarde at m4x.org Wed Sep 3 19:58:38 2014 From: joseph.martinot-lagarde at m4x.org (Joseph Martinot-Lagarde) Date: Thu, 04 Sep 2014 01:58:38 +0200 Subject: [SciPy-Dev] Multiple comment tokens for loadtxt Message-ID: loadtxt currently has a keyword to change the comment token. The PR #4612 [1] enables to define multiple comment token for a file. It is motivated by #2633 [2] What is your position on this one ? Joseph [1] https://github.com/numpy/numpy/pull/4612 [2] https://github.com/numpy/numpy/issues/2633 From luke.pfister at gmail.com Wed Sep 3 20:44:02 2014 From: luke.pfister at gmail.com (Luke Pfister) Date: Wed, 3 Sep 2014 19:44:02 -0500 Subject: [SciPy-Dev] 'norm' keyword for FFT functions In-Reply-To: References: Message-ID: I would appreciate this- I often wind up writing a wrapper function to normalize my fft/iffts. Luke On Wed, Sep 3, 2014 at 6:51 PM, Joseph Martinot-Lagarde < joseph.martinot-lagarde at m4x.org> wrote: > I have an old PR [1] to fix #2142 [2]. The idea is to have a new keyword > for all fft functions to define the normalisation of the fft: > - if 'norm' is None (the default), the normalisation is the current one: > fft() is not normalized ans ifft is normalized by 1/n. > - if norm is "ortho", the direct and inverse transforms are both > normalized by 1/sqrt(n). The results are then unitary. > > The keyword name and value is consistent with scipy.fftpack.dct. > > Do you feel that it should be merged ? > > Joseph > > [1] https://github.com/numpy/numpy/pull/3883 > [2] https://github.com/numpy/numpy/issues/2142 > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.haessig at crans.org Thu Sep 4 04:41:47 2014 From: pierre.haessig at crans.org (Pierre Haesssig) Date: Thu, 04 Sep 2014 10:41:47 +0200 Subject: [SciPy-Dev] 'norm' keyword for FFT functions In-Reply-To: References: Message-ID: <540825CB.5050602@crans.org> Le 04/09/2014 01:51, Joseph Martinot-Lagarde a ?crit : > I have an old PR [1] to fix #2142 [2]. The idea is to have a new keyword > for all fft functions to define the normalisation of the fft: > - if 'norm' is None (the default), the normalisation is the current one: > fft() is not normalized ans ifft is normalized by 1/n. > - if norm is "ortho", the direct and inverse transforms are both > normalized by 1/sqrt(n). The results are then unitary. > Should there be a third one where fft() is normalized by 1/n ? best, Pierre From ralf.gommers at gmail.com Thu Sep 4 17:49:57 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 4 Sep 2014 23:49:57 +0200 Subject: [SciPy-Dev] Multiple comment tokens for loadtxt In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 1:58 AM, Joseph Martinot-Lagarde < joseph.martinot-lagarde at m4x.org> wrote: > loadtxt currently has a keyword to change the comment token. The PR > #4612 [1] enables to define multiple comment token for a file. It is > motivated by #2633 [2] > > What is your position on this one ? > Looks fine to me. Note that you want to ask this on the numpy mailing list, not the scipy one. Ralf > > Joseph > > [1] https://github.com/numpy/numpy/pull/4612 > [2] https://github.com/numpy/numpy/issues/2633 > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.martinot-lagarde at m4x.org Thu Sep 4 20:37:26 2014 From: joseph.martinot-lagarde at m4x.org (Joseph Martinot-Lagarde) Date: Fri, 05 Sep 2014 02:37:26 +0200 Subject: [SciPy-Dev] Multiple comment tokens for loadtxt In-Reply-To: References: Message-ID: Le 04/09/2014 23:49, Ralf Gommers a ?crit : > > > > On Thu, Sep 4, 2014 at 1:58 AM, Joseph Martinot-Lagarde > > wrote: > > loadtxt currently has a keyword to change the comment token. The PR > #4612 [1] enables to define multiple comment token for a file. It is > motivated by #2633 [2] > > What is your position on this one ? > > > Looks fine to me. > > Note that you want to ask this on the numpy mailing list, not the scipy one. > > Ralf > Oh, I thought that it was a common list. Is gmane.comp.python.numeric,general the correct one ? I can't find a list containing numpy on gmane. From joseph.martinot-lagarde at m4x.org Thu Sep 4 20:46:14 2014 From: joseph.martinot-lagarde at m4x.org (Joseph Martinot-Lagarde) Date: Fri, 05 Sep 2014 02:46:14 +0200 Subject: [SciPy-Dev] Multiple comment tokens for loadtxt In-Reply-To: References: Message-ID: Le 05/09/2014 02:37, Joseph Martinot-Lagarde a ?crit : > Le 04/09/2014 23:49, Ralf Gommers a ?crit : >> >> >> >> On Thu, Sep 4, 2014 at 1:58 AM, Joseph Martinot-Lagarde >> > > wrote: >> >> loadtxt currently has a keyword to change the comment token. The PR >> #4612 [1] enables to define multiple comment token for a file. It is >> motivated by #2633 [2] >> >> What is your position on this one ? >> >> >> Looks fine to me. >> >> Note that you want to ask this on the numpy mailing list, not the scipy one. >> >> Ralf >> > Oh, I thought that it was a common list. Is > gmane.comp.python.numeric,general the correct one ? I can't find a list > containing numpy on gmane. > Nevermind, I found the official link. From djpine at gmail.com Fri Sep 5 10:25:40 2014 From: djpine at gmail.com (David J Pine) Date: Fri, 5 Sep 2014 10:25:40 -0400 Subject: [SciPy-Dev] Introduction to Python for Science Message-ID: NumPy, SciPy, MatPlotLib Users & Science teachers: I have written an introduction to scientific python that you may find useful. You can download it from GitHub and use it freely: https://github.com/djpine/pyman I wrote this manual/book for undergraduates taking science and engineering courses that use programming to solve science and engineering problems. It is not for experts. I am sharing it with the hope that others may find it useful. It includes an introduction to very basic programming, numpy, matplotlib, & scipy, as well as instructions on how to download and install Python and these three libraries. It also includes an introduction to IPython notebooks. Corrections and suggestions for improvements are welcome. David Pine -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.otte at gmail.com Fri Sep 5 10:31:35 2014 From: stefan.otte at gmail.com (Stefan Otte) Date: Fri, 5 Sep 2014 16:31:35 +0200 Subject: [SciPy-Dev] Introduction to Python for Science In-Reply-To: References: Message-ID: Nice work! I always recommend the "Python Scientific Lecture Notes" [1] to students. Best, Stefan [1] https://scipy-lectures.github.io/ On Fri, Sep 5, 2014 at 4:25 PM, David J Pine wrote: > NumPy, SciPy, MatPlotLib Users & Science teachers: > > I have written an introduction to scientific python that you may find > useful. You can download it from GitHub and use it freely: > > https://github.com/djpine/pyman > > I wrote this manual/book for undergraduates taking science and engineering > courses that use programming to solve science and engineering problems. It > is not for experts. I am sharing it with the hope that others may find it > useful. It includes an introduction to very basic programming, > numpy,matplotlib, & scipy, as well as instructions on how to download and > install Python and these three libraries. It also includes an introduction > to IPython notebooks. > > Corrections and suggestions for improvements are welcome. > > David Pine > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From djpine at gmail.com Fri Sep 5 11:53:56 2014 From: djpine at gmail.com (David J Pine) Date: Fri, 5 Sep 2014 11:53:56 -0400 Subject: [SciPy-Dev] Introduction to Python for Science In-Reply-To: References: Message-ID: The "Python Scientific Lecture Notes" at https://scipy-lectures.github.io/ are very nice indeed, but aimed at a somewhat more programming-savvy audience. On Fri, Sep 5, 2014 at 10:31 AM, Stefan Otte wrote: > Nice work! I always recommend the "Python Scientific Lecture Notes" > [1] to students. > > Best, > Stefan > > > [1] https://scipy-lectures.github.io/ > > > > On Fri, Sep 5, 2014 at 4:25 PM, David J Pine wrote: > > NumPy, SciPy, MatPlotLib Users & Science teachers: > > > > I have written an introduction to scientific python that you may find > > useful. You can download it from GitHub and use it freely: > > > > https://github.com/djpine/pyman > > > > I wrote this manual/book for undergraduates taking science and > engineering > > courses that use programming to solve science and engineering problems. > It > > is not for experts. I am sharing it with the hope that others may find > it > > useful. It includes an introduction to very basic programming, > > numpy,matplotlib, & scipy, as well as instructions on how to download and > > install Python and these three libraries. It also includes an > introduction > > to IPython notebooks. > > > > Corrections and suggestions for improvements are welcome. > > > > David Pine > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Fri Sep 5 12:00:46 2014 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 5 Sep 2014 12:00:46 -0400 Subject: [SciPy-Dev] Introduction to Python for Science Message-ID: Is there any comprehensive list of such resources? I feel like I've seen several go by at different times, and surely at some point will want to recommend some of them to students, but by that time I'll have list track of the links, and be uncertain which resources are more appropriate for which students as well. -n On 5 Sep 2014 10:32, "Stefan Otte" wrote: Nice work! I always recommend the "Python Scientific Lecture Notes" [1] to students. Best, Stefan [1] https://scipy-lectures.github.io/ On Fri, Sep 5, 2014 at 4:25 PM, David J Pine wrote: > NumPy, SciPy, MatPlotLib Users & Science teachers: > > I have written an introduction to scientific python that you may find > useful. You can download it from GitHub and use it freely: > > https://github.com/djpine/pyman > > I wrote this manual/book for undergraduates taking science and engineering > courses that use programming to solve science and engineering problems. It > is not for experts. I am sharing it with the hope that others may find it > useful. It includes an introduction to very basic programming, > numpy,matplotlib, & scipy, as well as instructions on how to download and > install Python and these three libraries. It also includes an introduction > to IPython notebooks. > > Corrections and suggestions for improvements are welcome. > > David Pine > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > _______________________________________________ SciPy-Dev mailing list SciPy-Dev at scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Sep 5 14:33:18 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 5 Sep 2014 20:33:18 +0200 Subject: [SciPy-Dev] Introduction to Python for Science In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 6:00 PM, Nathaniel Smith wrote: > Is there any comprehensive list of such resources? I feel like I've seen > several go by at different times, and surely at some point will want to > recommend some of them to students, but by that time I'll have list track > of the links, and be uncertain which resources are more appropriate for > which students as well. > I wouldn't say it's comprehensive, but http://scipy.org/topical-software.html#tutorials-and-texts contains a selection. David's book looks like it would be a nice addition to that list. PR to https://github.com/scipy/scipy.org very welcome. Ralf -n > On 5 Sep 2014 10:32, "Stefan Otte" wrote: > > Nice work! I always recommend the "Python Scientific Lecture Notes" > [1] to students. > > Best, > Stefan > > > [1] https://scipy-lectures.github.io/ > > > > On Fri, Sep 5, 2014 at 4:25 PM, David J Pine wrote: > > NumPy, SciPy, MatPlotLib Users & Science teachers: > > > > I have written an introduction to scientific python that you may find > > useful. You can download it from GitHub and use it freely: > > > > https://github.com/djpine/pyman > > > > I wrote this manual/book for undergraduates taking science and > engineering > > courses that use programming to solve science and engineering problems. > It > > is not for experts. I am sharing it with the hope that others may find > it > > useful. It includes an introduction to very basic programming, > > numpy,matplotlib, & scipy, as well as instructions on how to download and > > install Python and these three libraries. It also includes an > introduction > > to IPython notebooks. > > > > Corrections and suggestions for improvements are welcome. > > > > David Pine > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Sep 5 15:07:53 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 5 Sep 2014 21:07:53 +0200 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule Message-ID: Hi all, It's about time for a couple of releases. 0.14.1 fixes some regressions as well as a lot of test failures against numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are fixed now, so I plan to tag it this weekend. If there's anything really urgent that still needs to go in, please speak up. For 0.15.0 there are still 17 issues/PRs, but most of those we should be able to merge/fix relatively quickly. I propose the following release schedule: - beta 1: 16 Sep - release candidate 1: 4 Oct - release candidate 2: 18 Oct (if needed) - final release: 25 Oct Does that work for everyone? Are there issues/PRs that aren't under the 0.15.0 milestone but have to go in? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaime.frio at gmail.com Fri Sep 5 16:17:09 2014 From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=) Date: Fri, 5 Sep 2014 13:17:09 -0700 Subject: [SciPy-Dev] bug in min(max)imum_filter1d Message-ID: A while back I made some changes to ndimage.filters.min(max)imum_filter1d that sped it up quite considerably, see here: https://github.com/scipy/scipy/pull/3517 A little after that, I started a discussion on whether a different algorithm, about 30% slower for random inputs, but up to 10x faster for worse case inputs, would be a better option, and submitted a new PR, see here: http://mail.scipy.org/pipermail/scipy-dev/2014-April/019776.html https://github.com/scipy/scipy/pull/3527 I didn't follow up on that discussion, and so #3527 had been lingering abandoned ever since. Recently, Julian Taylor discovered that #3517 breaks the scikit-image tests, because it does not handle properly the case with a filter of size 1, see here: https://github.com/scipy/scipy/issues/3898 Rather than fixing the existing code merged in #3517, I have reworked the code in #3527 a little, because it had the same trouble with filters of size 1, and updated it. Merging the latest version of #3527 will fix the skimage bug, but I would like to bring up the discussion on whether this is the right thing to do or not. I certainly prefer #3527 to #3517, but if there is no consensus I will close #3527 and fix #3517 instead. Thanks, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ay?dale en sus planes de dominaci?n mundial. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clarkfitzg at gmail.com Sat Sep 6 12:54:15 2014 From: clarkfitzg at gmail.com (Clark Fitzgerald) Date: Sat, 6 Sep 2014 09:54:15 -0700 Subject: [SciPy-Dev] return named tuples Message-ID: As a user, it would be convenient to access results by name. The relevant issue on Github is #3665 . For example: summary = scipy.stats.describe(data) The current way to access the mean is to write `summary[2]`. It would be more clear to write `summary.mean`. I'd like to create a PR to implement this using namedtuples. Here is the idea: from collections import namedtuple from scipy.stats import describe, norm data = norm().rvs(100) unnamed = describe(data) output = namedtuple('describe', ('size', 'range', 'mean', 'variance', 'skewness', 'kurtosis')) named = output(*unnamed) This doesn't break backwards compatibility since: In [8]: unnamed[2] == named[2] == named.mean Out[8]: True This isn't limited to stats.describe; it would be beneficial anywhere that the return object is a tuple that's possibly unclear. The feedback on the Git issue has been positive. More feedback welcome. Best, Clark Fitzgerald Statistics phd student, UC Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Sat Sep 6 15:10:03 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sat, 6 Sep 2014 15:10:03 -0400 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 12:54 PM, Clark Fitzgerald wrote: > As a user, it would be convenient to access results by name. The relevant > issue on Github is #3665 . > For example: > > summary = scipy.stats.describe(data) > > The current way to access the mean is to write `summary[2]`. It would be > more clear to write `summary.mean`. I'd like to create a PR to implement > this using namedtuples. Here is the idea: > > from collections import namedtuple > from scipy.stats import describe, norm > > > data = norm().rvs(100) > unnamed = describe(data) > > output = namedtuple('describe', ('size', 'range', 'mean', 'variance', > 'skewness', 'kurtosis')) > > named = output(*unnamed) > > This doesn't break backwards compatibility since: > > In [8]: unnamed[2] == named[2] == named.mean > Out[8]: True > > This isn't limited to stats.describe; it would be beneficial anywhere that > the return object is a tuple that's possibly unclear. > > The feedback on the Git issue has been positive. More feedback welcome. > > Sounds good to me. This could eventually be applied to many functions in scipy. Before adding this feature to a function, look for any related functions that might return similar values. We should try to ensure that return values with the same meaning are consistently given the same name. We should avoid, for example, one statistical test using "p", another using "pvalue" and third using "p_value". We'll also need to update our docstring standard to include guidelines for documenting such return values. Warren > > Best, > Clark Fitzgerald > Statistics phd student, UC Davis > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sat Sep 6 15:59:56 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sat, 6 Sep 2014 15:59:56 -0400 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 3:10 PM, Warren Weckesser wrote: > > > > On Sat, Sep 6, 2014 at 12:54 PM, Clark Fitzgerald > wrote: > >> As a user, it would be convenient to access results by name. The relevant >> issue on Github is #3665 . >> For example: >> >> summary = scipy.stats.describe(data) >> >> The current way to access the mean is to write `summary[2]`. It would be >> more clear to write `summary.mean`. I'd like to create a PR to implement >> this using namedtuples. Here is the idea: >> >> from collections import namedtuple >> from scipy.stats import describe, norm >> >> >> data = norm().rvs(100) >> unnamed = describe(data) >> >> output = namedtuple('describe', ('size', 'range', 'mean', 'variance', >> 'skewness', 'kurtosis')) >> >> named = output(*unnamed) >> >> This doesn't break backwards compatibility since: >> >> In [8]: unnamed[2] == named[2] == named.mean >> Out[8]: True >> >> This isn't limited to stats.describe; it would be beneficial anywhere >> that the return object is a tuple that's possibly unclear. >> >> The feedback on the Git issue has been positive. More feedback welcome. >> >> > > Sounds good to me. This could eventually be applied to many > functions in scipy. > > Before adding this feature to a function, look for any related > functions that might return similar values. We should try to > ensure that return values with the same meaning are consistently > given the same name. We should avoid, for example, one statistical > test using "p", another using "pvalue" and third using "p_value". > > We'll also need to update our docstring standard to include guidelines > for documenting such return values. > It's nice for users, but doesn't help for developing the code. It's backwards compatible but not "future proof". For example it's a pain that we cannot change the returns of linregress to add some additional things because it would break the behavior as a tuple. Josef > > Warren > > > >> >> Best, >> Clark Fitzgerald >> Statistics phd student, UC Davis >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Sat Sep 6 21:09:02 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Sat, 6 Sep 2014 19:09:02 -0600 Subject: [SciPy-Dev] Expose Lapack for Cython Message-ID: Hi all, I have put together pxd files that allow direct access from Cython to the the blas and lapack functions wrapped in scipy.linalg.blas and scipy.linalg.lapack. The idea is to make these low level functions available in Cython without the corresponding Python level function call that is necessary when using the wrappers already in SciPy. They are currently in my github repository https://github.com/insertinterestingnamehere/cylinalg. The approach is based on the gist https://gist.github.com/pv/5437087. I think this would be a good addition to SciPy since it is really only another interface to the wrappers that are already there. Where would be the best place to put this? Also, what sorts of tests should be included? Any other input is welcome too. Thanks! -Ian Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: From clarkfitzg at gmail.com Sun Sep 7 01:04:18 2014 From: clarkfitzg at gmail.com (Clark Fitzgerald) Date: Sat, 6 Sep 2014 22:04:18 -0700 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: Agreed, consistent names are important. My general strategy is to use the function name as the `typename` parameter for namedtuple, and the equivalent Numpy function names for `field_names`. There's room for discussion here- if the function is `describe`, then the `typename` could be: 1) `describe` 3) `stats_describe` 2) `describe_out` 4) or something else It would be nice to have a standard for this naming convention as well. Regarding Josef's point about 'future proofing', it seems to me that it would be cleaner for the function to return a dict when this is anticipated. But this would only work for new code. Clark On Sat, Sep 6, 2014 at 12:59 PM, wrote: > > > > On Sat, Sep 6, 2014 at 3:10 PM, Warren Weckesser < > warren.weckesser at gmail.com> wrote: > >> >> >> >> On Sat, Sep 6, 2014 at 12:54 PM, Clark Fitzgerald >> wrote: >> >>> As a user, it would be convenient to access results by name. The >>> relevant issue on Github is #3665 >>> . For example: >>> >>> summary = scipy.stats.describe(data) >>> >>> The current way to access the mean is to write `summary[2]`. It would be >>> more clear to write `summary.mean`. I'd like to create a PR to implement >>> this using namedtuples. Here is the idea: >>> >>> from collections import namedtuple >>> from scipy.stats import describe, norm >>> >>> >>> data = norm().rvs(100) >>> unnamed = describe(data) >>> >>> output = namedtuple('describe', ('size', 'range', 'mean', 'variance', >>> 'skewness', 'kurtosis')) >>> >>> named = output(*unnamed) >>> >>> This doesn't break backwards compatibility since: >>> >>> In [8]: unnamed[2] == named[2] == named.mean >>> Out[8]: True >>> >>> This isn't limited to stats.describe; it would be beneficial anywhere >>> that the return object is a tuple that's possibly unclear. >>> >>> The feedback on the Git issue has been positive. More feedback welcome. >>> >>> >> >> Sounds good to me. This could eventually be applied to many >> functions in scipy. >> >> Before adding this feature to a function, look for any related >> functions that might return similar values. We should try to >> ensure that return values with the same meaning are consistently >> given the same name. We should avoid, for example, one statistical >> test using "p", another using "pvalue" and third using "p_value". >> >> We'll also need to update our docstring standard to include guidelines >> for documenting such return values. >> > > It's nice for users, but doesn't help for developing the code. > > It's backwards compatible but not "future proof". > For example it's a pain that we cannot change the returns of linregress to > add some additional things because it would break the behavior as a tuple. > > Josef > > >> >> Warren >> >> >> >>> >>> Best, >>> Clark Fitzgerald >>> Statistics phd student, UC Davis >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtaylor.debian at googlemail.com Sun Sep 7 06:33:19 2014 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Sun, 07 Sep 2014 12:33:19 +0200 Subject: [SciPy-Dev] ANN: NumPy 1.9.0 release Message-ID: <540C346F.8070109@googlemail.com> Hello, We are proud to announce the 1.9.0 release of NumPy. This release includes numerous performance improvements, most significantly the indexing code has been rewritten be a lot times faster for most cases and performance of using small arrays and scalars has almost doubled. Plenty of other functions have been improved too, nonzero, where, bincount, searchsorted, count_nonzero, floating point min/max, boolean argmin/argmax, triu/tril, masked sorting can be expected to perform significantly better in many cases. Also NumPy 1.9.0 releases the GIL for more functions, most notably indexing now releases it and the random modules state object has a private lock instead of using the GIL. This allows leveraging pure python threads more efficiently. In order to make working with arrays containing NaN values easier nanmedian and nanpercentile have been added which ignore these values. These functions and the regular median and percentile now also support generalized axis arguments that ufuncs already have, these allow reducing along multiple axis in one call. Please see the release notes for all the details. Please also take not of the many small compatibility changes and deprecation in the notes. https://github.com/numpy/numpy/blob/maintenance/1.9.x/doc/release/1.9.0-notes.rst The source tarballs and win32 binaries can be downloaded here: https://sourceforge.net/projects/numpy/files/NumPy/1.9.0 Cheers, The NumPy Development Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sturla.molden at gmail.com Sun Sep 7 12:21:37 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Sun, 7 Sep 2014 16:21:37 +0000 (UTC) Subject: [SciPy-Dev] Expose Lapack for Cython References: Message-ID: <554112533431799230.509399sturla.molden-gmail.com@news.gmane.org> Ian Henriksen wrote: > Hi all, I have put together pxd files that allow direct access from Cython > to the the blas and lapack functions wrapped in scipy.linalg.blas and > scipy.linalg.lapack. The idea is to make these low level functions > available in Cython without the corresponding Python level function call > that is necessary when using the wrappers already in SciPy. They are > currently in my github repository > href="https://github.com/insertinterestingnamehere/cylinalg.">https://github.com/insertinterestingnamehere/cylinalg. > The approach is > based on the gist href="https://gist.github.com/pv/5437087.">https://gist.github.com/pv/5437087. I think > this would be > a good addition to SciPy since it is really only another interface to the > wrappers that are already there. I would recommend storing the pointers globally in a module (instead of populating a struct) together with references to the LAPACK and BLAS modules in SciPy. LAPACK and BLAS extension modules should not be unloaded as long as the pointers are available, or you risk creating dangling function pointers. > Where would be the best place to put this? Also, what sorts of tests should > be included? Any other input is welcome too. You can check that they create the same output as calls to the Python interface. Or you can use codes from the LAPACK test programs to check the sanity of the output. Sturla From mail at danieldasilva.org Tue Sep 9 12:16:55 2014 From: mail at danieldasilva.org (Daniel da Silva) Date: Tue, 9 Sep 2014 12:16:55 -0400 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: Are the namedtuple subclasses used to create return values going to be made available? If so, what's the convention on where they will be placed? On Sun, Sep 7, 2014 at 1:04 AM, Clark Fitzgerald wrote: > Agreed, consistent names are important. My general strategy is to use the > function name as the `typename` parameter for namedtuple, and the > equivalent Numpy function names for `field_names`. > > There's room for discussion here- if the function is `describe`, then the > `typename` could be: > > 1) `describe` > 3) `stats_describe` > 2) `describe_out` > 4) or something else > > It would be nice to have a standard for this naming convention as well. > > Regarding Josef's point about 'future proofing', it seems to me that it > would be cleaner for the function to return a dict when this is > anticipated. But this would only work for new code. > > Clark > > > On Sat, Sep 6, 2014 at 12:59 PM, wrote: > >> >> >> >> On Sat, Sep 6, 2014 at 3:10 PM, Warren Weckesser < >> warren.weckesser at gmail.com> wrote: >> >>> >>> >>> >>> On Sat, Sep 6, 2014 at 12:54 PM, Clark Fitzgerald >>> wrote: >>> >>>> As a user, it would be convenient to access results by name. The >>>> relevant issue on Github is #3665 >>>> . For example: >>>> >>>> summary = scipy.stats.describe(data) >>>> >>>> The current way to access the mean is to write `summary[2]`. It would >>>> be more clear to write `summary.mean`. I'd like to create a PR to implement >>>> this using namedtuples. Here is the idea: >>>> >>>> from collections import namedtuple >>>> from scipy.stats import describe, norm >>>> >>>> >>>> data = norm().rvs(100) >>>> unnamed = describe(data) >>>> >>>> output = namedtuple('describe', ('size', 'range', 'mean', 'variance', >>>> 'skewness', 'kurtosis')) >>>> >>>> named = output(*unnamed) >>>> >>>> This doesn't break backwards compatibility since: >>>> >>>> In [8]: unnamed[2] == named[2] == named.mean >>>> Out[8]: True >>>> >>>> This isn't limited to stats.describe; it would be beneficial anywhere >>>> that the return object is a tuple that's possibly unclear. >>>> >>>> The feedback on the Git issue has been positive. More feedback welcome. >>>> >>>> >>> >>> Sounds good to me. This could eventually be applied to many >>> functions in scipy. >>> >>> Before adding this feature to a function, look for any related >>> functions that might return similar values. We should try to >>> ensure that return values with the same meaning are consistently >>> given the same name. We should avoid, for example, one statistical >>> test using "p", another using "pvalue" and third using "p_value". >>> >>> We'll also need to update our docstring standard to include guidelines >>> for documenting such return values. >>> >> >> It's nice for users, but doesn't help for developing the code. >> >> It's backwards compatible but not "future proof". >> For example it's a pain that we cannot change the returns of linregress >> to add some additional things because it would break the behavior as a >> tuple. >> >> Josef >> >> >>> >>> Warren >>> >>> >>> >>>> >>>> Best, >>>> Clark Fitzgerald >>>> Statistics phd student, UC Davis >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Sep 9 13:53:06 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 9 Sep 2014 19:53:06 +0200 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 6:16 PM, Daniel da Silva wrote: > Are the namedtuple subclasses used to create return values going to be > made available? If so, what's the convention on where they will be placed? > They should remain private I'd think. > > >>>> Sounds good to me. This could eventually be applied to many >>>> functions in scipy. >>>> >>>> Before adding this feature to a function, look for any related >>>> functions that might return similar values. We should try to >>>> ensure that return values with the same meaning are consistently >>>> given the same name. We should avoid, for example, one statistical >>>> test using "p", another using "pvalue" and third using "p_value". >>>> >>>> We'll also need to update our docstring standard to include guidelines >>>> for documenting such return values. >>>> >>> >>> It's nice for users, but doesn't help for developing the code. >>> >>> It's backwards compatible but not "future proof". >>> For example it's a pain that we cannot change the returns of linregress >>> to add some additional things because it would break the behavior as a >>> tuple. >>> >> True, but an orthogonal discussion. We may decide to break backwards compat on a case by case basis, but there would have to be very good reasons to do so. Using namedtuples is a straightforward improvement Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Tue Sep 9 15:05:24 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Tue, 9 Sep 2014 13:05:24 -0600 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: <554112533431799230.509399sturla.molden-gmail.com@news.gmane.org> References: <554112533431799230.509399sturla.molden-gmail.com@news.gmane.org> Message-ID: Hmm. It's not clear to me exactly how to make a custom Python module with additional C level pointers like that that. I'm in the process of looking through the C api to see how something like that might be done, but an example would be helpful. That would certainly be a good way to take care of references though. My end goal is to make these all available in a single pxd file. It will be necessary to initialize the struct/module from the wrappers in scipy, but other than that I'd like to make the interface as simple as possible. I don't think using the lapack test programs is feasible without a great deal of trouble. My main concern is what sort of testing needs to be done for its inclusion in scipy. I could write examples that call each of them, but that would be a rather lengthy project in its own right. I really just need a way to show that the signatures are correct. Does anyone have any suggestions as to how/where this should be included? Thanks! -Ian On Sun, Sep 7, 2014 at 10:21 AM, Sturla Molden wrote: > Ian Henriksen wrote: > > Hi all, I have put together pxd files that allow direct access from > Cython > > to the the blas and lapack functions wrapped in scipy.linalg.blas and > > scipy.linalg.lapack. The idea is to make these low level functions > > available in Cython without the corresponding Python level function call > > that is necessary when using the wrappers already in SciPy. They are > > currently in my github repository > > > href="https://github.com/insertinterestingnamehere/cylinalg."> > https://github.com/insertinterestingnamehere/cylinalg. > > The approach is > > based on the gist > href="https://gist.github.com/pv/5437087."> > https://gist.github.com/pv/5437087. I think > > this would be > > a good addition to SciPy since it is really only another interface to the > > wrappers that are already there. > > I would recommend storing the pointers globally in a module (instead of > populating a struct) together with references to the LAPACK and BLAS > modules in SciPy. LAPACK and BLAS extension modules should not be unloaded > as long as the pointers are available, or you risk creating dangling > function pointers. > > > > Where would be the best place to put this? Also, what sorts of tests > should > > be included? Any other input is welcome too. > > You can check that they create the same output as calls to the Python > interface. Or you can use codes from the LAPACK test programs to check the > sanity of the output. > > Sturla > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Tue Sep 9 15:15:39 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Tue, 9 Sep 2014 13:15:39 -0600 Subject: [SciPy-Dev] Introduction to Python for Science In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 12:33 PM, Ralf Gommers wrote: > > > > On Fri, Sep 5, 2014 at 6:00 PM, Nathaniel Smith wrote: > >> Is there any comprehensive list of such resources? I feel like I've seen >> several go by at different times, and surely at some point will want to >> recommend some of them to students, but by that time I'll have list track >> of the links, and be uncertain which resources are more appropriate for >> which students as well. >> > > I wouldn't say it's comprehensive, but > http://scipy.org/topical-software.html#tutorials-and-texts contains a > selection. David's book looks like it would be a nice addition to that > list. PR to https://github.com/scipy/scipy.org very welcome. > > Ralf > > -n >> On 5 Sep 2014 10:32, "Stefan Otte" wrote: >> >> Nice work! I always recommend the "Python Scientific Lecture Notes" >> [1] to students. >> >> Best, >> Stefan >> >> >> [1] https://scipy-lectures.github.io/ >> >> >> >> On Fri, Sep 5, 2014 at 4:25 PM, David J Pine wrote: >> > NumPy, SciPy, MatPlotLib Users & Science teachers: >> > >> > I have written an introduction to scientific python that you may find >> > useful. You can download it from GitHub and use it freely: >> > >> > https://github.com/djpine/pyman >> > >> > I wrote this manual/book for undergraduates taking science and >> engineering >> > courses that use programming to solve science and engineering >> problems. It >> > is not for experts. I am sharing it with the hope that others may find >> it >> > useful. It includes an introduction to very basic programming, >> > numpy,matplotlib, & scipy, as well as instructions on how to download >> and >> > install Python and these three libraries. It also includes an >> introduction >> > to IPython notebooks. >> > >> > Corrections and suggestions for improvements are welcome. >> > >> > David Pine >> > >> > >> > _______________________________________________ >> > SciPy-Dev mailing list >> > SciPy-Dev at scipy.org >> > http://mail.scipy.org/mailman/listinfo/scipy-dev >> > >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > Also, for anyone interested, there is the repository https://github.com/byuimpact/numerical_computing. It is the LaTeX source code for the lab manuals currently used by BYU's Applied Math program. It is certainly still a work in progress, but there is a lot of good material there. Once it is in a more polished state, it would make a good addition to the list at scipy.org. -Ian Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Tue Sep 9 15:28:45 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Tue, 9 Sep 2014 15:28:45 -0400 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 3:07 PM, Ralf Gommers wrote: > Hi all, > > It's about time for a couple of releases. > > 0.14.1 fixes some regressions as well as a lot of test failures against > numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are > fixed now, so I plan to tag it this weekend. If there's anything really > urgent that still needs to go in, please speak up. > > For 0.15.0 there are still 17 issues/PRs, but most of those we should be > able to merge/fix relatively quickly. I propose the following release > schedule: > > - beta 1: 16 Sep > - release candidate 1: 4 Oct > - release candidate 2: 18 Oct (if needed) > - final release: 25 Oct > > Does that work for everyone? > Works for me. Thanks, Ralf. Warren > Are there issues/PRs that aren't under the 0.15.0 milestone but have to go > in? > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From travis at continuum.io Tue Sep 9 15:41:51 2014 From: travis at continuum.io (Travis Oliphant) Date: Tue, 9 Sep 2014 14:41:51 -0500 Subject: [SciPy-Dev] Introduction to Python for Science In-Reply-To: References: Message-ID: That is a nice book. Thank you for making it available. It would be great if you also showed beginners how to use Spyder which is an open source IDE that is commonly used by many beginners and experts. Best, -Travis On Fri, Sep 5, 2014 at 9:25 AM, David J Pine wrote: > NumPy, SciPy, MatPlotLib Users & Science teachers: > > I have written an introduction to scientific python that you may find > useful. You can download it from GitHub and use it freely: > > https://github.com/djpine/pyman > > I wrote this manual/book for undergraduates taking science and engineering > courses that use programming to solve science and engineering problems. It > is not for experts. I am sharing it with the hope that others may find it > useful. It includes an introduction to very basic programming, numpy, > matplotlib, & scipy, as well as instructions on how to download and > install Python and these three libraries. It also includes an introduction > to IPython notebooks. > > Corrections and suggestions for improvements are welcome. > > David Pine > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -- Travis Oliphant CEO Continuum Analytics, Inc. http://www.continuum.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaime.frio at gmail.com Tue Sep 9 16:11:33 2014 From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=) Date: Tue, 9 Sep 2014 13:11:33 -0700 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 12:07 PM, Ralf Gommers wrote: > Hi all, > > It's about time for a couple of releases. > > 0.14.1 fixes some regressions as well as a lot of test failures against > numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are > fixed now, so I plan to tag it this weekend. If there's anything really > urgent that still needs to go in, please speak up. > Is fixing #3898 (https://github.com/scipy/scipy/issues/3898) 0.14.1 material? I modified #3527 (https://github.com/scipy/scipy/pull/3527) to take care of it, and e-mailed the list about it a few days back. If that is not seen as the right way to solve it, I have no problem discarding it, or postponing a decision for later, and fixing the existing algorithm rather than changing it in a new PR. But I need some feedback on how to go about this... Jaime -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Sep 9 16:29:55 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 9 Sep 2014 22:29:55 +0200 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 10:11 PM, Jaime Fern?ndez del R?o < jaime.frio at gmail.com> wrote: > > On Fri, Sep 5, 2014 at 12:07 PM, Ralf Gommers > wrote: > >> Hi all, >> >> It's about time for a couple of releases. >> >> 0.14.1 fixes some regressions as well as a lot of test failures against >> numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are >> fixed now, so I plan to tag it this weekend. If there's anything really >> urgent that still needs to go in, please speak up. >> > > Is fixing #3898 (https://github.com/scipy/scipy/issues/3898) 0.14.1 > material? > It would be if gh-3517 had been included in 0.14.0. Which it wasn't, unless I missed something. Your fix definitely needs to go in for 0.15.0 though. I modified #3527 (https://github.com/scipy/scipy/pull/3527) to take care of > it, and e-mailed the list about it a few days back. If that is not seen as > the right way to solve it, I have no problem discarding it, or postponing a > decision for later, and fixing the existing algorithm rather than changing > it in a new PR. But I need some feedback on how to go about this... > The performance trade-off that you proposed sounds right to me, but I haven't had a chance to look in detail. I just marked the PR for 0.15.0, to make sure we won't forget. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Wed Sep 10 12:46:28 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 10 Sep 2014 16:46:28 +0000 (UTC) Subject: [SciPy-Dev] Expose Lapack for Cython References: <554112533431799230.509399sturla.molden-gmail.com@news.gmane.org> Message-ID: <303320712432058573.085487sturla.molden-gmail.com@news.gmane.org> Ian Henriksen wrote: > Hmm. It's not clear to me exactly how to make a custom Python module with > additional C level pointers like that that. The function pointer instances goes in a lapack.pyx file and the declarations goes in a corresponding lapack.pxd file. It is similar to what you would do in C when you have corresponding.c and .h files. The lapack module must be loaded from SciPy when its __init__.py is executed. This also initializes the pointers. Just let your lapack.pyx initialize its own pointers when it is loaded. Then any other Cython module can "cimport lapack". (In reality you don't need to use the f2py objects either, if you link lapack.pyx with LAPACK when Scipy is built.) > I'm in the process of looking > through the C api to see how something like that might be done, but an > example would be helpful. That would certainly be a good way to take care > of references though. My end goal is to make these all available in a > single pxd file. It is better to have a .pyx file with a corresponding .pxd file. > It will be necessary to initialize the struct/module from > the wrappers in scipy, No, this can be avoided if you have corresponding .pyx and .pxd files. You should only need to "cimport lapack" if you do it right. (Actually it would be something like "cimport scipy.linalg.lapack.cylapack as lapack".) See here: http://docs.cython.org/src/userguide/sharing_declarations.html#sharing-c-functions Sturla From matthew.brett at gmail.com Thu Sep 11 11:07:48 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 11 Sep 2014 11:07:48 -0400 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: Message-ID: Hi, On Sat, Sep 6, 2014 at 9:09 PM, Ian Henriksen wrote: > Hi all, I have put together pxd files that allow direct access from Cython > to the the blas and lapack functions wrapped in scipy.linalg.blas and > scipy.linalg.lapack. The idea is to make these low level functions available > in Cython without the corresponding Python level function call that is > necessary when using the wrappers already in SciPy. They are currently in my > github repository https://github.com/insertinterestingnamehere/cylinalg. The > approach is based on the gist https://gist.github.com/pv/5437087. I think > this would be a good addition to SciPy since it is really only another > interface to the wrappers that are already there. > > Where would be the best place to put this? Also, what sorts of tests should > be included? Any other input is welcome too. Just to say - thanks very much for doing this - it will be very useful indeed. Cheers, Matthew From gael.varoquaux at normalesup.org Thu Sep 11 11:24:40 2014 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Thu, 11 Sep 2014 17:24:40 +0200 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: Message-ID: <20140911152440.GN19676@phare.normalesup.org> On Thu, Sep 11, 2014 at 11:07:48AM -0400, Matthew Brett wrote: > Just to say - thanks very much for doing this - it will be very useful indeed. +1000! Ga?l PS: Note that I haven't posted on this list for at least a year. This tells you how enthousiastic I am. From insertinterestingnamehere at gmail.com Thu Sep 11 11:57:43 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Thu, 11 Sep 2014 09:57:43 -0600 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: <20140911152440.GN19676@phare.normalesup.org> References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On Thu, Sep 11, 2014 at 9:24 AM, Gael Varoquaux < gael.varoquaux at normalesup.org> wrote: > On Thu, Sep 11, 2014 at 11:07:48AM -0400, Matthew Brett wrote: > > Just to say - thanks very much for doing this - it will be very useful > indeed. > > +1000! > > Ga?l > > PS: Note that I haven't posted on this list for at least a year. This > tells you how enthousiastic I am. > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > Thanks. I'm glad to hear it will be helpful. Sturla: Thanks, I see what you were saying now. I'll work on getting a pull request up in the next couple of days. Thanks! -Ian Henriksen -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.oleary at gmail.com Thu Sep 11 12:18:01 2014 From: aaron.oleary at gmail.com (Aaron O'Leary) Date: Thu, 11 Sep 2014 17:18:01 +0100 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: <20140911152440.GN19676@phare.normalesup.org> References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: Yeah this is really useful Ian! Thanks for working on it. On 11 September 2014 16:24, Gael Varoquaux wrote: > On Thu, Sep 11, 2014 at 11:07:48AM -0400, Matthew Brett wrote: >> Just to say - thanks very much for doing this - it will be very useful indeed. > > +1000! > > Ga?l > > PS: Note that I haven't posted on this list for at least a year. This > tells you how enthousiastic I am. > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From sturla.molden at gmail.com Thu Sep 11 13:58:16 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 11 Sep 2014 17:58:16 +0000 (UTC) Subject: [SciPy-Dev] Expose Lapack for Cython References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: <449895517432150462.049572sturla.molden-gmail.com@news.gmane.org> Ian Henriksen wrote: > Sturla: Thanks, I see what you were saying now. I'll work on getting a pull > request up in the next couple of days. Thanks, it was a bit convoluted to explain. (This way of using Cython modules are not so well known, perhaps.) Anyhow, I suggest we make two Cython modules with corresponding .pxd files that can be cimported like this: cimport scipy.linalg.lapack.cylapack as lapack cimport scipy.linalg.lapack.cyblas as blas After these statements it should be possible to just call blas.dgemm, lapack.dpotrf, etc. (Also ignore what I said in my earlier post about not using the f2py wrappers. Because of the f2c ABI in Apple Accelerate framework only the f2py wrappers in SciPy have a known C API. So use the f2py wrappers like you currently do.) Sturla From sturla.molden at gmail.com Thu Sep 11 14:22:09 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 11 Sep 2014 18:22:09 +0000 (UTC) Subject: [SciPy-Dev] Expose Lapack for Cython References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: <890608952432151113.754377sturla.molden-gmail.com@news.gmane.org> Gael Varoquaux wrote: > PS: Note that I haven't posted on this list for at least a year. This > tells you how enthousiastic I am. Yes, many projects depending on SciPy would benefit from access to SciPy's LAPACK and BLAS. Having to link BLAS and LAPACK again is a PITA, not to mention the pain of building ATLAS or OpenBLAS correctly on your own. Matlab has always provided access to its BLAS and LAPACK for Fortran and C MEX files. 15 years ago, when I was writing MEX files extensively I used this option a lot. It takes away a lot of pain... We are only talking about making LAPACK available for Cython though. C and C++ extension modules would have to take care of this themselves using the Python C API. Perhaps we should provide an example on how to do that? BTW: SciPy already provides access to BLAS and LAPACK for Fortran extension modules through f2py. This is a fantastic feature, but unfortunately few seem to be aware of it. Now we are actually just piggybacking the Cython code on the f2py machinery for this feature. So Pearu Peterson and the other authors of f2py deserve to be credited. Sturla From clarkfitzg at gmail.com Fri Sep 12 17:28:31 2014 From: clarkfitzg at gmail.com (Clark Fitzgerald) Date: Fri, 12 Sep 2014 14:28:31 -0700 Subject: [SciPy-Dev] return named tuples In-Reply-To: References: Message-ID: PR open for this now: https://github.com/scipy/scipy/pull/3991 I made them private using the naming convention `_funcname_out` and put them in the same module, directly above the function where they will be used. Clark On Tue, Sep 9, 2014 at 10:53 AM, Ralf Gommers wrote: > > > On Tue, Sep 9, 2014 at 6:16 PM, Daniel da Silva > wrote: > >> Are the namedtuple subclasses used to create return values going to be >> made available? If so, what's the convention on where they will be placed? >> > > They should remain private I'd think. > > > >> >> >>>>> Sounds good to me. This could eventually be applied to many >>>>> functions in scipy. >>>>> >>>>> Before adding this feature to a function, look for any related >>>>> functions that might return similar values. We should try to >>>>> ensure that return values with the same meaning are consistently >>>>> given the same name. We should avoid, for example, one statistical >>>>> test using "p", another using "pvalue" and third using "p_value". >>>>> >>>>> We'll also need to update our docstring standard to include guidelines >>>>> for documenting such return values. >>>>> >>>> >>>> It's nice for users, but doesn't help for developing the code. >>>> >>>> It's backwards compatible but not "future proof". >>>> For example it's a pain that we cannot change the returns of linregress >>>> to add some additional things because it would break the behavior as a >>>> tuple. >>>> >>> > True, but an orthogonal discussion. We may decide to break backwards > compat on a case by case basis, but there would have to be very good > reasons to do so. Using namedtuples is a straightforward improvement > > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danilo.horta at gmail.com Tue Sep 16 06:50:43 2014 From: danilo.horta at gmail.com (Danilo Horta) Date: Tue, 16 Sep 2014 11:50:43 +0100 Subject: [SciPy-Dev] Fast symmetric rank-one Cholesky decomposition update Message-ID: Hi folks, Let L be the Cholesky decomposition of A. There are O(n^2) methods for updating L such that L is now the Cholesky decomposition of A + numpy.outer(v, v) (and also for A - np.outer(v, v)). Is this something adequate to scipy? If so, I'm willing to implement. (I need this kind of method...) Best, Danilo -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Tue Sep 16 07:12:02 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 16 Sep 2014 07:12:02 -0400 Subject: [SciPy-Dev] Fast symmetric rank-one Cholesky decomposition update In-Reply-To: References: Message-ID: On Tue, Sep 16, 2014 at 6:50 AM, Danilo Horta wrote: > Hi folks, > > Let L be the Cholesky decomposition of A. There are O(n^2) methods for > updating L such that L is now the Cholesky decomposition of A + > numpy.outer(v, v) (and also for A - np.outer(v, v)). > > Is this something adequate to scipy? If so, I'm willing to implement. (I > need this kind of method...) I also just needed this and coded a boring version in python (based on Wikipedia). IMO, it would be useful to have this in numpy or scipy. a few comments: It's in LINPACK but never made it into LAPACK. Here is a cython version https://github.com/jcrudy/choldate Updating is numerically stable, but downdating can run into problems. A good downdating implementation would be more complicated than the plain vanilla implementation. To be able to use it in a fast loop, I think a cython function that can handle several rank-1 up or down dates would be useful. Josef > > Best, > Danilo > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From annapowellsmith at gmail.com Wed Sep 17 03:23:11 2014 From: annapowellsmith at gmail.com (Anna Powell-Smith) Date: Wed, 17 Sep 2014 08:23:11 +0100 Subject: [SciPy-Dev] Adding Pearson residuals to chi2_contingency Message-ID: Hi I'm interested in contributing to scipy. I'd like to add a feature to stats.chi2_contingency to return the raw and standardised Pearson residuals - it's something I need myself. The contributing guide [1] says I should run feature ideas past this list before jumping in with a pull request, so here I am :) Would this be a useful pull request? Best wishes Anna [1] https://github.com/scipy/scipy/blob/master/HACKING.rst.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Sep 17 18:50:11 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 18 Sep 2014 00:50:11 +0200 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule In-Reply-To: References: Message-ID: On Tue, Sep 9, 2014 at 9:28 PM, Warren Weckesser wrote: > > > On Fri, Sep 5, 2014 at 3:07 PM, Ralf Gommers > wrote: > >> Hi all, >> >> It's about time for a couple of releases. >> >> 0.14.1 fixes some regressions as well as a lot of test failures against >> numpy 1.9.0 (due to __numpy_ufunc__) removal. All known regressions are >> fixed now, so I plan to tag it this weekend. If there's anything really >> urgent that still needs to go in, please speak up. >> >> For 0.15.0 there are still 17 issues/PRs, but most of those we should be >> able to merge/fix relatively quickly. I propose the following release >> schedule: >> >> - beta 1: 16 Sep >> - release candidate 1: 4 Oct >> - release candidate 2: 18 Oct (if needed) >> - final release: 25 Oct >> >> Does that work for everyone? >> > > > Works for me. Thanks, Ralf. > There are still a few issues to be solved (see https://github.com/scipy/scipy/milestones/0.15.0), so the timing has to shift a bit. I'll be offline for a week, so probably we can do the beta at the end of this month. Ralf > > Warren > > > >> Are there issues/PRs that aren't under the 0.15.0 milestone but have to >> go in? >> >> Cheers, >> Ralf >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Thu Sep 18 10:40:52 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Thu, 18 Sep 2014 10:40:52 -0400 Subject: [SciPy-Dev] Adding Pearson residuals to chi2_contingency In-Reply-To: References: Message-ID: On Wed, Sep 17, 2014 at 3:23 AM, Anna Powell-Smith < annapowellsmith at gmail.com> wrote: > Hi > > I'm interested in contributing to scipy. I'd like to add a feature to > stats.chi2_contingency to return the raw and standardised Pearson residuals > - it's something I need myself. > > The contributing guide [1] says I should run feature ideas past this list > before jumping in with a pull request, so here I am :) > > Would this be a useful pull request? > > Anna, Yes, that would be useful. I included an implementation of these in my answer to this question on stackoverlow: http://stackoverflow.com/questions/20453729/what-is-the-equivalent-of-r-data-chisqresiduals-in-python (The implementation of stdres given there only works for 2-d tables, but it should be possible to generalize it to the n-dimensional case.) It would be great to get something like this into scipy. Warren Best wishes > Anna > > [1] https://github.com/scipy/scipy/blob/master/HACKING.rst.txt > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Fri Sep 19 09:16:11 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 19 Sep 2014 13:16:11 +0000 (UTC) Subject: [SciPy-Dev] Fast symmetric rank-one Cholesky decomposition update References: Message-ID: <804816899432825056.901953sturla.molden-gmail.com@news.gmane.org> wrote: > It's in LINPACK but never made it into LAPACK. > Here is a cython version https://github.com/jcrudy/choldate The inner loop can be replaced with two calls to BLAS' *axpy subroutines. Indexing with casts to unsigned int just corrupts the readability. Sturla From cimrman3 at ntc.zcu.cz Thu Sep 25 11:21:38 2014 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Thu, 25 Sep 2014 17:21:38 +0200 Subject: [SciPy-Dev] ANN: SfePy 2014.3 Message-ID: <54243302.1010701@ntc.zcu.cz> I am pleased to announce release 2014.3 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 -------------------------- - isogeometric analysis (IGA) speed-up by C implementation of NURBS basis evaluation - generalized linear combination boundary conditions that work between different fields/variables and support non-homogeneous periodic conditions - non-constant essential boundary conditions given by a function in IGA - reorganized and improved documentation For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladimir Lukes, Matyas Novak, Zhihua Ouyang, Jaroslav Vondrejc From insertinterestingnamehere at gmail.com Thu Sep 25 17:22:37 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Thu, 25 Sep 2014 15:22:37 -0600 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On Thu, Sep 11, 2014 at 9:57 AM, Ian Henriksen < insertinterestingnamehere at gmail.com> wrote: > > On Thu, Sep 11, 2014 at 9:24 AM, Gael Varoquaux < > gael.varoquaux at normalesup.org> wrote: > >> On Thu, Sep 11, 2014 at 11:07:48AM -0400, Matthew Brett wrote: >> > Just to say - thanks very much for doing this - it will be very useful >> indeed. >> >> +1000! >> >> Ga?l >> >> PS: Note that I haven't posted on this list for at least a year. This >> tells you how enthousiastic I am. >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> > > Thanks. I'm glad to hear it will be helpful. > > Sturla: Thanks, I see what you were saying now. I'll work on getting a > pull request up in the next couple of days. > > Thanks! > > -Ian Henriksen > > I've opened this pull request that implements this. There are still several things I'd like to finish before it gets merged, but the basic functionality is there. Feedback is welcome. Thanks! -Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Thu Sep 25 21:47:55 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 26 Sep 2014 03:47:55 +0200 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On 25/09/14 23:22, Ian Henriksen wrote: > I've opened this pull request > that implements this. There > are still several things I'd like to finish before it gets merged, but > the basic functionality is there. Feedback is welcome. I think there is a minor bug causing a build failure. But apart from that it looks rather complete and well written. :-) Sturla From sturla.molden at gmail.com Thu Sep 25 21:53:01 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 26 Sep 2014 03:53:01 +0200 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On 26/09/14 03:47, Sturla Molden wrote: > On 25/09/14 23:22, Ian Henriksen wrote: > >> I've opened this pull request >> that implements this. There >> are still several things I'd like to finish before it gets merged, but >> the basic functionality is there. Feedback is welcome. > > > I think there is a minor bug causing a build failure. But apart from > that it looks rather complete and well written. :-) Documentation is needed though. Sturla From lanceboyle at qwest.net Fri Sep 26 04:41:55 2014 From: lanceboyle at qwest.net (Jerry) Date: Fri, 26 Sep 2014 01:41:55 -0700 Subject: [SciPy-Dev] Hamming etc. windows are wrong Message-ID: <32A9B832-5B17-4C3D-B573-336E4700FA36@qwest.net> I?ve noticed that the Hamming window (and I suppose other windows) provided by Octave, SciPy****, and NumPy***** is wrong, returning a window that is symmetric rather than one that is ?DFT symmetric.? This is easily spotted by looking at the first and last points of the window; if they are the same values, then the window is incorrect. These windows are normally applied to data that are equally spaced, thus implying that their DFTs are periodic. Let?s assume that we are windowing N data points, indexed from 0 to N-1 as is normal in signal processing. Then the DFT is also N points long, also indexed from 0 to N-1. The periodic extension principal implies that the point indexed by N in the DFT domain has the same value as the point indexed by 0. The window can also be imagined to have the same kind of periodic extension, so that what would be the N-th point of the window matches the N-point of the data with the same weight as was applied to the 0-th point of the data but without duplicating that point at N-1. This mistake is widespread, infecting many software packages. (I am sending this same note to the NumPy, SciPy, and Octave lists.) It is certainly wrong in most textbooks, including the classic, Oppenheim & Schafer, 1975. However, the definitive and widely referenced paper on windows by Fredric J. Harris, ?On the Use of Windows for Harmonic Analysis with the Discrete Fourier Transform,? Proceedings of the IEEE, vol. 66, NO. 1 , January, 1978 * discusses this problem, both its roots and its correction. For example, quoting from the paper: ?Since the DFT essentially considers sequences to be periodic, we can consider the missing end point to be the beginning of the next period of the periodic extension of this sequence. In fact, under the periodic extension, the next sample (at 16 s in Fig. 1.) is indistinguishable from the sample at zero seconds. ?This apparent lack of symmetry due to the missing (but implied) end point is a source of confusion in sampled window design. This can be traced to the early work related to convergence factors for the partial sums of the Fourier series. The partial sums (or the finite Fourier transform) always include an odd number of points and exhibit even symmetry about the origin. Hence much of the literature and many software libraries incorporate windows designed with true even symmetry rather than the implied symmetry with the missing end point!? ...and later... ?We will now catalog some well-known (and some not well-known windows. For each window we will comment on the justification for its use and identify its significant parameters. All the windows will be presented as even (about the origin) sequences with an odd number of points. To convert the window to DFT even, the right endpoint will be discarded and the sequence will be shifted so that the left end point coincides with the origin.? Note that he limits himself therefore to even-numbered "DFT even" windows, but the rule remains--honor the implied periodicity even for windows of odd length. Lest one consider this a trivial difference, consider the following Octave-Matlab code (corresponding NumPy and SciPy code would yield the same results). x = ones(8, 1); # An even sequence; its DFT should be real. hWrong = hamming(8) h9 = hamming(9); hRight = h9(1:8) xWrong = x .* hWrong; # Multiplication by "ones" xRight = x .* hRight; # shown for clarity. XWrong = fft(xWrong) # Contains nonzero imaginary part. XRight = fft(xRight) # Real, as expected from evenness of x. XWrongMag = abs(XWrong) # The magnitudes are XRightMag = abs(XRight) # also different. This causes the following output: hWrong = 0.080000 0.253195 0.642360 0.954446 0.954446 0.642360 0.253195 0.080000 hRight = 0.080000 0.214731 0.540000 0.865269 1.000000 0.865269 0.540000 0.214731 XWrong = 3.86000 + 0.00000i -1.76795 - 0.73231i 0.13889 + 0.13889i 0.01906 + 0.04602i 0.00000 + 0.00000i 0.01906 - 0.04602i 0.13889 - 0.13889i -1.76795 + 0.73231i XRight = 4.32000 + 0.00000i -1.84000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 + 0.00000i 0.00000 - 0.00000i 0.00000 - 0.00000i -1.84000 - 0.00000i XWrongMag = 3.86000 1.91362 0.19642 0.04981 0.00000 0.04981 0.19642 1.91362 XRightMag = 4.32000 1.84000 0.00000 0.00000 0.00000 0.00000 0.00000 1.84000 This news will likely upset many and I will be interested to see what arguments will flow in favor of keeping the status quo--I?m sure one will be, ?we?ve always done it this way? and others will be more substantial, possibly expressing decent arguments why the current situation is useful for some applications. In any case, I refer again to the Harris paper. So rather than host an argument on this list, this is what I propose: Do what Matlab** does. Acknowledge both uses by making a flag to handle the ?periodic? or the ?symmetric? cases. The Matlab default is ?symmetric? which is of course unfortunate but at least such inclusion in Octave, NumPy, and SciPy would retain compatibility with the existing usage. Then it?s up to the user whether to shoot him/herself in the foot, assuming that such a decision is guided by actually referring to the documentation for the package being used and not blindly using the default. Jerry Bauck * http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=1455106&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1455106 ** http://www.mathworks.com/help/signal/ref/hamming.html *** http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.hamming.html **** I am just learning Python-NumPy-SciPy but it appears as though the SciPy situation is that the documentation page above *** mentions the flag but the flag has not been implemented into SciPy itself. I would be glad to stand corrected. ***** http://docs.scipy.org/doc/numpy/reference/generated/numpy.hamming.html From davidmenhur at gmail.com Fri Sep 26 05:56:32 2014 From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=) Date: Fri, 26 Sep 2014 11:56:32 +0200 Subject: [SciPy-Dev] Hamming etc. windows are wrong In-Reply-To: <32A9B832-5B17-4C3D-B573-336E4700FA36@qwest.net> References: <32A9B832-5B17-4C3D-B573-336E4700FA36@qwest.net> Message-ID: On 26 September 2014 10:41, Jerry wrote: > **** I am just learning Python-NumPy-SciPy but it appears as though the > SciPy situation is that the documentation page above *** mentions the flag > but the flag has not been implemented into SciPy itself. I would be glad to > stand corrected. Regarding this, you can look at the source: odd = M % 2 if not sym and not odd: w = w[:-1] so it is implemented in Scipy, explicitely limited to even windows. It is not in Numpy, though (but that can be fixed). I think a reference is worth adding to the documentation, to make the intent and application of the sym flag clear. I am sure a PR will be most appreciated. /David. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at hilboll.de Fri Sep 26 06:44:53 2014 From: lists at hilboll.de (Andreas Hilboll) Date: Fri, 26 Sep 2014 12:44:53 +0200 Subject: [SciPy-Dev] unicode_literals for string arguments Message-ID: <542543A5.8000200@hilboll.de> Hi, I'm running into some issues which I attribute to not using from __future__ import unicode_literals. I'm running Python2.7, and am writing a script where I use from __future__ import unicode_literals. This raises ValueErrors e.g. in stats.binned_statistic_2d: ValueError: statistic not understood Do you see a way to prevent these errors from happening? Obviously, scipy should work no matter if a Py2 user uses from __future__ import unicode_literals or not. Any ideas? Cheers, Andreas From charlesr.harris at gmail.com Fri Sep 26 15:36:30 2014 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 26 Sep 2014 13:36:30 -0600 Subject: [SciPy-Dev] unicode_literals for string arguments In-Reply-To: <542543A5.8000200@hilboll.de> References: <542543A5.8000200@hilboll.de> Message-ID: On Fri, Sep 26, 2014 at 4:44 AM, Andreas Hilboll wrote: > Hi, > > I'm running into some issues which I attribute to not using from > __future__ import unicode_literals. I'm running Python2.7, and am > writing a script where I use from __future__ import unicode_literals. > This raises ValueErrors e.g. in stats.binned_statistic_2d: > > ValueError: statistic not understood > > Do you see a way to prevent these errors from happening? Obviously, > scipy should work no matter if a Py2 user uses from __future__ import > unicode_literals or not. > > Any ideas? > Yes, don't import unicode_literals ;) I didn't do that for the numpy code base as it caused problems that I didn't want to deal with. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Fri Sep 26 16:38:09 2014 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 26 Sep 2014 21:38:09 +0100 Subject: [SciPy-Dev] unicode_literals for string arguments In-Reply-To: References: <542543A5.8000200@hilboll.de> Message-ID: On 26 Sep 2014 20:38, "Charles R Harris" wrote: > > > > On Fri, Sep 26, 2014 at 4:44 AM, Andreas Hilboll wrote: >> >> Hi, >> >> I'm running into some issues which I attribute to not using from >> __future__ import unicode_literals. I'm running Python2.7, and am >> writing a script where I use from __future__ import unicode_literals. >> This raises ValueErrors e.g. in stats.binned_statistic_2d: >> >> ValueError: statistic not understood >> >> Do you see a way to prevent these errors from happening? Obviously, >> scipy should work no matter if a Py2 user uses from __future__ import >> unicode_literals or not. >> >> Any ideas? > > > Yes, don't import unicode_literals ;) I didn't do that for the numpy code base as it caused problems that I didn't want to deal with. This is sensible advice for numpy or scipy internally, but I think the issue here is that there's a public API which takes a string argument like statistic="mean", and it turns out that scipy doesn't grok statistic=u"mean" being passed in instead. I am sorta surprised that this is true, since IIUC in py2 both "mean" and u"mean" should compare == and hash the same, so the function ought to just work work. I think this is just a scipy bug that needs fixing? -n -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlucente at pipeline.com Tue Sep 30 21:59:54 2014 From: rlucente at pipeline.com (Robert Lucente - Pipeline) Date: Tue, 30 Sep 2014 21:59:54 -0400 Subject: [SciPy-Dev] scipy.optimize.anneal - deprecation Message-ID: <015801cfdd1b$6565a750$3030f5f0$@pipeline.com> Hi everyone, I am a newbie to open source and so I am not sure what the appropriate tribal norms are. So, if the "To" emailing is too broad, I apologize ahead of time. Please let me know if there is a more appropriate mailing list. I am also a newbie to Python. I haven't gotten much past the hello world stage. However, as I am poking around, simulated annealing got my attention because of a project that I am tangentially involved w/. As usual, I love "open source" because well, it is open. I can look at code and know exactly what is going on. I was surprised to learn that scipy.optimize.anneal is being deprecated. It is a "standard" mathematical optimization technique which is used. Also, there is a decent amount of literature on it. For some references, refer to the blog "Simulated Annealing (SA) for Mathematical Optimization ." The recommendation seems to be to use basinhopping. Unfortunately, it assumes "smooth scalar function". Unfortunately, this smoothness does not apply in my case. I am sure that the deprecation of anneal was given a lot of thought. Is that documented anywhere or would someone be willing to share why it was deprecated? -------------- next part -------------- An HTML attachment was scrubbed... URL: