From ralf.gommers at gmail.com Mon Dec 1 17:29:10 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 1 Dec 2014 23:29:10 +0100 Subject: [SciPy-Dev] SciPy under Android In-Reply-To: References: Message-ID: Hi, On Tue, Nov 25, 2014 at 10:39 AM, Apps Embedded wrote: > Hi, > > We are about publishing an Android app with all the SciPy python packages. > We will include : > - Python > - Numpy package > - Scipy package > - Matplotlib package > - pandas package > - Sympy package > - iPython > - nose package > > The app will be published under a freemium model. > The free app will include a small top ad banner and enable user to use all > the packages. However in this free app, graphics will not be available. > In the premium app for a very small fee under the Play Store, user will > have access to the same things as the free version but the top ad banner > will be removed and the graphics will be enabled with the use of Matplotlib. > > We are going to call these two apps "LabPy Console Free" and "LabPy > Console Premium". > > The licence of the work bundle will be GPL v3 but the Python software and > all the associated packages will stay in their respective licence. We will > of course publish the source code of all the project. > > We had recently the written approbation of the Python Trademark comittee > from a trademark point of view. > > We are writing this email to see if there are no legal issue we are > missing with the licence for example and if the name of the app LabPy > Console Free / Premium is ok from your point of view. > Thanks for asking. I don't see a problem with using that name. It was once suggested as a name for the Scipy stack ( http://article.gmane.org/gmane.comp.python.scientific.user/32570/match=labpy) but nothing happened with that. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From apps.embedded at gmail.com Tue Dec 2 03:55:56 2014 From: apps.embedded at gmail.com (Apps Embedded) Date: Tue, 2 Dec 2014 09:55:56 +0100 Subject: [SciPy-Dev] SciPy under Android In-Reply-To: References: Message-ID: Hi, Thanks for your answer. For your information, the two apps are now available under the Play Store. Here are the links: https://play.google.com/store/apps/details?id=com.appsopensource.labpy https://play.google.com/store/apps/details?id=com.appsopensource.labpypremium Best regards. Apps Embedded Team. 2014-12-01 23:29 GMT+01:00 Ralf Gommers : > Hi, > > On Tue, Nov 25, 2014 at 10:39 AM, Apps Embedded > wrote: > >> Hi, >> >> We are about publishing an Android app with all the SciPy python packages. >> We will include : >> - Python >> - Numpy package >> - Scipy package >> - Matplotlib package >> - pandas package >> - Sympy package >> - iPython >> - nose package >> >> The app will be published under a freemium model. >> The free app will include a small top ad banner and enable user to use >> all the packages. However in this free app, graphics will not be available. >> In the premium app for a very small fee under the Play Store, user will >> have access to the same things as the free version but the top ad banner >> will be removed and the graphics will be enabled with the use of Matplotlib. >> >> We are going to call these two apps "LabPy Console Free" and "LabPy >> Console Premium". >> >> The licence of the work bundle will be GPL v3 but the Python software and >> all the associated packages will stay in their respective licence. We will >> of course publish the source code of all the project. >> >> We had recently the written approbation of the Python Trademark comittee >> from a trademark point of view. >> >> We are writing this email to see if there are no legal issue we are >> missing with the licence for example and if the name of the app LabPy >> Console Free / Premium is ok from your point of view. >> > > Thanks for asking. I don't see a problem with using that name. It was once > suggested as a name for the Scipy stack ( > http://article.gmane.org/gmane.comp.python.scientific.user/32570/match=labpy) > but nothing happened with that. > > 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 bussonniermatthias at gmail.com Tue Dec 2 04:11:30 2014 From: bussonniermatthias at gmail.com (Matthias Bussonnier) Date: Tue, 2 Dec 2014 10:11:30 +0100 Subject: [SciPy-Dev] SciPy under Android In-Reply-To: References: Message-ID: Le 2 d?c. 2014 ? 09:55, Apps Embedded a ?crit : > Hi, > > Thanks for your answer. > > For your information, the two apps are now available under the Play Store. Here are the links: > https://play.google.com/store/apps/details?id=com.appsopensource.labpy > https://play.google.com/store/apps/details?id=com.appsopensource.labpypremium > > Best regards. Looks great ! Your casing of SciPy is inconsistent (sometime all lower case) If at some future release you can also write IPython with the proper casing (Upper case I) that would be even better ! Thanks ! -- M > > Apps Embedded Team. > > > > > 2014-12-01 23:29 GMT+01:00 Ralf Gommers : > Hi, > > On Tue, Nov 25, 2014 at 10:39 AM, Apps Embedded wrote: > Hi, > > We are about publishing an Android app with all the SciPy python packages. > We will include : > - Python > - Numpy package > - Scipy package > - Matplotlib package > - pandas package > - Sympy package > - iPython > - nose package > > The app will be published under a freemium model. > The free app will include a small top ad banner and enable user to use all the packages. However in this free app, graphics will not be available. > In the premium app for a very small fee under the Play Store, user will have access to the same things as the free version but the top ad banner will be removed and the graphics will be enabled with the use of Matplotlib. > > We are going to call these two apps "LabPy Console Free" and "LabPy Console Premium". > > The licence of the work bundle will be GPL v3 but the Python software and all the associated packages will stay in their respective licence. We will of course publish the source code of all the project. > > We had recently the written approbation of the Python Trademark comittee from a trademark point of view. > > We are writing this email to see if there are no legal issue we are missing with the licence for example and if the name of the app LabPy Console Free / Premium is ok from your point of view. > > Thanks for asking. I don't see a problem with using that name. It was once suggested as a name for the Scipy stack (http://article.gmane.org/gmane.comp.python.scientific.user/32570/match=labpy) but nothing happened with that. > > 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 apps.embedded at gmail.com Tue Dec 2 04:29:22 2014 From: apps.embedded at gmail.com (Apps Embedded) Date: Tue, 2 Dec 2014 10:29:22 +0100 Subject: [SciPy-Dev] SciPy under Android In-Reply-To: References: Message-ID: Hi, We have corrected the app description. The update will be available in a couple of hours under the Play Store. Best regards. Apps Embedded Team. 2014-12-02 10:11 GMT+01:00 Matthias Bussonnier : > > Le 2 d?c. 2014 ? 09:55, Apps Embedded a ?crit : > > Hi, > > Thanks for your answer. > > For your information, the two apps are now available under the Play Store. > Here are the links: > https://play.google.com/store/apps/details?id=com.appsopensource.labpy > > https://play.google.com/store/apps/details?id=com.appsopensource.labpypremium > > Best regards. > > > Looks great ! > Your casing of SciPy is inconsistent (sometime all lower case) > If at some future release you can also write IPython with the proper > casing (Upper case I) that would be even better ! > > Thanks ! > -- > M > > > > Apps Embedded Team. > > > > > 2014-12-01 23:29 GMT+01:00 Ralf Gommers : > >> Hi, >> >> On Tue, Nov 25, 2014 at 10:39 AM, Apps Embedded >> wrote: >> >>> Hi, >>> >>> We are about publishing an Android app with all the SciPy python >>> packages. >>> We will include : >>> - Python >>> - Numpy package >>> - Scipy package >>> - Matplotlib package >>> - pandas package >>> - Sympy package >>> - iPython >>> - nose package >>> >>> The app will be published under a freemium model. >>> The free app will include a small top ad banner and enable user to use >>> all the packages. However in this free app, graphics will not be available. >>> In the premium app for a very small fee under the Play Store, user will >>> have access to the same things as the free version but the top ad banner >>> will be removed and the graphics will be enabled with the use of Matplotlib. >>> >>> We are going to call these two apps "LabPy Console Free" and "LabPy >>> Console Premium". >>> >>> The licence of the work bundle will be GPL v3 but the Python software >>> and all the associated packages will stay in their respective licence. We >>> will of course publish the source code of all the project. >>> >>> We had recently the written approbation of the Python Trademark comittee >>> from a trademark point of view. >>> >>> We are writing this email to see if there are no legal issue we are >>> missing with the licence for example and if the name of the app LabPy >>> Console Free / Premium is ok from your point of view. >>> >> >> Thanks for asking. I don't see a problem with using that name. It was >> once suggested as a name for the Scipy stack ( >> http://article.gmane.org/gmane.comp.python.scientific.user/32570/match=labpy) >> but nothing happened with that. >> >> 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 > > > > _______________________________________________ > 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 bussonniermatthias at gmail.com Tue Dec 2 04:34:37 2014 From: bussonniermatthias at gmail.com (Matthias BUSSONNIER) Date: Tue, 2 Dec 2014 10:34:37 +0100 Subject: [SciPy-Dev] SciPy under Android In-Reply-To: References: Message-ID: <1CB1FC9F-68BA-41A3-8D83-89DA149670A0@gmail.com> Le 2 d?c. 2014 ? 10:29, Apps Embedded a ?crit : > Hi, > > We have corrected the app description. > The update will be available in a couple of hours under the Play Store. Thanks for the quick response ! -- M > > Best regards. > > Apps Embedded Team. > > > 2014-12-02 10:11 GMT+01:00 Matthias Bussonnier : > > Le 2 d?c. 2014 ? 09:55, Apps Embedded a ?crit : > >> Hi, >> >> Thanks for your answer. >> >> For your information, the two apps are now available under the Play Store. Here are the links: >> https://play.google.com/store/apps/details?id=com.appsopensource.labpy >> https://play.google.com/store/apps/details?id=com.appsopensource.labpypremium >> >> Best regards. > > Looks great ! > Your casing of SciPy is inconsistent (sometime all lower case) > If at some future release you can also write IPython with the proper casing (Upper case I) that would be even better ! > > Thanks ! > -- > M > > >> >> Apps Embedded Team. >> >> >> >> >> 2014-12-01 23:29 GMT+01:00 Ralf Gommers : >> Hi, >> >> On Tue, Nov 25, 2014 at 10:39 AM, Apps Embedded wrote: >> Hi, >> >> We are about publishing an Android app with all the SciPy python packages. >> We will include : >> - Python >> - Numpy package >> - Scipy package >> - Matplotlib package >> - pandas package >> - Sympy package >> - iPython >> - nose package >> >> The app will be published under a freemium model. >> The free app will include a small top ad banner and enable user to use all the packages. However in this free app, graphics will not be available. >> In the premium app for a very small fee under the Play Store, user will have access to the same things as the free version but the top ad banner will be removed and the graphics will be enabled with the use of Matplotlib. >> >> We are going to call these two apps "LabPy Console Free" and "LabPy Console Premium". >> >> The licence of the work bundle will be GPL v3 but the Python software and all the associated packages will stay in their respective licence. We will of course publish the source code of all the project. >> >> We had recently the written approbation of the Python Trademark comittee from a trademark point of view. >> >> We are writing this email to see if there are no legal issue we are missing with the licence for example and if the name of the app LabPy Console Free / Premium is ok from your point of view. >> >> Thanks for asking. I don't see a problem with using that name. It was once suggested as a name for the Scipy stack (http://article.gmane.org/gmane.comp.python.scientific.user/32570/match=labpy) but nothing happened with that. >> >> 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 > > > _______________________________________________ > 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 pierre.haessig at crans.org Tue Dec 2 06:52:07 2014 From: pierre.haessig at crans.org (Pierre Haessig) Date: Tue, 02 Dec 2014 12:52:07 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' Message-ID: <547DA7E7.8000209@crans.org> Hi, The scipy.signal.iirdesign function accepts different filter types like 'butter' or 'ellip' (cf. http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.iirdesign.html). However, it fails with the ftype 'bessel': ValueError: bessel does not have order selection. Use iirfilter function. This error is triggered at this line of code: https://github.com/scipy/scipy/blob/master/scipy/signal/filter_design.py#L645 So in practice, the iirdesign function cannot accept the 'bessel' type. Shouldn't we remove it from the docstring ? Or is this a pedagogical error, put here on purpose ? best, Pierre From irvin.probst at ensta-bretagne.fr Tue Dec 2 12:10:25 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Tue, 02 Dec 2014 18:10:25 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: <54765736.5020506@supsi.ch> References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> <54765736.5020506@supsi.ch> Message-ID: <547DF281.7080404@ensta-bretagne.fr> Hi all, please find attached what I wrote for pole placement. I used the famous KNV algorithms (Kautsky, Nichols, Van Dooreen) method 0 and 1 (see Robust Pole assignments in linear state feedback, http://la.epfl.ch/files/content/sites/la/files/users/105941/public/KautskyNicholsDooren ) Method 0 is what Matlab uses, in this implementation it works well if the poles are real, I think I can fix it to work with complex poles also but it's not my top priority. Method 1 is another approach to get the same results, it works most of the time but on some specific cases it fails. It is related to rank(X) decreasing sometimes over the iteration process but I simply can't understand what I'm missing here. As this method yields the same results as method 0 but is much more difficult to implement, I'm not sure I'll investigate this any further. Now knowing the Matlab licensing issue, I used their source code to stay as far as possible from their implementation. Especially they use SVD decomposition all over step A and step F (see p 1144-1145) of the algorithm so I used QR decomposition instead. In step X, method 0 however there is no magic, we implemented the same algorithm so it looks the same ! So if the scipy maintainers think the licensing issues are cleared I would be very happy to work further on the code of method0 in order to integrate it to Scipy, or if is definitely a problem to use the same algorithm as Matlab then I could try to implement method 2/3 if I find some time but I can't promise anything. Finally please discard the tests in the main part of the code, I used matlab to check if my code worked as expected. P.S: Ralf, as I made some changes since yesterday I thought it was better to avoid spamming you and send this directly to the ML. -------------- next part -------------- A non-text attachment was scrubbed... Name: pole.py Type: text/x-python Size: 8564 bytes Desc: not available URL: From yw5aj at virginia.edu Tue Dec 2 14:53:29 2014 From: yw5aj at virginia.edu (Yuxiang Wang) Date: Tue, 2 Dec 2014 14:53:29 -0500 Subject: [SciPy-Dev] Documentation page on API In-Reply-To: References: Message-ID: #bump# On Mon, Oct 27, 2014 at 9:48 PM, Yuxiang Wang wrote: > (Sorry about sending this to the wrong list, scipy-user instead of > scipy-dev, before; apologize to those who saw this twice) > > Hi all, > > I was reading through the link > ( > http://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing-functions-from-scipy > ) > and it mentioned that the first form is > preferred over the second one under most circumstances: > > # first form > from scipy import stats > stats.lomax(...) > > # second form > from scipy.stats import distributions > distributions.lomax(...) > > I honestly think the second form is far more frequently used in the > examples given in the document, for example: > > http://docs.scipy.org/doc/scipy/reference/tutorial/special.html > http://docs.scipy.org/doc/scipy/reference/tutorial/integrate.html > http://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html > http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html > http://docs.scipy.org/doc/scipy/reference/tutorial/fftpack.html > > Would you think it'd be better to update this link? > > -Shawn > -- Yuxiang "Shawn" Wang Gerling Research Lab University of Virginia yw5aj at virginia.edu +1 (434) 284-0836 https://sites.google.com/a/virginia.edu/yw5aj/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Dec 3 17:49:27 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 3 Dec 2014 23:49:27 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' In-Reply-To: <547DA7E7.8000209@crans.org> References: <547DA7E7.8000209@crans.org> Message-ID: On Tue, Dec 2, 2014 at 12:52 PM, Pierre Haessig wrote: > Hi, > > The scipy.signal.iirdesign function accepts different filter types like > 'butter' or 'ellip' (cf. > > http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.signal.iirdesign.html > ). > > However, it fails with the ftype 'bessel': > ValueError: bessel does not have order selection. Use iirfilter function. > > This error is triggered at this line of code: > > https://github.com/scipy/scipy/blob/master/scipy/signal/filter_design.py#L645 > > So in practice, the iirdesign function cannot accept the 'bessel' type. > Shouldn't we remove it from the docstring ? > Or is this a pedagogical error, put here on purpose ? > I'm not sure what that's supposed to teach. It would be good to remove 'bessel' from the docs. Also, iirdesign() has the impressive number of zero tests. Care to send a PR for this? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Thu Dec 4 08:36:48 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 04 Dec 2014 14:36:48 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' In-Reply-To: <547DA7E7.8000209@crans.org> References: <547DA7E7.8000209@crans.org> Message-ID: On 02/12/14 12:52, Pierre Haessig wrote: > So in practice, the iirdesign function cannot accept the 'bessel' type. > Shouldn't we remove it from the docstring ? > Or is this a pedagogical error, put here on purpose ? Looking at the code, it seems the problem is that there is no 'besselord' function. Cf. buttord, cheb1ord, cheb2ord, ellipord and the filter_dict. I am not sure if this is a deliberate omission or not. Sturla From warren.weckesser at gmail.com Fri Dec 5 07:15:47 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Fri, 5 Dec 2014 07:15:47 -0500 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow Message-ID: Could someone with a Windows installation of scipy 0.14.0 run the code at http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad? It works for me on Mac OS X. In the comments to the question, Jonathan March reported that the problem occurs with both 32 and 64 bit Windows 7. Does the code work for anyone using Windows? ("Work" means the values reported for 'Intf1corr' and 'Intf2' are the same.) Warren From pierre.haessig at crans.org Fri Dec 5 07:20:02 2014 From: pierre.haessig at crans.org (Pierre Haessig) Date: Fri, 05 Dec 2014 13:20:02 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' In-Reply-To: References: <547DA7E7.8000209@crans.org> Message-ID: <5481A2F2.2070007@crans.org> Le 04/12/2014 14:36, Sturla Molden a ?crit : > Looking at the code, it seems the problem is that there is no > 'besselord' function. Cf. buttord, cheb1ord, cheb2ord, ellipord and the > filter_dict. I am not sure if this is a deliberate omission or not. It seems there is none in Matlab too http://www.mathworks.com/help/signal/ug/iir-filter-design.html I'm not familiar enough with Bessel filters to know if order estimation is possible or not for this class. best; Pierre From sturla.molden at gmail.com Fri Dec 5 07:26:04 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 05 Dec 2014 13:26:04 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' In-Reply-To: <5481A2F2.2070007@crans.org> References: <547DA7E7.8000209@crans.org> <5481A2F2.2070007@crans.org> Message-ID: On 05/12/14 13:20, Pierre Haessig wrote: > It seems there is none in Matlab too > http://www.mathworks.com/help/signal/ug/iir-filter-design.html > > I'm not familiar enough with Bessel filters to know if order estimation > is possible or not for this class. Neither am I. Sturla From charlesnwoods at gmail.com Fri Dec 5 11:12:54 2014 From: charlesnwoods at gmail.com (Gmail) Date: Fri, 5 Dec 2014 09:12:54 -0700 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: > On Dec 5, 2014, at 5:15 AM, Warren Weckesser wrote: > > Could someone with a Windows installation of scipy 0.14.0 run the code > at http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad? > > It works for me on Mac OS X. In the comments to the question, > Jonathan March reported that the problem occurs with both 32 and 64 > bit Windows 7. Does the code work for anyone using Windows? ("Work" > means the values reported for 'Intf1corr' and 'Intf2' are the same.) > > Warren > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev Can someone ask whether or not the old function dblquad gives the same incorrect results? SO won?t let me comment yet, and I don?t think it?s really an answer... From cournape at gmail.com Fri Dec 5 11:49:15 2014 From: cournape at gmail.com (David Cournapeau) Date: Fri, 5 Dec 2014 16:49:15 +0000 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: On Fri, Dec 5, 2014 at 12:15 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > Could someone with a Windows installation of scipy 0.14.0 run the code > at > http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad > ? > > It works for me on Mac OS X. In the comments to the question, > Jonathan March reported that the problem occurs with both 32 and 64 > bit Windows 7. Does the code work for anyone using Windows? ("Work" > means the values reported for 'Intf1corr' and 'Intf2' are the same.) I briefly looked at it: * canopy (numpy 1.8.1 and scipy 0.14.0, VS 2008 + ifort + MKL): bug * gholke eggs on python 3.4 w/ numpy 1.9.1 and scipy 0.14.0 (MKL as well): bug * official binaries on 2.7: no bug I suspect either an ifort/MKL bug, or some bad interactions between scipy and this config. I will update once I have time to actually look into the issue. David > Warren > _______________________________________________ > 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 Dec 5 12:37:51 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 5 Dec 2014 18:37:51 +0100 Subject: [SciPy-Dev] iirdesign fails with ftype='bessel' In-Reply-To: References: <547DA7E7.8000209@crans.org> <5481A2F2.2070007@crans.org> Message-ID: On Fri, Dec 5, 2014 at 1:26 PM, Sturla Molden wrote: > On 05/12/14 13:20, Pierre Haessig wrote: > > > It seems there is none in Matlab too > > http://www.mathworks.com/help/signal/ug/iir-filter-design.html > > > > I'm not familiar enough with Bessel filters to know if order estimation > > is possible or not for this class. > > Neither am I. > Same here. Given that Matlab doesn't have it, I'd guess no though. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From irvin.probst at ensta-bretagne.fr Fri Dec 5 12:43:03 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Fri, 05 Dec 2014 18:43:03 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: <547DF281.7080404@ensta-bretagne.fr> References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> <54765736.5020506@supsi.ch> <547DF281.7080404@ensta-bretagne.fr> Message-ID: <5481EEA7.10200@ensta-bretagne.fr> Hi all, I have finished a new version of a tentative place function for Scipy with Yang Tits' algorithm (improvement over KNV method 0), the user can choose between both Yang Tits or KNV at runtime (method="YT" or method="KNV0"). See http://drum.lib.umd.edu/handle/1903/5598 I think YT is what Slicot uses but this time I played it safe and I did not check the source code, this implementation is 100% original (with all that it implies regarding bugs...). Once again only real poles are supported, rough tests show that YT gives better conditioning of the eigen vectors of (A-BK) on 50% of my tests, KNV 25% and they are equal otherwise. Please not that these are only rough tests with dumb random matrices, it is not a claim over the respective performances of these algorithms in real life, and I'm pretty sure my implementation does not give results as clean as the original matlab/fortran code polished over decades does (I plan to test that later). Is there a documentation/tutorial anywhere about what should or should not be done when trying to include code into Scipy ? I mean coding style, patch format and so on. Regards. P.S: I did not attach my code to this email as it is not yet clean enough but I would be pleased to send it to anyone who requests it -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Fri Dec 5 12:54:51 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Fri, 5 Dec 2014 12:54:51 -0500 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: On Fri, Dec 5, 2014 at 11:12 AM, Gmail wrote: > > > On Dec 5, 2014, at 5:15 AM, Warren Weckesser > wrote: > > > > Could someone with a Windows installation of scipy 0.14.0 run the code > > at > http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad > ? > > > > It works for me on Mac OS X. In the comments to the question, > > Jonathan March reported that the problem occurs with both 32 and 64 > > bit Windows 7. Does the code work for anyone using Windows? ("Work" > > means the values reported for 'Intf1corr' and 'Intf2' are the same.) > > > > Warren > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > Can someone ask whether or not the old function dblquad gives the same > incorrect results? SO won?t let me comment yet, and I don?t think it?s > really an answer... > Good idea. I added a comment with the suggestion to check dblquad. Warren > _______________________________________________ > 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 Fri Dec 5 12:55:26 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Fri, 5 Dec 2014 12:55:26 -0500 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: On Fri, Dec 5, 2014 at 11:49 AM, David Cournapeau wrote: > > > On Fri, Dec 5, 2014 at 12:15 PM, Warren Weckesser < > warren.weckesser at gmail.com> wrote: > >> Could someone with a Windows installation of scipy 0.14.0 run the code >> at >> http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad >> ? >> >> It works for me on Mac OS X. In the comments to the question, >> Jonathan March reported that the problem occurs with both 32 and 64 >> bit Windows 7. Does the code work for anyone using Windows? ("Work" >> means the values reported for 'Intf1corr' and 'Intf2' are the same.) > > > I briefly looked at it: > > * canopy (numpy 1.8.1 and scipy 0.14.0, VS 2008 + ifort + MKL): bug > * gholke eggs on python 3.4 w/ numpy 1.9.1 and scipy 0.14.0 (MKL as > well): bug > * official binaries on 2.7: no bug > > I suspect either an ifort/MKL bug, or some bad interactions between scipy > and this config. I will update once I have time to actually look into the > issue. > > David > > Thanks, David. Warren > >> Warren >> _______________________________________________ >> 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 roberto.bucher at supsi.ch Sat Dec 6 12:03:40 2014 From: roberto.bucher at supsi.ch (SUPSI) Date: Sat, 06 Dec 2014 18:03:40 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: <5481EEA7.10200@ensta-bretagne.fr> References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> <54765736.5020506@supsi.ch> <547DF281.7080404@ensta-bretagne.fr> <5481EEA7.10200@ensta-bretagne.fr> Message-ID: <548336EC.7060607@supsi.ch> Pole placement without complex poles is not usable in praxis. Usaually we put all the poles on the bandwidth circle, chhosing damping factors to have 3%-5% of overshooting. At present, I'm using a pole plecement routine combined with a Fortran wrapper calling the procedures from an old slycot library. This the same solution implemented in Scicoslab, NSP and I think scilab too. The good conditioning of the results is demostrated by a set of practical implementations on real plants in our laboratory at the SUPSI. Best regards Roberto On 12/05/2014 06:43 PM, Irvin Probst wrote: > Hi all, > I have finished a new version of a tentative place function for Scipy > with Yang Tits' algorithm (improvement over KNV method 0), the user > can choose between both Yang Tits or KNV at runtime (method="YT" or > method="KNV0"). See http://drum.lib.umd.edu/handle/1903/5598 > > I think YT is what Slicot uses but this time I played it safe and I > did not check the source code, this implementation is 100% original > (with all that it implies regarding bugs...). > > Once again only real poles are supported, rough tests show that YT > gives better conditioning of the eigen vectors of (A-BK) on 50% of my > tests, KNV 25% and they are equal otherwise. Please not that these are > only rough tests with dumb random matrices, it is not a claim over the > respective performances of these algorithms in real life, and I'm > pretty sure my implementation does not give results as clean as the > original matlab/fortran code polished over decades does (I plan to > test that later). > > Is there a documentation/tutorial anywhere about what should or should > not be done when trying to include code into Scipy ? I mean coding > style, patch format and so on. > > Regards. > > P.S: I did not attach my code to this email as it is not yet clean > enough but I would be pleased to send it to anyone who requests it > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: yottalab.py Type: text/x-python Size: 15577 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dqrdc.f Type: text/x-fortran Size: 7099 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dqrsl.f Type: text/x-fortran Size: 9141 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dqrsm.f Type: text/x-fortran Size: 4769 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hhdml.f Type: text/x-fortran Size: 6682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: polmc.f Type: text/x-fortran Size: 13929 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ssxmc.f Type: text/x-fortran Size: 7918 bytes Desc: not available URL: -------------- next part -------------- python module _wrapper ! in interface ! in :_wrapper subroutine ssxmc(n,m,a,na,b,ncont,indcon,nblk,z,wrka,wrk1,wrk2,iwrk,tol,mode) integer, required,check(shape(a,1)==n),depend(a) :: n=shape(a,1) integer, required,check(shape(b,1)==m),depend(b) :: m=shape(b,1) double precision intent(in, out, copy), dimension(na,n) :: a integer, required,check(shape(a,0)==na),depend(a) :: na=shape(a,0) double precision intent(in, out, copy), dimension(na,m),depend(na) :: b integer intent(out) :: ncont integer intent(out) :: indcon integer intent(out), dimension(n),depend(n) :: nblk double precision intent(out), dimension(na,n),depend(na,n) :: z double precision dimension(n,m),depend(n,m) :: wrka double precision dimension(m),depend(m) :: wrk1 double precision dimension(m),depend(m) :: wrk2 integer dimension(m),depend(m) :: iwrk double precision :: tol integer :: mode end subroutine ssxmc subroutine polmc(nm,ng,n,m,a,b,g,wr,wi,z,inc,invr,ierr,jpvt,rm1,rm2,rv1,rv2,rv3,rv4) integer, optional,check(shape(a,0)==nm),depend(a) :: nm=shape(a,0) integer, optional ,check(shape(g,0)==ng),depend(g) :: ng=shape(g,0) integer, optional,check(shape(a,1)==n),depend(a) :: n=shape(a,1) integer, optional,check(shape(b,1)==m),depend(b) :: m=shape(b,1) double precision intent(in,out, copy), dimension(nm,n) :: a double precision intent(in,out, copy), dimension(nm,m),depend(nm) :: b double precision intent(in,out,copy), dimension(ng,n),depend(n) :: g double precision dimension(n),depend(n) :: wr double precision dimension(n),depend(n) :: wi double precision intent(in,out,copy), dimension(nm,n),depend(nm,n) :: z integer :: inc integer dimension(n),depend(n) :: invr integer intent(out) :: ierr integer intent(out), dimension(m),depend(m) :: jpvt double precision dimension(m,m),depend(m,m) :: rm1 double precision dimension(m,*),depend(m) :: rm2 double precision dimension(n),depend(n) :: rv1 double precision dimension(n),depend(n) :: rv2 double precision dimension(m),depend(m) :: rv3 double precision dimension(m),depend(m) :: rv4 end subroutine polmc end interface end python module _wrapper From warren.weckesser at gmail.com Mon Dec 8 17:14:48 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 8 Dec 2014 17:14:48 -0500 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: On 12/5/14, Gmail wrote: > >> On Dec 5, 2014, at 5:15 AM, Warren Weckesser >> wrote: >> >> Could someone with a Windows installation of scipy 0.14.0 run the code >> at >> http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad? >> >> It works for me on Mac OS X. In the comments to the question, >> Jonathan March reported that the problem occurs with both 32 and 64 >> bit Windows 7. Does the code work for anyone using Windows? ("Work" >> means the values reported for 'Intf1corr' and 'Intf2' are the same.) >> >> Warren >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev > > Can someone ask whether or not the old function dblquad gives the same > incorrect results? SO won?t let me comment yet, and I don?t think it?s > really an answer... The author of the question reported in a comment that dblquad also gives the wrong result (http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-nquad). Warren > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From charlesnwoods at gmail.com Mon Dec 8 17:23:24 2014 From: charlesnwoods at gmail.com (Gmail) Date: Mon, 8 Dec 2014 15:23:24 -0700 Subject: [SciPy-Dev] Problem with scipy.integrate.nquad reported on stackoverflow In-Reply-To: References: Message-ID: At least they?re giving consistent results. nquad and dblquad are both just wrappers that call scipy.integrate.quad on itself, so it seems that something about this recursion is interacting badly, maybe with MKL. Maybe the bug can be reproduced with just a call to quad? I?m afraid my knowledge of the .integrate package peters out about here. N > On Dec 8, 2014, at 3:14 PM, Warren Weckesser wrote: > > On 12/5/14, Gmail wrote: >> >>> On Dec 5, 2014, at 5:15 AM, Warren Weckesser >>> wrote: >>> >>> Could someone with a Windows installation of scipy 0.14.0 run the code >>> at >>> http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-ndquad? >>> >>> It works for me on Mac OS X. In the comments to the question, >>> Jonathan March reported that the problem occurs with both 32 and 64 >>> bit Windows 7. Does the code work for anyone using Windows? ("Work" >>> means the values reported for 'Intf1corr' and 'Intf2' are the same.) >>> >>> Warren >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> Can someone ask whether or not the old function dblquad gives the same >> incorrect results? SO won?t let me comment yet, and I don?t think it?s >> really an answer... > > > > The author of the question reported in a comment that dblquad also > gives the wrong result > (http://stackoverflow.com/questions/27270044/big-integration-error-with-integrate-nquad). > > Warren > > >> _______________________________________________ >> 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 From ewm at redtetrahedron.org Tue Dec 9 09:22:04 2014 From: ewm at redtetrahedron.org (Eric Moore) Date: Tue, 9 Dec 2014 09:22:04 -0500 Subject: [SciPy-Dev] Adding routines for updating QR decompositions Message-ID: Hi, I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete for performing rank-k updates, adding rows or columns and removing rows or colums. https://github.com/scipy/scipy/pull/4249 Comments welcome. Eric. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irvin.probst at ensta-bretagne.fr Tue Dec 9 09:24:23 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Tue, 09 Dec 2014 15:24:23 +0100 Subject: [SciPy-Dev] Adding routines for updating QR decompositions In-Reply-To: References: Message-ID: <54870617.4020500@ensta-bretagne.fr> On 09/12/2014 15:22, Eric Moore wrote: > I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete > for performing rank-k updates, adding rows or columns and removing > rows or colums. That's exactly what I was looking for in order to speed up my pole placement routines ! Actually I was about to start coding this myself tomorrow. I would really like to have this into scipy. Have a nice day. From clarkfitzg at gmail.com Tue Dec 9 10:15:05 2014 From: clarkfitzg at gmail.com (Clark Fitzgerald) Date: Tue, 9 Dec 2014 07:15:05 -0800 Subject: [SciPy-Dev] Adding routines for updating QR decompositions In-Reply-To: <54870617.4020500@ensta-bretagne.fr> References: <54870617.4020500@ensta-bretagne.fr> Message-ID: I was looking for this functionality recently- this would be useful. Thanks! On Tue, Dec 9, 2014 at 6:24 AM, Irvin Probst wrote: > On 09/12/2014 15:22, Eric Moore wrote: > > I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete > > for performing rank-k updates, adding rows or columns and removing > > rows or colums. > > That's exactly what I was looking for in order to speed up my pole > placement routines ! Actually I was about to start coding this myself > tomorrow. I would really like to have this into scipy. > Have a nice day. > > _______________________________________________ > 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 Tue Dec 9 10:28:53 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 9 Dec 2014 10:28:53 -0500 Subject: [SciPy-Dev] Adding routines for updating QR decompositions In-Reply-To: References: <54870617.4020500@ensta-bretagne.fr> Message-ID: On Tue, Dec 9, 2014 at 10:15 AM, Clark Fitzgerald wrote: > I was looking for this functionality recently- this would be useful. > > Thanks! > > On Tue, Dec 9, 2014 at 6:24 AM, Irvin Probst < > irvin.probst at ensta-bretagne.fr> wrote: > >> On 09/12/2014 15:22, Eric Moore wrote: >> > I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete >> > for performing rank-k updates, adding rows or columns and removing >> > rows or colums. >> >> That's exactly what I was looking for in order to speed up my pole >> placement routines ! Actually I was about to start coding this myself >> tomorrow. I would really like to have this into scipy. >> Have a nice day. >> > Same here, good to see this arriving in scipy I as looking for this some months ago. (although, IIRC, I ended up with Q-less R updating for the special use case of out of memory least squares.) Josef > >> _______________________________________________ >> 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 josef.pktd at gmail.com Tue Dec 9 12:06:38 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 9 Dec 2014 12:06:38 -0500 Subject: [SciPy-Dev] Adding routines for updating QR decompositions In-Reply-To: References: <54870617.4020500@ensta-bretagne.fr> Message-ID: On Tue, Dec 9, 2014 at 10:28 AM, wrote: > > > On Tue, Dec 9, 2014 at 10:15 AM, Clark Fitzgerald > wrote: > >> I was looking for this functionality recently- this would be useful. >> >> Thanks! >> >> On Tue, Dec 9, 2014 at 6:24 AM, Irvin Probst < >> irvin.probst at ensta-bretagne.fr> wrote: >> >>> On 09/12/2014 15:22, Eric Moore wrote: >>> > I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete >>> > for performing rank-k updates, adding rows or columns and removing >>> > rows or colums. >>> >>> That's exactly what I was looking for in order to speed up my pole >>> placement routines ! Actually I was about to start coding this myself >>> tomorrow. I would really like to have this into scipy. >>> Have a nice day. >>> >> > > Same here, good to see this arriving in scipy > > I as looking for this some months ago. > > (although, IIRC, I ended up with Q-less R updating for the special use > case of out of memory least squares.) > That was just the first application that I remembered. In other cases like best or all subset regression we need something like this. In my functions for subset regression I had to work around these missing features. Thanks, Josef > > Josef > > > > >> >>> _______________________________________________ >>> 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 alexandre.gramfort at inria.fr Tue Dec 9 15:30:06 2014 From: alexandre.gramfort at inria.fr (Alexandre Gramfort) Date: Tue, 9 Dec 2014 21:30:06 +0100 Subject: [SciPy-Dev] Adding routines for updating QR decompositions In-Reply-To: References: <54870617.4020500@ensta-bretagne.fr> Message-ID: hi, I think it would be indeed a nice contrib. On the same line you have in scikit-learn [1] an implementation of cholesky update and downdate which might be useful to a broader audience. Best, Alex [1] https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/linear_model/least_angle.py On Tue, Dec 9, 2014 at 6:06 PM, wrote: > > > On Tue, Dec 9, 2014 at 10:28 AM, wrote: >> >> >> >> On Tue, Dec 9, 2014 at 10:15 AM, Clark Fitzgerald >> wrote: >>> >>> I was looking for this functionality recently- this would be useful. >>> >>> Thanks! >>> >>> On Tue, Dec 9, 2014 at 6:24 AM, Irvin Probst >>> wrote: >>>> >>>> On 09/12/2014 15:22, Eric Moore wrote: >>>> > I've just submitted PR #4249 adding qr_update, qr_insert and qr_delete >>>> > for performing rank-k updates, adding rows or columns and removing >>>> > rows or colums. >>>> >>>> That's exactly what I was looking for in order to speed up my pole >>>> placement routines ! Actually I was about to start coding this myself >>>> tomorrow. I would really like to have this into scipy. >>>> Have a nice day. >> >> >> >> Same here, good to see this arriving in scipy >> >> I as looking for this some months ago. >> >> (although, IIRC, I ended up with Q-less R updating for the special use >> case of out of memory least squares.) > > > That was just the first application that I remembered. > > In other cases like best or all subset regression we need something like > this. In my functions for subset regression I had to work around these > missing features. > > Thanks, > > Josef > >> >> >> Josef >> >> >> >>>> >>>> >>>> _______________________________________________ >>>> 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 > From dsweeney at scimentis.com Thu Dec 11 12:09:37 2014 From: dsweeney at scimentis.com (Deacon Sweeney) Date: Thu, 11 Dec 2014 12:09:37 -0500 Subject: [SciPy-Dev] Several packages failing on sparse/csgraph/_validation.py Message-ID: Hello, I'm having an unusual bug on a fresh installation of scipy on SUSE, with Python 2.7.8. There are several packages (stats, sparse, optimize, interpolate, etc) that all fail to import due to sparse/csgraph/_validation.py. Here is the error message from sparse: >>> import scipy.sparse Traceback (most recent call last): File "", line 1, in File "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/__init__.py", line 206, in from scipy.sparse.csgraph import _validation File "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/csgraph/__init__.py", line 122, in from scipy.sparse.csgraph import _validation File "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/csgraph/_validation.py", line 4, in from scipy.sparse import csr_matrix, isspmatrix, isspmatrix_csc, isspmatrix_csr ImportError: cannot import name csr_matrix We have a bit of an unusual installation arrangement here, where I have to use the "module load" command to switch Python versions. I can't find anything searching around, so I figured I'd reach out to the experts here while digging in further myself. Any insights would be very appreciated! Thanks, Deacon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rnelsonchem at gmail.com Thu Dec 11 13:29:35 2014 From: rnelsonchem at gmail.com (Ryan Nelson) Date: Thu, 11 Dec 2014 13:29:35 -0500 Subject: [SciPy-Dev] Cookbook update Message-ID: Hello Scipy-devs: The link below on building a Qt app with a Matplotlib widget is very dated. http://wiki.scipy.org/Cookbook/Matplotlib/Qt_with_IPython_and_Designer After several research/trial/error cycles, I reproduced the Qt4 plot window that you using the relevant pyplot commands. I suppose I could update the Cookbook page above, but I need editing rights. Is this still possible, or are we trying to point users to a new location? Ryan P.S. Here's the relevant code, in case it matters. File = run.py ------------------------------------------------------------------------- from test import Ui_MainWindow from matplotlib.figure import Figure from matplotlib.backends.backend_qt4agg import ( FigureCanvasQTAgg as FigureCanvas, NavigationToolbar2QT as NavigationToolbar) from PyQt4 import QtGui class Main(QtGui.QMainWindow, Ui_MainWindow): def __init__(self, ): super(Main, self).__init__() self.setupUi(self) self.populatefigure() self.addtoolbar() self.plotdata() def populatefigure(self,): self.fig = Figure() self.canvas = FigureCanvas(self.fig) self.canvas.setParent(self.MplFigure) self.mplvbox = QtGui.QVBoxLayout() self.mplvbox.addWidget(self.canvas) self.MplFigure.setLayout(self.mplvbox) def addtoolbar(self,): self.toolbar = NavigationToolbar(self.canvas, self, coordinates=True) self.addToolBar(self.toolbar) def addtoolbar2(self,): self.toolbar = NavigationToolbar(self.canvas, self.MplFigure, coordinates=True) self.mplvbox.addWidget(self.toolbar) def plotdata(self,): self.axes = self.fig.add_subplot(111) self.axes.plot([1,3,2]) self.canvas.draw() if __name__ == "__main__": ''' Run IPython as follows: $ ipython --gui='qt' [In 1]: %run run.py If running this file directly from the command line, remove the comments below and do the following: $ python run.py ''' #import sys #app = QtGui.QApplication([]) main = Main() main.show() #sys.exit(app.exec_()) ------------------------------------------------- File = test.py (created with Designer and pyuic4) ------------------------------------------------------------------- # -*- coding: utf-8 -*- # Form implementation generated from reading ui file 'test.ui' # # Created: Thu Dec 11 12:32:15 2014 # by: PyQt4 UI code generator 4.11.3 # # WARNING! All changes made in this file will be lost! from PyQt4 import QtCore, QtGui try: _fromUtf8 = QtCore.QString.fromUtf8 except AttributeError: def _fromUtf8(s): return s try: _encoding = QtGui.QApplication.UnicodeUTF8 def _translate(context, text, disambig): return QtGui.QApplication.translate(context, text, disambig, _encoding) except AttributeError: def _translate(context, text, disambig): return QtGui.QApplication.translate(context, text, disambig) class Ui_MainWindow(object): def setupUi(self, MainWindow): MainWindow.setObjectName(_fromUtf8("MainWindow")) MainWindow.resize(800, 600) self.centralwidget = QtGui.QWidget(MainWindow) self.centralwidget.setObjectName(_fromUtf8("centralwidget")) self.gridLayout = QtGui.QGridLayout(self.centralwidget) self.gridLayout.setObjectName(_fromUtf8("gridLayout")) self.MplFigure = QtGui.QWidget(self.centralwidget) self.MplFigure.setObjectName(_fromUtf8("MplFigure")) self.gridLayout.addWidget(self.MplFigure, 0, 0, 1, 1) MainWindow.setCentralWidget(self.centralwidget) self.retranslateUi(MainWindow) QtCore.QMetaObject.connectSlotsByName(MainWindow) def retranslateUi(self, MainWindow): MainWindow.setWindowTitle(_translate("MainWindow", "MainWindow", None)) ------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Thu Dec 11 13:56:26 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Thu, 11 Dec 2014 13:56:26 -0500 Subject: [SciPy-Dev] Cookbook update In-Reply-To: References: Message-ID: On Thu, Dec 11, 2014 at 1:29 PM, Ryan Nelson wrote: > Hello Scipy-devs: > > The link below on building a Qt app with a Matplotlib widget is very dated. > http://wiki.scipy.org/Cookbook/Matplotlib/Qt_with_IPython_and_Designer > > After several research/trial/error cycles, I reproduced the Qt4 plot > window that you using the relevant pyplot commands. I suppose I could > update the Cookbook page above, but I need editing rights. Is this still > possible, or are we trying to point users to a new location? > > Ryan > > This is a timely question. In the last few weeks, I've run into a couple things I'd like to update: * At http://wiki.scipy.org/Cookbook/LASReader, I want to add a link to the latest version, which is now on github: https://github.com/WarrenWeckesser/las * I've seen at least three occurrences (a couple on stackoverflow, and one private email) of someone using the argument 'order=15' in a call to the 'set_integrator' method of 'scipy.integrate.ode'. Presumably this is because of the suggestion in the "NumPy for Matlab Users" page on the wiki ( http://wiki.scipy.org/NumPy_for_Matlab_Users) to replace 'ode15s' with ' scipy.integrate.ode(f).set_integrator('vode', method='bdf', order=15)'. This is pointless, because the stiff solver in 'vode'--presumably the solver of interest for someone using 'ode15s'--has a maximum order of 5, and the non-stiff solver has maximum order of 12. (The maximum order of 'ode15s' is also 5; the '15' in the name refers to the variable order ranging from 1 to 5.) I can log in, but I can't edit either of those pages. Warren P.S. Here's the relevant code, in case it matters. > > File = run.py > ------------------------------------------------------------------------- > from test import Ui_MainWindow > > from matplotlib.figure import Figure > from matplotlib.backends.backend_qt4agg import ( > FigureCanvasQTAgg as FigureCanvas, > NavigationToolbar2QT as NavigationToolbar) > > from PyQt4 import QtGui > > class Main(QtGui.QMainWindow, Ui_MainWindow): > def __init__(self, ): > super(Main, self).__init__() > self.setupUi(self) > > self.populatefigure() > self.addtoolbar() > self.plotdata() > > def populatefigure(self,): > self.fig = Figure() > self.canvas = FigureCanvas(self.fig) > self.canvas.setParent(self.MplFigure) > > self.mplvbox = QtGui.QVBoxLayout() > self.mplvbox.addWidget(self.canvas) > self.MplFigure.setLayout(self.mplvbox) > > def addtoolbar(self,): > self.toolbar = NavigationToolbar(self.canvas, self, > coordinates=True) > self.addToolBar(self.toolbar) > > def addtoolbar2(self,): > self.toolbar = NavigationToolbar(self.canvas, self.MplFigure, > coordinates=True) > self.mplvbox.addWidget(self.toolbar) > > def plotdata(self,): > self.axes = self.fig.add_subplot(111) > self.axes.plot([1,3,2]) > self.canvas.draw() > > if __name__ == "__main__": > ''' > Run IPython as follows: > $ ipython --gui='qt' > [In 1]: %run run.py > If running this file directly from the command line, remove the > comments > below and do the following: > $ python run.py > ''' > > #import sys > #app = QtGui.QApplication([]) > main = Main() > main.show() > #sys.exit(app.exec_()) > ------------------------------------------------- > > File = test.py (created with Designer and pyuic4) > ------------------------------------------------------------------- > # -*- coding: utf-8 -*- > > # Form implementation generated from reading ui file 'test.ui' > # > # Created: Thu Dec 11 12:32:15 2014 > # by: PyQt4 UI code generator 4.11.3 > # > # WARNING! All changes made in this file will be lost! > > from PyQt4 import QtCore, QtGui > > try: > _fromUtf8 = QtCore.QString.fromUtf8 > except AttributeError: > def _fromUtf8(s): > return s > > try: > _encoding = QtGui.QApplication.UnicodeUTF8 > def _translate(context, text, disambig): > return QtGui.QApplication.translate(context, text, disambig, > _encoding) > except AttributeError: > def _translate(context, text, disambig): > return QtGui.QApplication.translate(context, text, disambig) > > class Ui_MainWindow(object): > def setupUi(self, MainWindow): > MainWindow.setObjectName(_fromUtf8("MainWindow")) > MainWindow.resize(800, 600) > self.centralwidget = QtGui.QWidget(MainWindow) > self.centralwidget.setObjectName(_fromUtf8("centralwidget")) > self.gridLayout = QtGui.QGridLayout(self.centralwidget) > self.gridLayout.setObjectName(_fromUtf8("gridLayout")) > self.MplFigure = QtGui.QWidget(self.centralwidget) > self.MplFigure.setObjectName(_fromUtf8("MplFigure")) > self.gridLayout.addWidget(self.MplFigure, 0, 0, 1, 1) > MainWindow.setCentralWidget(self.centralwidget) > > self.retranslateUi(MainWindow) > QtCore.QMetaObject.connectSlotsByName(MainWindow) > > def retranslateUi(self, MainWindow): > MainWindow.setWindowTitle(_translate("MainWindow", "MainWindow", > None)) > ------------------------------------------------- > > _______________________________________________ > 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 joe at neoturbine.net Thu Dec 11 14:14:30 2014 From: joe at neoturbine.net (Joseph Booker) Date: Thu, 11 Dec 2014 14:14:30 -0500 Subject: [SciPy-Dev] Cookbook update In-Reply-To: References: Message-ID: On Thu, Dec 11, 2014 at 1:56 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > > > On Thu, Dec 11, 2014 at 1:29 PM, Ryan Nelson > wrote: > >> Hello Scipy-devs: >> >> The link below on building a Qt app with a Matplotlib widget is very >> dated. >> http://wiki.scipy.org/Cookbook/Matplotlib/Qt_with_IPython_and_Designer >> >> After several research/trial/error cycles, I reproduced the Qt4 plot >> window that you using the relevant pyplot commands. I suppose I could >> update the Cookbook page above, but I need editing rights. Is this still >> possible, or are we trying to point users to a new location? >> >> Ryan >> >> > > This is a timely question. In the last few weeks, I've run into a couple > things I'd like to update: > > * At http://wiki.scipy.org/Cookbook/LASReader, I want to add a link to > the latest version, which is now on github: > https://github.com/WarrenWeckesser/las > > * I've seen at least three occurrences (a couple on stackoverflow, and one > private email) of someone using the argument 'order=15' in a call to the > 'set_integrator' method of 'scipy.integrate.ode'. Presumably this is > because of the suggestion in the "NumPy for Matlab Users" page on the wiki ( > http://wiki.scipy.org/NumPy_for_Matlab_Users) to replace 'ode15s' with ' > scipy.integrate.ode(f).set_integrator('vode', method='bdf', order=15)'. > This is pointless, because the stiff solver in 'vode'--presumably the > solver of interest for someone using 'ode15s'--has a maximum order of 5, > and the non-stiff solver has maximum order of 12. (The maximum order of > 'ode15s' is also 5; the '15' in the name refers to the variable order > ranging from 1 to 5.) > > I can log in, but I can't edit either of those pages. > > Warren > > > P.S. Here's the relevant code, in case it matters. >> >> File = run.py >> ------------------------------------------------------------------------- >> from test import Ui_MainWindow >> >> from matplotlib.figure import Figure >> from matplotlib.backends.backend_qt4agg import ( >> FigureCanvasQTAgg as FigureCanvas, >> NavigationToolbar2QT as NavigationToolbar) >> >> from PyQt4 import QtGui >> >> class Main(QtGui.QMainWindow, Ui_MainWindow): >> def __init__(self, ): >> super(Main, self).__init__() >> self.setupUi(self) >> >> self.populatefigure() >> self.addtoolbar() >> self.plotdata() >> >> def populatefigure(self,): >> self.fig = Figure() >> self.canvas = FigureCanvas(self.fig) >> self.canvas.setParent(self.MplFigure) >> >> self.mplvbox = QtGui.QVBoxLayout() >> self.mplvbox.addWidget(self.canvas) >> self.MplFigure.setLayout(self.mplvbox) >> >> def addtoolbar(self,): >> self.toolbar = NavigationToolbar(self.canvas, self, >> coordinates=True) >> self.addToolBar(self.toolbar) >> >> def addtoolbar2(self,): >> self.toolbar = NavigationToolbar(self.canvas, self.MplFigure, >> coordinates=True) >> self.mplvbox.addWidget(self.toolbar) >> >> def plotdata(self,): >> self.axes = self.fig.add_subplot(111) >> self.axes.plot([1,3,2]) >> self.canvas.draw() >> >> if __name__ == "__main__": >> ''' >> Run IPython as follows: >> $ ipython --gui='qt' >> [In 1]: %run run.py >> If running this file directly from the command line, remove the >> comments >> below and do the following: >> $ python run.py >> ''' >> >> #import sys >> #app = QtGui.QApplication([]) >> main = Main() >> main.show() >> #sys.exit(app.exec_()) >> ------------------------------------------------- >> >> File = test.py (created with Designer and pyuic4) >> ------------------------------------------------------------------- >> # -*- coding: utf-8 -*- >> >> # Form implementation generated from reading ui file 'test.ui' >> # >> # Created: Thu Dec 11 12:32:15 2014 >> # by: PyQt4 UI code generator 4.11.3 >> # >> # WARNING! All changes made in this file will be lost! >> >> from PyQt4 import QtCore, QtGui >> >> try: >> _fromUtf8 = QtCore.QString.fromUtf8 >> except AttributeError: >> def _fromUtf8(s): >> return s >> >> try: >> _encoding = QtGui.QApplication.UnicodeUTF8 >> def _translate(context, text, disambig): >> return QtGui.QApplication.translate(context, text, disambig, >> _encoding) >> except AttributeError: >> def _translate(context, text, disambig): >> return QtGui.QApplication.translate(context, text, disambig) >> >> class Ui_MainWindow(object): >> def setupUi(self, MainWindow): >> MainWindow.setObjectName(_fromUtf8("MainWindow")) >> MainWindow.resize(800, 600) >> self.centralwidget = QtGui.QWidget(MainWindow) >> self.centralwidget.setObjectName(_fromUtf8("centralwidget")) >> self.gridLayout = QtGui.QGridLayout(self.centralwidget) >> self.gridLayout.setObjectName(_fromUtf8("gridLayout")) >> self.MplFigure = QtGui.QWidget(self.centralwidget) >> self.MplFigure.setObjectName(_fromUtf8("MplFigure")) >> self.gridLayout.addWidget(self.MplFigure, 0, 0, 1, 1) >> MainWindow.setCentralWidget(self.centralwidget) >> >> self.retranslateUi(MainWindow) >> QtCore.QMetaObject.connectSlotsByName(MainWindow) >> >> def retranslateUi(self, MainWindow): >> MainWindow.setWindowTitle(_translate("MainWindow", "MainWindow", >> None)) >> ------------------------------------------------- >> >> > Along the same lines, I'd also like to mention that http://wiki.scipy.org/Cookbook/FortranIO/FortranFile and http://wiki.scipy.org/Cookbook/FortranIO give code that does the same as scipy.io.FortranFile (with a dtype-like API instead of the first page and more general use then the approach in the second page). -- Joseph Booker -------------- next part -------------- An HTML attachment was scrubbed... URL: From parke.loyd at gmail.com Fri Dec 12 20:12:00 2014 From: parke.loyd at gmail.com (Parke Loyd) Date: Fri, 12 Dec 2014 18:12:00 -0700 Subject: [SciPy-Dev] contribute wald-wolfowitz runs test to scipy.stats Message-ID: Hi, I wrote a bit of code that computes the test statistic and p-value for the wald-wolfowitz runs test. Seems like it would fit nicely alongside the other statistical tests in the stats module (ansari, bartlett, ...). The code is currently available here -- the function named runstest. The code works for my purposes, but I expect there is still much to be done before it will be ready for a pull request. Per the guide on contributing to SciPy, I figured I would get the conversation started to find out whether the community thought it a worthwhile contribution before making the effort to get it ready for a PR. Best, Parke -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Dec 13 07:05:17 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Dec 2014 13:05:17 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? Message-ID: Hi all, During the last week there were 3 PRs that failed because they used features not available in numpy 1.5.x or 1.6.x: https://github.com/scipy/scipy/pull/4238 (copy kw to astype method) https://github.com/scipy/scipy/pull/4256 (out kw to ufuncs) https://github.com/scipy/scipy/pull/4260 (use of np.random.choice) All those issues were/are fixable, but it looks like the balance of gain from keeping support for those numpy versions to development effort of supporting them is slowly shifting the wrong way. So questions: 1. Is anyone still relying on numpy 1.5.x or 1.6.x support for the next scipy releases? 2. Is it time to drop support for those versions, or if not then when? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From larsmans at gmail.com Sat Dec 13 07:34:55 2014 From: larsmans at gmail.com (Lars Buitinck) Date: Sat, 13 Dec 2014 13:34:55 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: 2014-12-13 13:05 GMT+01:00 Ralf Gommers : > 1. Is anyone still relying on numpy 1.5.x or 1.6.x support for the next > scipy releases? I don't, but I just checked the NumPy version that comes with various Linux distros so we can see what people are likely to have. There is no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. I take this to mean that almost nobody has NumPy 1.5, so there's no great benefit to supporting it. 1.6 might be more common. [1] http://packages.ubuntu.com/search?keywords=numpy&searchon=names&suite=all§ion=all [2] https://packages.debian.org/search?keywords=numpy&searchon=names&suite=all§ion=all [3] http://mirror.centos.org/centos/6/os/x86_64/Packages/ [4] http://mirror.centos.org/centos/7/os/x86_64/Packages/ From warren.weckesser at gmail.com Sat Dec 13 11:23:21 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sat, 13 Dec 2014 11:23:21 -0500 Subject: [SciPy-Dev] contribute wald-wolfowitz runs test to scipy.stats In-Reply-To: References: Message-ID: On 12/12/14, Parke Loyd wrote: > Hi, > > I wrote a bit of code that computes the test statistic and p-value for the > wald-wolfowitz runs test. Seems like it would fit nicely alongside the > other statistical tests in the stats module (ansari, bartlett, ...). The > code is currently available here > -- the function > named runstest. > > The code works for my purposes, but I expect there is still much to be done > before it will be ready for a pull request. Per the guide on contributing > to SciPy, I figured I would get the conversation started to find out > whether the community thought it a worthwhile contribution before making > the effort to get it ready for a PR. > Parke, The Wald-Wolfowitz test would be a nice addition to scipy. If you create a pull request, I hope Josef P. can help review it. I probably won't be able to do much more than a cursory review until January. Warren > Best, > Parke > From ralf.gommers at gmail.com Sat Dec 13 15:01:02 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Dec 2014 21:01:02 +0100 Subject: [SciPy-Dev] deprecating stats.pdf_fromgamma Message-ID: Hi all, Today I ran into stats.pdf_fromgamma again. That function, which does Gram-Chandler expansion to construct a distribution from 4 moments, is completely undocumented and untested. Statsmodels seems to be a better place to put this kind of functionality in, and it already contains the closely related Edgeworth expansion. See https://github.com/scipy/scipy/issues/699 for more details. Therefore the proposal is to deprecate pdf_fromgamma for 0.16.0. Any objections? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidmenhur at gmail.com Sat Dec 13 16:22:12 2014 From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=) Date: Sat, 13 Dec 2014 22:22:12 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On 13 December 2014 at 13:34, Lars Buitinck wrote: > I don't, but I just checked the NumPy version that comes with various > Linux distros so we can see what people are likely to have. There is > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. If you are using your OS's Numpy, you are likely to grab Scipy from there too. As far as I know, the only reason why someone would not upgrade Numpy is because they can't touch their systems, in which case the existence of a newer version of Scipy is equally irrelevant. Furthermore, compiling Numpy is easier than Scipy, so if you can update the later, you should be able to upgrade both. I think never versions of Scipy should just target maintained versions of Numpy, for some definition of "maintained". /David. From ralf.gommers at gmail.com Sun Dec 14 05:02:07 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 14 Dec 2014 11:02:07 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: > > On 13 December 2014 at 13:34, Lars Buitinck wrote: > > I don't, but I just checked the NumPy version that comes with various > > Linux distros so we can see what people are likely to have. There is > > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) > > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases > > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. > Thanks for checking. The most recent Ubuntu LTS and CentOS releases are good data points in general I'd say. In this case Ubuntu (and Debian stable) are on 1.6.x, so keep that but drop 1.5.x then? If you are using your OS's Numpy, you are likely to grab Scipy from there > too. > > As far as I know, the only reason why someone would not upgrade Numpy > is because they can't touch their systems, in which case the existence > of a newer version of Scipy is equally irrelevant. Furthermore, > compiling Numpy is easier than Scipy, so if you can update the later, > you should be able to upgrade both. > A lot more packages depend on numpy than on scipy, so upgrading numpy can have way more impact. And there may be institutes/companies that ship a fixed version of numpy that needs to be supported for a long time. > I think never versions of Scipy should just target maintained versions > of Numpy, for some definition of "maintained". > In principle only the last released numpy version gets new bugfix point releases, in exceptional cases maybe one version further back. So there's a good chance we'll get a numpy 1.9.2, little chance for a 1.8.3 and close to zero chance for a 1.7.3. I don't think that we can consider dropping numpy 1.7.x or 1.8.x support. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Dec 14 09:20:16 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 14 Dec 2014 15:20:16 +0100 Subject: [SciPy-Dev] Several packages failing on sparse/csgraph/_validation.py In-Reply-To: References: Message-ID: On Thu, Dec 11, 2014 at 6:09 PM, Deacon Sweeney wrote: > > Hello, > > I'm having an unusual bug on a fresh installation of scipy on SUSE, with > Python 2.7.8. There are several packages (stats, sparse, optimize, > interpolate, etc) that all fail to import due to > sparse/csgraph/_validation.py. Here is the error message from sparse: > > >>> import scipy.sparse > Traceback (most recent call last): > File "", line 1, in > File > "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/__init__.py", > line 206, in > from scipy.sparse.csgraph import _validation > File > "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/csgraph/__init__.py", > line 122, in > from scipy.sparse.csgraph import _validation > File > "/itmi/Python-2.7.8_a/lib/python2.7/site-packages/scipy/sparse/csgraph/_validation.py", > line 4, in > from scipy.sparse import csr_matrix, isspmatrix, isspmatrix_csc, > isspmatrix_csr > ImportError: cannot import name csr_matrix > > We have a bit of an unusual installation arrangement here, where I have to > use the "module load" command to switch Python versions. > > I can't find anything searching around, so I figured I'd reach out to the > experts here while digging in further myself. Any insights would be very > appreciated! > It fails on an absolute import from scipy.sparse reached from within scipy.sparse.__init__. Does it help to change line 4 of _validation.py to ``from .. import csr_matrix ``? I'm not sure what "module load" does exactly, is that something specific to your setup? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Dec 14 09:25:15 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 14 Dec 2014 15:25:15 +0100 Subject: [SciPy-Dev] Documentation page on API In-Reply-To: References: Message-ID: On Tue, Oct 28, 2014 at 2:48 AM, Yuxiang Wang wrote: > > (Sorry about sending this to the wrong list, scipy-user instead of > scipy-dev, before; apologize to those who saw this twice) > > Hi all, > > I was reading through the link > ( > http://docs.scipy.org/doc/scipy/reference/api.html#guidelines-for-importing-functions-from-scipy > ) > and it mentioned that the first form is > preferred over the second one under most circumstances: > > # first form > from scipy import stats > stats.lomax(...) > > # second form > from scipy.stats import distributions > distributions.lomax(...) > > I honestly think the second form is far more frequently used in the > examples given in the document, for example: > > http://docs.scipy.org/doc/scipy/reference/tutorial/special.html > http://docs.scipy.org/doc/scipy/reference/tutorial/integrate.html > http://docs.scipy.org/doc/scipy/reference/tutorial/optimize.html > http://docs.scipy.org/doc/scipy/reference/tutorial/interpolate.html > http://docs.scipy.org/doc/scipy/reference/tutorial/fftpack.html > > Would you think it'd be better to update this link? > Hi Shawn, sorry for the slow reply. I think what happened here is that we've settled on the first form after part of the documentation was written, and no one has bothered to go through every example in scipy (that would be quite a bit of work...) to make everything consistent. Personally I prefer the first form. Cheers, Ralf > > -Shawn > _______________________________________________ > 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 larsmans at gmail.com Sun Dec 14 09:29:19 2014 From: larsmans at gmail.com (Lars Buitinck) Date: Sun, 14 Dec 2014 15:29:19 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: 2014-12-14 11:02 GMT+01:00 Ralf Gommers : >> On 13 December 2014 at 13:34, Lars Buitinck wrote: >> > I don't, but I just checked the NumPy version that comes with various >> > Linux distros so we can see what people are likely to have. There is >> > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) >> > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases >> > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. > > > Thanks for checking. The most recent Ubuntu LTS and CentOS releases are good > data points in general I'd say. In this case Ubuntu (and Debian stable) are > on 1.6.x, so keep that but drop 1.5.x then? I'd say so. > On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: >> I think never versions of Scipy should just target maintained versions >> of Numpy, for some definition of "maintained". > > In principle only the last released numpy version gets new bugfix point > releases, in exceptional cases maybe one version further back. So there's a > good chance we'll get a numpy 1.9.2, little chance for a 1.8.3 and close to > zero chance for a 1.7.3. I don't think that we can consider dropping numpy > 1.7.x or 1.8.x support. NumPy releases are not always backwards compatible. Supporting an earlier version makes it easier for users to migrate their code. It's also easier for buildbots (Travis) if they can fetch a prepackaged NumPy. From warren.weckesser at gmail.com Sun Dec 14 12:30:17 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 14 Dec 2014 12:30:17 -0500 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On 12/14/14, Ralf Gommers wrote: > On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: >> >> On 13 December 2014 at 13:34, Lars Buitinck wrote: >> > I don't, but I just checked the NumPy version that comes with various >> > Linux distros so we can see what people are likely to have. There is >> > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) >> > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases >> > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. >> > > Thanks for checking. The most recent Ubuntu LTS and CentOS releases are > good data points in general I'd say. In this case Ubuntu (and Debian > stable) are on 1.6.x, so keep that but drop 1.5.x then? +1 for dropping 1.5.x. (I'm neutral on 1.6 support.) Warren > > If you are using your OS's Numpy, you are likely to grab Scipy from there >> too. >> >> As far as I know, the only reason why someone would not upgrade Numpy >> is because they can't touch their systems, in which case the existence >> of a newer version of Scipy is equally irrelevant. Furthermore, >> compiling Numpy is easier than Scipy, so if you can update the later, >> you should be able to upgrade both. >> > > A lot more packages depend on numpy than on scipy, so upgrading numpy can > have way more impact. And there may be institutes/companies that ship a > fixed version of numpy that needs to be supported for a long time. > > >> I think never versions of Scipy should just target maintained versions >> of Numpy, for some definition of "maintained". >> > > In principle only the last released numpy version gets new bugfix point > releases, in exceptional cases maybe one version further back. So there's a > good chance we'll get a numpy 1.9.2, little chance for a 1.8.3 and close to > zero chance for a 1.7.3. I don't think that we can consider dropping numpy > 1.7.x or 1.8.x support. > > Ralf > From jaime.frio at gmail.com Sun Dec 14 12:47:41 2014 From: jaime.frio at gmail.com (=?UTF-8?Q?Jaime_Fern=C3=A1ndez_del_R=C3=ADo?=) Date: Sun, 14 Dec 2014 09:47:41 -0800 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On Sun, Dec 14, 2014 at 2:02 AM, Ralf Gommers wrote: > > > > On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: >> >> On 13 December 2014 at 13:34, Lars Buitinck wrote: >> > I don't, but I just checked the NumPy version that comes with various >> > Linux distros so we can see what people are likely to have. There is >> > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) >> > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases >> > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. >> > > Thanks for checking. The most recent Ubuntu LTS and CentOS releases are > good data points in general I'd say. In this case Ubuntu (and Debian > stable) are on 1.6.x, so keep that but drop 1.5.x then? > +1 on dropping 1.5.x. I would actually skip over 1.6 and go all the way to 1.7 and its multi-axis reduction operations. But having einsum and out kwargs is already a much welcome change. Jaime -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sun Dec 14 17:29:33 2014 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 15 Dec 2014 00:29:33 +0200 Subject: [SciPy-Dev] ANN: Scipy 0.14.1 release candidate 1 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have finished preparing the Scipy 0.14.1 release candidate 1. If no regressions turn up, the final release is planned within the following weeks. The 0.14.1 release will be a bugfix-only release, addressing the following issues: - - gh-3630 NetCDF reading results in a segfault - - gh-3631 SuperLU object not working as expected for complex matrices - - gh-3733 Segfault from map_coordinates - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 - - gh-3781 Fix omitted types in sparsetools typemaps - - gh-3802 0.14.0 API breakage: _gen generators are missing from scipy.stats.distributions API - - gh-3805 ndimge test failures with numpy 1.10 - - gh-3812 == sometimes wrong on csr_matrix - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility - - gh-4093 Avoid a memory error in splev(x, tck, der=k) - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) - - gh-4143 Fix ndimage functions for large data - - gh-4149 Bug in expm for integer arrays - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is a tuple - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper - - gh-4180 pil resize support tuple fix - - gh-4168 Address arpack test failures on windows 32 bits with numpy 1.9.1 - - gh-4218 make ndimage interpolation compatible with numpy relaxed strides - - gh-4225 off-by-one error in PPoly shape checks - - gh-4248 fix issue with incorrect use of closure for slsqp Source tarballs and binaries are available at https://sourceforge.net/projects/scipy/files/scipy/0.14.1rc1/ Best regards, Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSOD0YACgkQ6BQxb7O0pWDO5ACfccLqMvZWfkHqSzDCkMSoRKAU n7cAni6XhWJRy7oJ757rlGeIi0e34HTn =9bB/ -----END PGP SIGNATURE----- From warren.weckesser at gmail.com Sun Dec 14 22:12:49 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 14 Dec 2014 22:12:49 -0500 Subject: [SciPy-Dev] contribute wald-wolfowitz runs test to scipy.stats In-Reply-To: References: Message-ID: On 12/13/14, Warren Weckesser wrote: > On 12/12/14, Parke Loyd wrote: >> Hi, >> >> I wrote a bit of code that computes the test statistic and p-value for >> the >> wald-wolfowitz runs test. Seems like it would fit nicely alongside the >> other statistical tests in the stats module (ansari, bartlett, ...). The >> code is currently available here >> -- the >> function >> named runstest. >> >> The code works for my purposes, but I expect there is still much to be >> done >> before it will be ready for a pull request. Per the guide on contributing >> to SciPy, I figured I would get the conversation started to find out >> whether the community thought it a worthwhile contribution before making >> the effort to get it ready for a PR. >> > > > Parke, > > The Wald-Wolfowitz test would be a nice addition to scipy. If you > create a pull request, I hope Josef P. can help review it. I probably > won't be able to do much more than a cursory review until January. > It doesn't mean we can't have it in scipy, but I see that statsmodels has the Wald-Wolfowitz runs test in their sandbox: https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/stats/runs.py Josef would probably know the status of the statsmodels version of the test. Warren > Warren > > >> Best, >> Parke >> > From warren.weckesser at gmail.com Sun Dec 14 22:44:32 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 14 Dec 2014 22:44:32 -0500 Subject: [SciPy-Dev] deprecating stats.pdf_fromgamma In-Reply-To: References: Message-ID: On 12/13/14, Ralf Gommers wrote: > Hi all, > > Today I ran into stats.pdf_fromgamma again. That function, which does > Gram-Chandler expansion to construct a distribution from 4 moments, is > completely undocumented and untested. Statsmodels seems to be a better > place to put this kind of functionality in, and it already contains the > closely related Edgeworth expansion. See > https://github.com/scipy/scipy/issues/699 for more details. > > Therefore the proposal is to deprecate pdf_fromgamma for 0.16.0. Any > objections? > No objection. Deprecate away... Warren > Ralf > From irvin.probst at ensta-bretagne.fr Mon Dec 15 05:53:32 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Mon, 15 Dec 2014 11:53:32 +0100 Subject: [SciPy-Dev] Asking for a code review: pole placement In-Reply-To: References: Message-ID: <548EBDAC.9000107@ensta-bretagne.fr> Hi all, I've finished to integrate and test my pole placement code, here is the url of the diff. I'd like to know what you think before issuing a pull request. https://github.com/I--P/scipy/compare/pole-placement As said a few days ago there are two algorithms, KNV method 0 (KNV0) and Yang Tits (YT). See code for urls to the reference papers. Motivations for doing this in pure Python rather than linking some old fortran code: I was in need of a 100% Python dependency free (except Numpy of course) pole placement function, integrating it into scipy was not my primary goal. Fortran code used for decades will for sure be faster and bug free but it was not an option. Regarding KNV0: - Licensing issues: I chose this method before knowing Matlab used it too. I did read some old matlab source code (circa 2001 release iirc) at the beginning of my work I won't lie on that, after Ralf Gommers warned me it was not possible to port Matlab code I used my knowledge of their code to stay as far as possible from what they did (the algorithm gives some degrees of freedom). Given the current status of my code I can't see any reason why it would be seen as a rip-off of their code unless I'm banned from coding a projection into a vector space because I read some Matlab code doing it. See lines 1171, 1172 and 1173 in ltisys.py which are the core of this algorithm and are not in any way an idea coming from Mathworks folks, these formulas are clearly written in the reference publication page 1145 and 1146. - Complex poles are not supported by the original algorithm. Using the ideas from the second algorithm below I managed to reach a success rate of 90% with complex poles but this is not reliable enough so the relevant code is disabled. Matlab has a 100% success rate in their 2013 implementation but I don't know how they achieved that (I _*did not*_ check their 2013 code). Regarding Yang Tits algorithm: - This is an update of the KNV0 algorithm published in the mid 90's, as far as I know it is only distributed by Slicot as "contributed MATLAB functions" http://slicot.org/contributed-software under a non-free license. - This implementation is 100% genuine, I did not read the code distributed by slicot past the license header until my code was working so there are no licensing issues imho. After achieving a working implementation of this algorithm I checked the reference implementation from Slicot and I'm still puzzled by how they did it. I'm sure there are tons of good reasons why their implementation is faster/better than mine but I simply can't understand what they did. - Real poles are supported, sometimes the solution has a better conditionning than KNV0's, sometimes not, but it does converge must faster all the time. I was considering adding an option to return the solution with the best conditionning from the two methods but it might confuse users as it would only work on real poles. What do you think ? - Complex poles are supported, I ran it for hours with random matrices and poles and it never failed. Please let me know if this code match you quality standards and I would really be glad if someone could test it and report any bug. The reference matlab implementations of these algorithms have been used and polished for decades, I'm sure I've missed lots of specific cases. As a sidenote, if PR #4249 is accepted it should be possible to greatly improve the speed of these two algorithms. From andyfaff at gmail.com Mon Dec 15 07:20:47 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Mon, 15 Dec 2014 23:20:47 +1100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: It occurs to me that there could be many places in the scipy codebase where modernisations could be made, but for the need of backward compatibility with older versions of dependent libraries, i.e. numpy. Is there any file where those locations are recorded, so that upgrades can be facilitated when support for older dependent libraries is dropped? -- _____________________________________ Dr. Andrew Nelson _____________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Dec 15 14:47:53 2014 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 15 Dec 2014 21:47:53 +0200 Subject: [SciPy-Dev] ANN: Scipy 0.15.0 release candidate 1 Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, Scipy 0.15.0 release candidate 1 is now available. If no surprises turn up, the final release is planned within two weeks. Source tarballs, full release notes etc. are available at https://sourceforge.net/projects/scipy/files/scipy/0.15.0rc1/ Best regards, Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSPOukACgkQ6BQxb7O0pWB93QCeKdH90WDdAPELEyJjnboeG1Qj vtYAoLLGi6OzCErtI5DDLVwA/S5xre2R =ReL8 -----END PGP SIGNATURE----- From rlucente at pipeline.com Mon Dec 15 20:21:40 2014 From: rlucente at pipeline.com (Robert Lucente - Pipeline) Date: Mon, 15 Dec 2014 20:21:40 -0500 Subject: [SciPy-Dev] Asking for a code review: pole placement Message-ID: <044101d018ce$a55ab820$f0102860$@pipeline.com> Date: Mon, 15 Dec 2014 11:53:32 +0100 From: Irvin Probst Subject: [SciPy-Dev] Asking for a code review: pole placement Message-ID: <548EBDAC.9000107 at ensta-bretagne.fr> >Licensing issues Perhaps eff.org might be able to help w/ some of the licensing stuff? From josef.pktd at gmail.com Tue Dec 16 10:19:09 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 16 Dec 2014 10:19:09 -0500 Subject: [SciPy-Dev] contribute wald-wolfowitz runs test to scipy.stats In-Reply-To: References: Message-ID: On Sun, Dec 14, 2014 at 10:12 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > On 12/13/14, Warren Weckesser wrote: > > On 12/12/14, Parke Loyd wrote: > >> Hi, > >> > >> I wrote a bit of code that computes the test statistic and p-value for > >> the > >> wald-wolfowitz runs test. Seems like it would fit nicely alongside the > >> other statistical tests in the stats module (ansari, bartlett, ...). The > >> code is currently available here > >> -- the > >> function > >> named runstest. > >> > >> The code works for my purposes, but I expect there is still much to be > >> done > >> before it will be ready for a pull request. Per the guide on > contributing > >> to SciPy, I figured I would get the conversation started to find out > >> whether the community thought it a worthwhile contribution before making > >> the effort to get it ready for a PR. > >> > > > > > > Parke, > > > > The Wald-Wolfowitz test would be a nice addition to scipy. If you > > create a pull request, I hope Josef P. can help review it. I probably > > won't be able to do much more than a cursory review until January. > > > > > It doesn't mean we can't have it in scipy, but I see that statsmodels > has the Wald-Wolfowitz runs test in their sandbox: > > https://github.com/statsmodels/statsmodels/blob/master/statsmodels/sandbox/stats/runs.py only the modules are located in the sandbox (*). The functions are "official" (included in the api.py) and reasonably tested AFAICS http://statsmodels.sourceforge.net/devel/stats.html#non-parametric-tests I haven't looked at those in a long time. According to the docstring, SAS has a "more exact" tie handling. I tried for a while to figure out the exact distributions of various runs processes and statistics but then gave up because it was taking too much time given my priorities. (*) some modules where my ambition was greater than my patience are still located in the sandbox even though the main functions are tested and "official". Josef > > > Josef would probably know the status of the statsmodels version of the > test. > > Warren > > > > Warren > > > > > >> Best, > >> Parke > >> > > > _______________________________________________ > 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 Wed Dec 17 15:21:18 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Dec 2014 21:21:18 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On Mon, Dec 15, 2014 at 1:20 PM, Andrew Nelson wrote: > > > _____________________________________ > It occurs to me that there could be many places in the scipy codebase > where modernisations could be made, but for the need of backward > compatibility with older versions of dependent libraries, i.e. numpy. > Modernisations can definitely be made in many places, but I think only a small fraction of those is coupled to improvements in the latest numpy releases. > Is there any file where those locations are recorded, so that upgrades can > be facilitated when support for older dependent libraries is dropped? > Searching for NumpyVersion will reveal things that do depend on numpy version. Lars already has a PR in to clean up code that's still there to support numpy 1.5.x: https://github.com/scipy/scipy/pull/4265. For other things that need major surgery, see the still to be merged Scipy 1.0 roadmap: https://github.com/scipy/scipy/pull/2908 Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Dec 17 15:26:06 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Dec 2014 21:26:06 +0100 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On Sun, Dec 14, 2014 at 6:47 PM, Jaime Fern?ndez del R?o < jaime.frio at gmail.com> wrote: > > > On Sun, Dec 14, 2014 at 2:02 AM, Ralf Gommers > wrote: >> >> >> >> On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: >>> >>> On 13 December 2014 at 13:34, Lars Buitinck wrote: >>> > I don't, but I just checked the NumPy version that comes with various >>> > Linux distros so we can see what people are likely to have. There is >>> > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) >>> > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases >>> > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. >>> >> >> Thanks for checking. The most recent Ubuntu LTS and CentOS releases are >> good data points in general I'd say. In this case Ubuntu (and Debian >> stable) are on 1.6.x, so keep that but drop 1.5.x then? >> > > +1 on dropping 1.5.x. > > I would actually skip over 1.6 and go all the way to 1.7 and its > multi-axis reduction operations. But having einsum and out kwargs is > already a much welcome change. > Summary of this thread so far: everyone in favor of dropping 1.5.x support, on keeping 1.6.x support the opinions are a bit more mixed. So I propose that we go ahead and drop 1.5.x (let's consider it final if no one objects in the next day or two) and reconsider dropping 1.6.x in the next release cycle. I'd actually suggest only supporting 1.6.2 - no use trying to work around bugs in 1.6.0/1.6.1 that have been fixed. We did the same with 1.5.x. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at gmail.com Wed Dec 17 15:33:54 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Wed, 17 Dec 2014 15:33:54 -0500 Subject: [SciPy-Dev] when to drop numpy 1.5.x/1.6.x support? In-Reply-To: References: Message-ID: On Wed, Dec 17, 2014 at 3:26 PM, Ralf Gommers wrote: > > > > On Sun, Dec 14, 2014 at 6:47 PM, Jaime Fern?ndez del R?o < > jaime.frio at gmail.com> wrote: >> >> >> On Sun, Dec 14, 2014 at 2:02 AM, Ralf Gommers >> wrote: >>> >>> >>> >>> On Sat, Dec 13, 2014 at 10:22 PM, Da?id wrote: >>>> >>>> On 13 December 2014 at 13:34, Lars Buitinck wrote: >>>> > I don't, but I just checked the NumPy version that comes with various >>>> > Linux distros so we can see what people are likely to have. There is >>>> > no Ubuntu long-term support release that ships 1.5, only 1.4 (10.04) >>>> > or 1.6 (12.04) [1]. Debian doesn't list 1.5 for any of its releases >>>> > either [2]. CentOS 6 ships 1.4 [3], while CentOS 7 ships 1.7.1 [4]. >>>> >>> >>> Thanks for checking. The most recent Ubuntu LTS and CentOS releases are >>> good data points in general I'd say. In this case Ubuntu (and Debian >>> stable) are on 1.6.x, so keep that but drop 1.5.x then? >>> >> >> +1 on dropping 1.5.x. >> >> I would actually skip over 1.6 and go all the way to 1.7 and its >> multi-axis reduction operations. But having einsum and out kwargs is >> already a much welcome change. >> > > Summary of this thread so far: everyone in favor of dropping 1.5.x > support, on keeping 1.6.x support the opinions are a bit more mixed. So I > propose that we go ahead and drop 1.5.x (let's consider it final if no one > objects in the next day or two) and reconsider dropping 1.6.x in the next > release cycle. > > I'd actually suggest only supporting 1.6.2 - no use trying to work around > bugs in 1.6.0/1.6.1 that have been fixed. We did the same with 1.5.x. > > +1 Warren > 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 ralf.gommers at gmail.com Wed Dec 17 16:13:12 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Dec 2014 22:13:12 +0100 Subject: [SciPy-Dev] deprecating stats.pdf_fromgamma In-Reply-To: References: Message-ID: On Mon, Dec 15, 2014 at 4:44 AM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > > On 12/13/14, Ralf Gommers wrote: > > Hi all, > > > > Today I ran into stats.pdf_fromgamma again. That function, which does > > Gram-Chandler expansion to construct a distribution from 4 moments, is > > completely undocumented and untested. Statsmodels seems to be a better > > place to put this kind of functionality in, and it already contains the > > closely related Edgeworth expansion. See > > https://github.com/scipy/scipy/issues/699 for more details. > > > > Therefore the proposal is to deprecate pdf_fromgamma for 0.16.0. Any > > objections? > > > > > No objection. Deprecate away... > Done: https://github.com/scipy/scipy/pull/4287 Ralf > > Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Dec 17 16:32:45 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 17 Dec 2014 16:32:45 -0500 Subject: [SciPy-Dev] ANN: Scipy 0.15.0 release candidate 1 In-Reply-To: References: Message-ID: Hi, On Mon, Dec 15, 2014 at 2:47 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > Scipy 0.15.0 release candidate 1 is now available. If no surprises > turn up, the final release is planned within two weeks. > > Source tarballs, full release notes etc. are available at > https://sourceforge.net/projects/scipy/files/scipy/0.15.0rc1/ OSX wheels at http://wheels.scipy.org/ (via https://travis-ci.org/MacPython/scipy-wheels). Scipy-stack tests running at https://travis-ci.org/MacPython/scipy-stack-osx-testing Cheers, Matthew From irvin.probst at ensta-bretagne.fr Fri Dec 19 04:08:33 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Fri, 19 Dec 2014 10:08:33 +0100 Subject: [SciPy-Dev] Asking for a code review: pole placement In-Reply-To: <044101d018ce$a55ab820$f0102860$@pipeline.com> References: <044101d018ce$a55ab820$f0102860$@pipeline.com> Message-ID: <5493EB11.8030405@ensta-bretagne.fr> On 16/12/2014 02:21, Robert Lucente - Pipeline wrote: > Perhaps eff.org might be able to help w/ some of the licensing stuff? Hi, as nobody raised any concerns about my code I've issued a PR: https://github.com/scipy/scipy/pull/4295 Have a nice day. From cournape at gmail.com Fri Dec 19 08:48:44 2014 From: cournape at gmail.com (David Cournapeau) Date: Fri, 19 Dec 2014 13:48:44 +0000 Subject: [SciPy-Dev] ANN: Scipy 0.14.1 release candidate 1 In-Reply-To: References: Message-ID: I built that rc on top of numpy 1.8.1 and MKL, and it worked on every platform we support @ Enthought. I saw a few test failures on linux and windows 64 bits, but those were there before or are precisions issues. I also tested when run on top of numpy 1.9.1 (but still built against 1.8.1), w/ similar results. Thanks for all the hard work, David On Sun, Dec 14, 2014 at 10:29 PM, Pauli Virtanen wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finished preparing the Scipy 0.14.1 release candidate 1. > If no regressions turn up, the final release is planned within the > following weeks. > > The 0.14.1 release will be a bugfix-only release, addressing the > following issues: > > - - gh-3630 NetCDF reading results in a segfault > - - gh-3631 SuperLU object not working as expected for complex matrices > - - gh-3733 Segfault from map_coordinates > - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 > - - gh-3781 Fix omitted types in sparsetools typemaps > - - gh-3802 0.14.0 API breakage: _gen generators are missing from > scipy.stats.distributions API > - - gh-3805 ndimge test failures with numpy 1.10 > - - gh-3812 == sometimes wrong on csr_matrix > - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 > - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility > - - gh-4093 Avoid a memory error in splev(x, tck, der=k) > - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) > - - gh-4143 Fix ndimage functions for large data > - - gh-4149 Bug in expm for integer arrays > - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is > a tuple > - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr > - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper > - - gh-4180 pil resize support tuple fix > - - gh-4168 Address arpack test failures on windows 32 bits with numpy > 1.9.1 > - - gh-4218 make ndimage interpolation compatible with numpy relaxed > strides > - - gh-4225 off-by-one error in PPoly shape checks > - - gh-4248 fix issue with incorrect use of closure for slsqp > > Source tarballs and binaries are available at > https://sourceforge.net/projects/scipy/files/scipy/0.14.1rc1/ > > Best regards, > Pauli Virtanen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlSOD0YACgkQ6BQxb7O0pWDO5ACfccLqMvZWfkHqSzDCkMSoRKAU > n7cAni6XhWJRy7oJ757rlGeIi0e34HTn > =9bB/ > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 valentine.c at husky.neu.edu Mon Dec 22 19:47:04 2014 From: valentine.c at husky.neu.edu (Clint Valentine) Date: Mon, 22 Dec 2014 19:47:04 -0500 Subject: [SciPy-Dev] (no subject) Message-ID: I ported an algorithm originally written in MatLab to Python for generating a random contingency table (when one exists) for a statistical test I am writing. I know something like this doesn't exist in scipy.stats.contingency and was wondering if it would be a good addition? I haven't developed any tests for the function yet but can if needed. I have just started developing in Python as an undergraduate student studying computational biology. This would be my first time contributing to open source and I am looking forward to the the experience and all the advice you are willing to offer. Thanks for your time. -Clint def rcont(ncol, nrow, ncolt, nrowt): """ Return a random contingency table based on the two-dimensional shape and marginal totals of a given contingency table There must be 1 or many tables with nonnegative, integral entries that have the given shape and marginal sums as input. The function will generate, at random, one of the tables and return it. Repeated calls to the function will return new random selections. Parameters: ----------- ncol : integer The vector length of the columns in the contingency table nrow : integer The vector length of the rows in the contingency table ncolt : array_like The vector of the marginal column totals in the contingency table nrowt : array_like The vector of the marginal row totals in the contingency table Returns ------- imatrix : ndarray of integers The randomly generated two-dimensional ndarray preserving the same shape and marginal totals provided if exists Reference --------- Algorithm AS144: Appl. Statist. (1979) v.28, pp.329-332 Licensing: GNU LGPL license Author: Original FORTRAN77 version by James Boyett. MATLAB version by John Burkardt. Python version by Clint Valentine Reference: James Boyett, Algorithm AS 144: Random R x C Tables with Given Row and Column Totals, Applied Statistics, Volume 28, Number 3, pages 329-332, 1979. """ # Initialize and permute vector nvect = np.array(xrange(sum(ncolt)), dtype=np.int_) np.random.shuffle(nvect) # Construct random matrix and partial column sums imatrix = np.zeros([nrow, ncol], dtype=np.int_) nsubt = np.cumsum(ncolt) # Generate random RxC contingency tables preserving shape and # marginal column and row sums and total sum. count = 0 for i in xrange(nrow): limit = nrowt[i] for _ in xrange(limit): for j in xrange(ncol): if nvect[count] <= nsubt[j]: count += 1 imatrix[i][j] += 1 break return imatrix -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Mon Dec 22 21:26:03 2014 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Dec 2014 21:26:03 -0500 Subject: [SciPy-Dev] (no subject) In-Reply-To: References: Message-ID: On Mon, Dec 22, 2014 at 7:47 PM, Clint Valentine wrote: > I ported an algorithm originally written in MatLab to Python for > generating a random contingency table (when one exists) for a statistical > test I am writing. I know something like this doesn't exist in > scipy.stats.contingency and was wondering if it would be a good addition? I > haven't developed any tests for the function yet but can if needed. > > I have just started developing in Python as an undergraduate student > studying computational biology. This would be my first time contributing to > open source and I am looking forward to the the experience and all the > advice you are willing to offer. Thanks for your time. > Hi Clint, More tools for the analysis of contigency tables, or other missing pieces in stats, will be useful and will find a home in either scipy.stats or statsmodels. Specifically to this: I never looked at random generation of contingency tables, but I think it would be useful for bootstrap or Monte Carlo based hypothesis tests, which are currently not yet available in scipy.stats but some are in other pacakges. However, scipy, and statsmodels and most other packages in this neighborhood, are BSD licensed and GPL is not compatible with it. So, we need to either translate code that is license compatible (like most of the code on the matlab fileexchange), or write the code based on the description of the algorithm without copying/translating code that has an incompatible license.. Josef > > -Clint > > def rcont(ncol, nrow, ncolt, nrowt): > """ > Return a random contingency table based on the two-dimensional shape > and marginal totals of a given contingency table > > There must be 1 or many tables with nonnegative, integral entries > that have the given shape and marginal sums as input. The function > will generate, at random, one of the tables and return it. Repeated > calls to the function will return new random selections. > > Parameters: > ----------- > ncol : integer > The vector length of the columns in the contingency table > > nrow : integer > The vector length of the rows in the contingency table > > ncolt : array_like > The vector of the marginal column totals in the contingency table > > nrowt : array_like > The vector of the marginal row totals in the contingency table > > Returns > ------- > imatrix : ndarray of integers > The randomly generated two-dimensional ndarray preserving the > same shape and marginal totals provided if exists > > Reference > --------- > Algorithm AS144: Appl. Statist. (1979) v.28, pp.329-332 > > Licensing: > GNU LGPL license > > Author: > Original FORTRAN77 version by James Boyett. > MATLAB version by John Burkardt. > Python version by Clint Valentine > > Reference: > James Boyett, > Algorithm AS 144: > Random R x C Tables with Given Row and Column Totals, > Applied Statistics, > Volume 28, Number 3, pages 329-332, 1979. > """ > # Initialize and permute vector > nvect = np.array(xrange(sum(ncolt)), dtype=np.int_) > np.random.shuffle(nvect) > > # Construct random matrix and partial column sums > imatrix = np.zeros([nrow, ncol], dtype=np.int_) > nsubt = np.cumsum(ncolt) > > # Generate random RxC contingency tables preserving shape and > # marginal column and row sums and total sum. > count = 0 > for i in xrange(nrow): > limit = nrowt[i] > for _ in xrange(limit): > for j in xrange(ncol): > if nvect[count] <= nsubt[j]: > count += 1 > imatrix[i][j] += 1 > break > return imatrix > > _______________________________________________ > 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 Tue Dec 23 06:33:30 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 23 Dec 2014 12:33:30 +0100 Subject: [SciPy-Dev] (no subject) In-Reply-To: References: Message-ID: As Joseph said, we cannot have LGPL code in SciPy, but we can use the original paper as source. The license must be SciPy's version of the BSD license, or at least compatible. Some comments on your code: The inner loop should be vectorized. If not possible (I have not looked at it carefully) you should consider to use Cython or Fortran (f2py). imatrix[i][j] is a common beginner's mistake. Use imatrix[i,j] (yes it matters) or preferably vectorize (cf. comment above). The function should take a RandomState as an optional argument. For Monte Carlo, it would be nice to have a repeats argument as well, to squash some of the Python overhead. If you add a repeats argument it is better to use Cython or Fortran because numpy.random.shuffle and numpy.random.permutation do not take an axis argument, hence you cannot vectorize the suffling. (This is a problem in NumPy we should fix.) All in all, I would say this points to Cython based solution. Sturla On 23/12/14 01:47, Clint Valentine wrote: > I ported an algorithm originally written in MatLab to Python for > generating a random contingency table (when one exists) for a > statistical test I am writing. I know something like this doesn't exist > in scipy.stats.contingency and was wondering if it would be a good > addition? I haven't developed any tests for the function yet but can if > needed. > > I have just started developing in Python as an undergraduate student > studying computational biology. This would be my first time contributing > to open source and I am looking forward to the the experience and all > the advice you are willing to offer. Thanks for your time. > > -Clint > > def rcont(ncol, nrow, ncolt, nrowt): > """ > Return a random contingency table based on the two-dimensional shape > and marginal totals of a given contingency table > > There must be 1 or many tables with nonnegative, integral entries > that have the given shape and marginal sums as input. The function > will generate, at random, one of the tables and return it. Repeated > calls to the function will return new random selections. > > Parameters: > ----------- > ncol : integer > The vector length of the columns in the contingency table > > nrow : integer > The vector length of the rows in the contingency table > > ncolt : array_like > The vector of the marginal column totals in the contingency table > > nrowt : array_like > The vector of the marginal row totals in the contingency table > > Returns > ------- > imatrix : ndarray of integers > The randomly generated two-dimensional ndarray preserving the > same shape and marginal totals provided if exists > > Reference > --------- > Algorithm AS144: Appl. Statist. (1979) v.28, pp.329-332 > > Licensing: > GNU LGPL license > > Author: > Original FORTRAN77 version by James Boyett. > MATLAB version by John Burkardt. > Python version by Clint Valentine > > Reference: > James Boyett, > Algorithm AS 144: > Random R x C Tables with Given Row and Column Totals, > Applied Statistics, > Volume 28, Number 3, pages 329-332, 1979. > """ > # Initialize and permute vector > nvect = np.array(xrange(sum(ncolt)), dtype=np.int_) > np.random.shuffle(nvect) > > # Construct random matrix and partial column sums > imatrix = np.zeros([nrow, ncol], dtype=np.int_) > nsubt = np.cumsum(ncolt) > > # Generate random RxC contingency tables preserving shape and > # marginal column and row sums and total sum. > count = 0 > for i in xrange(nrow): > limit = nrowt[i] > for _ in xrange(limit): > for j in xrange(ncol): > if nvect[count] <= nsubt[j]: > count += 1 > imatrix[i][j] += 1 > break > return imatrix > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From alex.e.susu at gmail.com Tue Dec 23 12:11:05 2014 From: alex.e.susu at gmail.com (Alex Susu) Date: Tue, 23 Dec 2014 19:11:05 +0200 Subject: [SciPy-Dev] Efficient operations on sparse matrices Message-ID: Hello. I am very interested in implementing efficient operations on sparse matrices from scipy, such as: interp2, imresize, imfilter, mean2, gradient - all these functions are actually the ones from Matlab, used in computer vision (you can google to see exactly what they do). It seems it's not very difficult - I used also some information from an earlier email on this list (see below). Did anybody else try something similar with the sparse matrices in scipy? Thank you, Alex > On Fri, Oct 10, 2014 at 12:00 PM, Saullo Castro gmail.com> wrote: > I developed a function (shown below) to check if a sparse matrix is > symmetric and would like to know if the community is interested to include > in scipy.sparse. > > Regards, > Saullo > > def is_symmetric(m): > """Check if a sparse matrix is symmetric > """ > if m.shape[0] != m.shape[1]: > raise ValueError('m must be a square matrix') > > if not isinstance(m, coo_matrix): > m = coo_matrix(m) > > r, c, v = m.row, m.col, m.data > tril_no_diag = r > c > triu_no_diag = c > r > > if triu_no_diag.sum() != tril_no_diag.sum(): > return False > > rl = r[tril_no_diag] > cl = c[tril_no_diag] > vl = v[tril_no_diag] > ru = r[triu_no_diag] > cu = c[triu_no_diag] > vu = v[triu_no_diag] > > sortl = np.lexsort((cl, rl)) > sortu = np.lexsort((ru, cu)) > vl = vl[sortl] > vu = vu[sortu] > > check = np.allclose(vl, vu) > > return check -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Tue Dec 23 13:32:18 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 23 Dec 2014 19:32:18 +0100 Subject: [SciPy-Dev] Efficient operations on sparse matrices In-Reply-To: References: Message-ID: On 23/12/14 18:11, Alex Susu wrote: > I am very interested in implementing efficient operations on sparse > matrices from scipy, such as: interp2, imresize, imfilter, mean2, > gradient - all these functions are actually the ones from Matlab, used > in computer vision (you can google to see exactly what they do). They are not from Matlab. But you will find cases where functions in Matlab and NumPy/SciPy have the same name, for obvious reasons. Sturla From arstone208 at gmail.com Tue Dec 23 14:03:16 2014 From: arstone208 at gmail.com (Adam Stone) Date: Tue, 23 Dec 2014 20:03:16 +0100 Subject: [SciPy-Dev] Wallenius' noncentral hypergeometric distribution Message-ID: Hello, I recently wrote some python code that involved calculating Wallenius' noncentral hypergeometric distribution ( http://en.wikipedia.org/wiki/Wallenius%27_noncentral_hypergeometric_distribution ). This is similar to the scipy.stats.hypergeom distribution, which is applied to situations like drawing marbles from an urn without replacement, but the noncentral version introduces unequally-weighted probabilities for drawing the different types of marbles. What I have is a multivariate implementation of this (i.e. drawing from 3+ types of marbles). I thought that it might be a good addition to the scipy.stats module. My initial implementation is here: https://github.com/AdamStone/hypergeometric Obviously the above isn't yet in a form consistent with the other scipy.stats distributions, but I wanted to check with the mailing list before committing the time to restructure it. If the list approves, I will go ahead with implementing it in the manner of the other scipy.stats distributions. Thanks, Adam Stone -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Tue Dec 23 21:32:30 2014 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Tue, 23 Dec 2014 18:32:30 -0800 Subject: [SciPy-Dev] Fast sizes for FFT Message-ID: Hey, The performance of fftpack depends very strongly on the array size -- sizes that are powers of two are good, but also powers of three, five and seven, or numbers whose only prime factors are from (2,3,5,7). For problems that can use padding, rounding up the size (using np.fft.fft(x, n=size_with_padding)) to one of these multiples makes a big difference. Some other packages expose a function for calculating the next fast size, e.g: http://ltfat.sourceforge.net/notes/ltfatnote017.pdf. Is there anything like this in numpy/scipy? If not, would this be a reasonable feature to add? -Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From kitchi.srikrishna at gmail.com Wed Dec 24 08:25:51 2014 From: kitchi.srikrishna at gmail.com (Sri Krishna) Date: Wed, 24 Dec 2014 18:55:51 +0530 Subject: [SciPy-Dev] Fast sizes for FFT In-Reply-To: References: Message-ID: Is there anything like this in numpy/scipy? If not, would this be a > reasonable feature to add? > > -Robert > > AFAIK the SciPy scipy.fftpack.fft function automatically does this. The function that calculates the next closest "composite number" isn't exposed, but any size you input to fftpack will automatically be resized to the next largest composite numbers for fast FFTs. Thanks, Krishna -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Wed Dec 24 08:51:52 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 24 Dec 2014 14:51:52 +0100 Subject: [SciPy-Dev] Fast sizes for FFT In-Reply-To: References: Message-ID: On 24/12/14 14:25, Sri Krishna wrote: > AFAIK the SciPy scipy.fftpack.fft function automatically does this. The > function that calculates the next closest "composite number" isn't > exposed, but any size you input to fftpack will automatically be resized > to the next largest composite numbers for fast FFTs. No, it factorizes the FFT into efficient chunks (size 2, 3, 4, or 5), and if the FFT size factorizes into larger primes it uses an O(N**2) DFT for those chunks. It allows us to compute FFTs of any size, but it will not always be efficient. E.g. compare an FFT of size 4099 (prime) and compare with an FFT of size 4096 (2**12). In[10]: a = np.zeros(4099*100) In[11]: %timeit scipy.fftpack.fft(a) 1 loops, best of 3: 615 ms per loop In[12]: a = np.zeros(4096*100) In[13]: %timeit scipy.fftpack.fft(a) 100 loops, best of 3: 8.64 ms per loop Sturla From ralf.gommers at gmail.com Sun Dec 28 09:52:43 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 28 Dec 2014 15:52:43 +0100 Subject: [SciPy-Dev] Wallenius' noncentral hypergeometric distribution In-Reply-To: References: Message-ID: Hi Adam, On Tue, Dec 23, 2014 at 8:03 PM, Adam Stone wrote: > Hello, > > I recently wrote some python code that involved calculating Wallenius' > noncentral hypergeometric distribution ( > http://en.wikipedia.org/wiki/Wallenius%27_noncentral_hypergeometric_distribution > ). > > This is similar to the scipy.stats.hypergeom distribution, which is > applied to situations like drawing marbles from an urn without replacement, > but the noncentral version introduces unequally-weighted probabilities for > drawing the different types of marbles. What I have is a multivariate > implementation of this (i.e. drawing from 3+ types of marbles). I thought > that it might be a good addition to the scipy.stats module. > > My initial implementation is here: > https://github.com/AdamStone/hypergeometric > > Obviously the above isn't yet in a form consistent with the other > scipy.stats distributions, but I wanted to check with the mailing list > before committing the time to restructure it. If the list approves, I will > go ahead with implementing it in the manner of the other scipy.stats > distributions. > This looks to me like a useful distribution to add. I see that there are GPL implementations in R and C++ available - keep in mind that you cannot look at the source code for those, but you can use them to test against to determine the correctness of your implementation. Cheers, Ralf > Thanks, > Adam Stone > > _______________________________________________ > 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 Sun Dec 28 10:55:54 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 28 Dec 2014 16:55:54 +0100 Subject: [SciPy-Dev] welcome Lars Buitinck and Matthew Brett to the Scipy team Message-ID: Hi all, On behalf of the Scipy developers I'd like to welcome Lars Buitinck and Matthew Brett as members of the core dev team. Both Lars and Matthew have been important contributors for a long time, this just makes it "official" (i.e. they now have commit rights). Matthew's first patch that I can find is from 2006; currently he is the maintainer of scipy.io.matlab and builds OS X wheels for our releases. Lars has been making improvements and fixes all over the code base for quite a while - 55 PRs and counting. I'm looking forward to their continued contributions! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Sun Dec 28 12:59:40 2014 From: charlesr.harris at gmail.com (Charles R Harris) Date: Sun, 28 Dec 2014 10:59:40 -0700 Subject: [SciPy-Dev] welcome Lars Buitinck and Matthew Brett to the Scipy team In-Reply-To: References: Message-ID: On Sun, Dec 28, 2014 at 8:55 AM, Ralf Gommers wrote: > Hi all, > > On behalf of the Scipy developers I'd like to welcome Lars Buitinck and > Matthew Brett as members of the core dev team. Both Lars and Matthew have > been important contributors for a long time, this just makes it "official" > (i.e. they now have commit rights). > > Matthew's first patch that I can find is from 2006; currently he is the > maintainer of scipy.io.matlab and builds OS X wheels for our releases. Lars > has been making improvements and fixes all over the code base for quite a > while - 55 PRs and counting. > > I'm looking forward to their continued contributions! > > +1 Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From simlangen at gmail.com Mon Dec 29 06:53:37 2014 From: simlangen at gmail.com (Simen Langseth) Date: Mon, 29 Dec 2014 20:53:37 +0900 Subject: [SciPy-Dev] Possibly a bug in scipy.spatial.distance.mahalanobis Message-ID: Dear Scipy Developers: The documentation below mentions the following for the formula of mahalanobis distance: [image: \sqrt{ (u-v) V^{-1} (u-v)^T }] http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.spatial.distance.mahalanobis.html#scipy.spatial.distance.mahalanobis However, in the following source code, the transpose of the delta seems to be missing. u = _validate_vector(u) v = _validate_vector(v)VI = np.atleast_2d(VI)delta = u - vm = np.dot(np.dot(delta, VI), delta)return np.sqrt(m) https://github.com/scipy/scipy/blob/6a7327e8bb8248b2ea165180bc602edf1ab33dda/scipy/spatial/distance.py Please forgive me if I could not understand the source code perfectly. Thanks. Simen -------------- next part -------------- An HTML attachment was scrubbed... URL: From heldercro at gmail.com Mon Dec 29 07:09:26 2014 From: heldercro at gmail.com (Helder) Date: Mon, 29 Dec 2014 10:09:26 -0200 Subject: [SciPy-Dev] Possibly a bug in scipy.spatial.distance.mahalanobis In-Reply-To: References: Message-ID: @Simen seems to be right. Even on master branch [1] its still without delta transpose. [1] https://github.com/scipy/scipy/blob/master/scipy/spatial/distance.py Att, *Helder C. R. de Oliveira* EESC/Universidade de S?o Paulo http://helderc.net 2014-12-29 9:53 GMT-02:00 Simen Langseth : > Dear Scipy Developers: > > The documentation below mentions the following for the formula of > mahalanobis distance: > > [image: \sqrt{ (u-v) V^{-1} (u-v)^T }] > > > http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.spatial.distance.mahalanobis.html#scipy.spatial.distance.mahalanobis > > However, in the following source code, the transpose of the delta seems to > be missing. > > u = _validate_vector(u) v = _validate_vector(v)VI = np.atleast_2d(VI)delta > = u - vm = np.dot(np.dot(delta, VI), delta)return np.sqrt(m) > > > > > https://github.com/scipy/scipy/blob/6a7327e8bb8248b2ea165180bc602edf1ab33dda/scipy/spatial/distance.py > > Please forgive me if I could not understand the source code perfectly. > > Thanks. > > Simen > > > _______________________________________________ > 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 Mon Dec 29 09:27:46 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 29 Dec 2014 09:27:46 -0500 Subject: [SciPy-Dev] Possibly a bug in scipy.spatial.distance.mahalanobis In-Reply-To: References: Message-ID: On Mon, Dec 29, 2014 at 6:53 AM, Simen Langseth wrote: > Dear Scipy Developers: > > The documentation below mentions the following for the formula of > mahalanobis distance: > > [image: \sqrt{ (u-v) V^{-1} (u-v)^T }] > > > http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.spatial.distance.mahalanobis.html#scipy.spatial.distance.mahalanobis > > However, in the following source code, the transpose of the delta seems to > be missing. > > u = _validate_vector(u) v = _validate_vector(v)VI = np.atleast_2d(VI)delta > = u - vm = np.dot(np.dot(delta, VI), delta)return np.sqrt(m) > > > > > https://github.com/scipy/scipy/blob/6a7327e8bb8248b2ea165180bc602edf1ab33dda/scipy/spatial/distance.py > > Please forgive me if I could not understand the source code perfectly. > > The x and y arguments to mahalanobis() must be one-dimensional arrays. This is enforced by _validate_vector(), which converts arguments with shape (N,1) or (1,N) to have shape (N,). A transpose applied to a one-dimensional array doesn't do anything, so there is no need for the transpose operation in the code. Warren Thanks. > > Simen > > > _______________________________________________ > 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 simlangen at gmail.com Mon Dec 29 10:05:36 2014 From: simlangen at gmail.com (Simen Langseth) Date: Tue, 30 Dec 2014 00:05:36 +0900 Subject: [SciPy-Dev] Possibly a bug in scipy.spatial.distance.mahalanobis In-Reply-To: References: Message-ID: Dear Warren Weckesser Thanks for your explanation, and sorry for my ignorance. Your answer made me confidence in using Scipy functions. On Mon, Dec 29, 2014 at 11:27 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > > > On Mon, Dec 29, 2014 at 6:53 AM, Simen Langseth > wrote: > >> Dear Scipy Developers: >> >> The documentation below mentions the following for the formula of >> mahalanobis distance: >> >> [image: \sqrt{ (u-v) V^{-1} (u-v)^T }] >> >> >> http://docs.scipy.org/doc/scipy-0.14.0/reference/generated/scipy.spatial.distance.mahalanobis.html#scipy.spatial.distance.mahalanobis >> >> However, in the following source code, the transpose of the delta seems >> to be missing. >> >> u = _validate_vector(u) v = _validate_vector(v)VI = np.atleast_2d(VI)delta >> = u - vm = np.dot(np.dot(delta, VI), delta)return np.sqrt(m) >> >> >> >> >> https://github.com/scipy/scipy/blob/6a7327e8bb8248b2ea165180bc602edf1ab33dda/scipy/spatial/distance.py >> >> Please forgive me if I could not understand the source code perfectly. >> >> > > The x and y arguments to mahalanobis() must be one-dimensional arrays. > This is enforced by _validate_vector(), which converts arguments with shape > (N,1) or (1,N) to have shape (N,). A transpose applied to a > one-dimensional array doesn't do anything, so there is no need for the > transpose operation in the code. > > Warren > > > Thanks. >> >> Simen >> >> >> _______________________________________________ >> 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 Dec 30 09:17:48 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 30 Dec 2014 15:17:48 +0100 Subject: [SciPy-Dev] removing lib.blas/lapack Message-ID: Hi, The following have been deprecated since scipy 0.12.0: - scipy.lib.blas - scipy.lib.lapack - scipy.linalg.blas.cblas - scipy.linalg.blas.fblas - scipy.linalg.lapack.clapack - scipy.linalg.lapack.flapack See http://docs.scipy.org/doc/scipy/reference/release.0.12.0.html#deprecated-features It looks to me like it's time to remove those for 0.16.0. Then scipy.lib doesn't contain anything public anymore and will then be renamed scipy._lib. Any objections? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Tue Dec 30 10:36:27 2014 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Tue, 30 Dec 2014 15:36:27 +0000 Subject: [SciPy-Dev] removing lib.blas/lapack In-Reply-To: References: Message-ID: +1 On Dec 30, 2014 2:17 PM, "Ralf Gommers" wrote: > Hi, > > The following have been deprecated since scipy 0.12.0: > - scipy.lib.blas > - scipy.lib.lapack > - scipy.linalg.blas.cblas > - scipy.linalg.blas.fblas > - scipy.linalg.lapack.clapack > - scipy.linalg.lapack.flapack > See > http://docs.scipy.org/doc/scipy/reference/release.0.12.0.html#deprecated-features > > It looks to me like it's time to remove those for 0.16.0. Then scipy.lib > doesn't contain anything public anymore and will then be renamed scipy._lib. > > Any objections? > > 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 sturla.molden at gmail.com Tue Dec 30 11:49:08 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 30 Dec 2014 16:49:08 +0000 (UTC) Subject: [SciPy-Dev] removing lib.blas/lapack References: Message-ID: <1289285722441650875.511778sturla.molden-gmail.com@news.gmane.org> They are just a source of confusion now. Sturla Ralf Gommers wrote: > Hi, > > The following have been deprecated since scipy 0.12.0: > - scipy.lib.blas > - scipy.lib.lapack > - scipy.linalg.blas.cblas > - scipy.linalg.blas.fblas > - scipy.linalg.lapack.clapack > - scipy.linalg.lapack.flapack > See > href="http://docs.scipy.org/doc/scipy/reference/release.0.12.0.html#deprecated-features">http://docs.scipy.org/doc/scipy/reference/release.0.12.0.html#deprecated-features > > It looks to me like it's time to remove those for 0.16.0. Then scipy.lib > doesn't contain anything public anymore and will then be renamed scipy._lib. > > Any objections? > > Ralf > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > href="http://mail.scipy.org/mailman/listinfo/scipy-dev">http://mail.scipy.org/mailman/listinfo/scipy-dev From pav at iki.fi Tue Dec 30 15:23:34 2014 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 30 Dec 2014 22:23:34 +0200 Subject: [SciPy-Dev] ANN: Scipy 0.14.1 release Message-ID: <54A309C6.3080504@iki.fi> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We are pleased to announce the Scipy 0.14.1 release. The 0.14.1 release is a bugfix-only release, addressing the following issues: - - gh-3630 NetCDF reading results in a segfault - - gh-3631 SuperLU object not working as expected for complex matrices - - gh-3733 Segfault from map_coordinates - - gh-3780 Segfault when using CSR/CSC matrix and uint32/uint64 - - gh-3781 Fix omitted types in sparsetools typemaps - - gh-3802 0.14.0 API breakage: _gen generators are missing from scipy.stats.distributions API - - gh-3805 Ndimge test failures with numpy 1.10 - - gh-3812 == sometimes wrong on csr_matrix - - gh-3853 Many scipy.sparse test errors/failures with numpy 1.9.0b2 - - gh-4084 Fix exception declarations for Cython 0.21.1 compatibility - - gh-4093 Avoid a memory error in splev(x, tck, der=k) - - gh-4104 Workaround SGEMV segfault in Accelerate (maintenance 0.14.x) - - gh-4143 Fix ndimage functions for large data - - gh-4149 Bug in expm for integer arrays - - gh-4154 Ensure that the 'size' argument of PIL's 'resize' method is a tuple - - gh-4163 ZeroDivisionError in scipy.sparse.linalg.lsqr - - gh-4164 Remove use of deprecated numpy API in lib/lapack/ f2py wrapper - - gh-4180 PIL resize support tuple fix - - gh-4168 Address arpack test failures on windows 32 bits with numpy 1.9.1 - - gh-4203 Sparse matrix multiplication in 0.14.x slower compared to 0.13.x - - gh-4218 Make ndimage interpolation compatible with numpy relaxed strides - - gh-4225 Off-by-one error in PPoly shape checks - - gh-4248 Fix issue with incorrect use of closure for slsqp Source tarballs and binaries are available at https://sourceforge.net/projects/scipy/files/SciPy/0.14.1/ Best regards, Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlSjCcYACgkQ6BQxb7O0pWBxcwCfcnd4uva5hzMHQlHmWxlfbja3 T0AAn2QQmhcotDRB2c2p41Xzjb4MJ13f =yBxH -----END PGP SIGNATURE----- From ralf.gommers at gmail.com Tue Dec 30 16:19:16 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 30 Dec 2014 22:19:16 +0100 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.14.1 release In-Reply-To: <54A309C6.3080504@iki.fi> References: <54A309C6.3080504@iki.fi> Message-ID: On Tue, Dec 30, 2014 at 9:23 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We are pleased to announce the Scipy 0.14.1 release. > Thanks a lot for taking care of this release Pauli! Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Dec 31 09:44:49 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 31 Dec 2014 15:44:49 +0100 Subject: [SciPy-Dev] removing lib.blas/lapack In-Reply-To: References: Message-ID: On Tue, Dec 30, 2014 at 4:36 PM, Evgeni Burovski wrote: > +1 > Okay, PR here: https://github.com/scipy/scipy/pull/4347 Ralf On Dec 30, 2014 2:17 PM, "Ralf Gommers" wrote: > >> Hi, >> >> The following have been deprecated since scipy 0.12.0: >> - scipy.lib.blas >> - scipy.lib.lapack >> - scipy.linalg.blas.cblas >> - scipy.linalg.blas.fblas >> - scipy.linalg.lapack.clapack >> - scipy.linalg.lapack.flapack >> See >> http://docs.scipy.org/doc/scipy/reference/release.0.12.0.html#deprecated-features >> >> It looks to me like it's time to remove those for 0.16.0. Then scipy.lib >> doesn't contain anything public anymore and will then be renamed scipy._lib. >> >> Any objections? >> >> 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: