From fbreitling at aip.de Fri Feb 1 05:36:24 2013 From: fbreitling at aip.de (Frank Breitling) Date: Fri, 01 Feb 2013 11:36:24 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510A9426.9080401@molden.no> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> Message-ID: <510B9AA8.4030401@aip.de> Hi Strula, Thank you very much for your answer and examples. What I understand form them is that there is currently no simple and fast method for plotting 2D histograms with variable bin width. Therefore I would like to come back to my initial feature request for imshow. It seems to me that with an implementation of a variable bin width all other solutions would collapse into a one-liner providing even best performance. From a technical perspective I understand that the philosophy behind imshow is to keep it simple to maintain its high speed. On the other hand a smart implementation of a variable bin width should at most result in a small penalty at the start of the execution. Therefore I would like to confirm my feature request to imshow. However, since this is a matplotlib issue (as you pointed out before), I should probably file it at their trackers. Thanks again for your replies Frank On 31.01.2013 16:56, Sturla Molden wrote: > On 31.01.2013 16:32, Frank Breitling wrote: > >> My experience with pcolor was that is was very slow. > imshow is fast because it basically just bitblit the image. You can > always use Python (or Cython, Fortran or C) to prepare an image from > your 2D data and pass that to imshow. > > I showed you can example where I used contourf. I kind of show too, but > I often just let the computer run for a while and prepare a bunch of PDF > files with the spectrums. Then I can take those into e.g. Adobe > Illustrator later on, and I will also store the wavelet data in PyTables > (HDF5) files. > > If I needed to render a spectrum in "real-time", I would use imshow or > OpenGL, and e.g. have my own Fortran 90 code prepare the displayed > image. I might even consider to use PyOpenGL to write vertex shaders and > have the graphics hardware do all the rendering. > > So it really depends on how fast you need it to be. Python code can draw > your data with OpenGL at the full speed that your graphics hardware > allows. Or you can settle for slower but more convenient data > visualization methods like pcolor and contourf. Or you can do something > in between. > > But as for the question you asked (how to draw a 2D historgram), pcolor > does exactly that. I did not say it will be fast for huge data sets. I > thought you were used to e.g. Matlab and wanted something like image or > imagesc, and then found imshow but overlooked pcolor. > > > :-) > > > Sturla > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From sturla at molden.no Fri Feb 1 10:59:23 2013 From: sturla at molden.no (Sturla Molden) Date: Fri, 01 Feb 2013 16:59:23 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510B9AA8.4030401@aip.de> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> Message-ID: <510BE65B.7040300@molden.no> On 01.02.2013 11:36, Frank Breitling wrote: > Thank you very much for your answer and examples. What I understand form > them is that there is currently no simple and fast method for plotting > 2D histograms with variable bin width. Not, not simple and fast (unless you work with something else than matplotlib). > Therefore I would like to come back to my initial feature request for > imshow. It seems to me that with an implementation of a variable bin > width all other solutions would collapse into a one-liner providing even > best performance. From a technical perspective I understand that the > philosophy behind imshow is to keep it simple to maintain its high > speed. On the other hand a smart implementation of a variable bin width > should at most result in a small penalty at the start of the execution. Digital images and computer screens do not have variable pixel size. imshow plots images. The speed is a coincidence and not very relevant. A feature request for drawing images with variable pixel size will probably be discarded as invalid. It sounds like you want a faster pcolor or pcolormesh. They will probably be happy if you can help with it. A feature request for a faster pcolor and pcolormesh might have a better chance of surviving. Sturla From toddrjen at gmail.com Fri Feb 1 11:19:19 2013 From: toddrjen at gmail.com (Todd) Date: Fri, 1 Feb 2013 17:19:19 +0100 Subject: [SciPy-Dev] Vector Strength function In-Reply-To: References: Message-ID: On Wed, Jan 9, 2013 at 8:44 PM, wrote: > On Wed, Jan 9, 2013 at 12:32 PM, Todd wrote: > > I am interested in implementing a function for scipy. The function is > > called "vector strength". It is basically a measure of how reliably a > set > > of events occur at a particular phase. > > > > It was originally developed for neuroscience research, to determine how > well > > a set of neural events sync up with a periodic stimulus like a sound > > waveform. > > > > However, it is useful for determining how periodic a supposedly periodic > set > > of events really are, for example: > > > > 1. Determining whether crime is really more common during a full moon > and by > > how much > > 2. Determining how concentrated visitors to a coffee shop are during rush > > hour > > 3. Determining exactly how concentrated hurricanes are during hurricane > > season > > > > > > My thinking is that this could be implemented in stages: > > > > First would be a Numpy function that would add a set of vectors in polar > > coordinates. Given a number of magnitude/angle pairs it would provide a > > summed magnitude/angle pair. This would probably be combined with a > > cartesian<->polar conversion functions. > > > > Making use of this function would be a scipy function that would actually > > implement the vector strength calculation. This is done by treating each > > event as a unit vector with a phase, then taking the average of the > vectors. > > If all events have the same phase, the result will have an amplitude of > 1. > > If they all have a different phases, the result will have an amplitude > of 0. > > > > It may even be worth having a dedicated polar dtype, although that may be > > too much. > > > > What does everyone think of this proposal? > > Is this the same as a mean resultant in circular statistics? > > def circular_resultant(rads, axis=0): > mp = np.sum(np.exp(1j*rads), axis=axis) > rho = np.abs(mp) > mu = np.angle(mp) > > return mp, rho, mu > > Josef It looks to be the same as the first part of my proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbreitling at aip.de Sat Feb 2 04:53:28 2013 From: fbreitling at aip.de (Frank Breitling) Date: Sat, 02 Feb 2013 10:53:28 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510BE65B.7040300@molden.no> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> Message-ID: <510CE218.3090908@aip.de> Hi, From the matplotlib developers it was pointed out, that there is a NonUniformImage which might be suite for representing interpolated variable bin size 2D histograms (https://github.com/matplotlib/matplotlib/issues/1729#issuecomment-13014723). There even exists an example (http://matplotlib.org/examples/pylab_examples/image_nonuniform.html) but it is very isolated and therefore not well known. It would be very useful to explain its usage or at least link to it in the histogram2d example at http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html. In addition a pcolor example (attached below) shouldn't be missing. Even though it is slow and can't do interpolation, it can at least do a correct representation for academic purposes. Can anybody do that or would you like me to do that myself? Frank --- import numpy as np, matplotlib.pyplot as plt x=[2] y=[0] xedges=[0,1,3] yedges=[0,1] H, yedges, xedges = np.histogram2d(y,x, bins=(yedges,xedges)) extent = [xedges[0], xedges[-1], yedges[-1], yedges[0]] X,Y = np.meshgrid(xedges, yedges) plt.pcolor(X, Y, H) plt.colorbar() plt.show() From ralf.gommers at gmail.com Sat Feb 2 07:41:27 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 2 Feb 2013 13:41:27 +0100 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: <510A7F5E.7090706@hilboll.de> References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: On Thu, Jan 31, 2013 at 3:27 PM, Andreas Hilboll wrote: > > Any updates? > > > > Please let me know how it is? what could be added? (Firstly whether you > > like it to put as scipy-central home page) > > > > I think the convention on this list is to bottom-post. > > Well, so far it doesn't look like finished. I guess everyone is waiting > for you to just continue, and basically show some more final result. > > If you ask me, I would want categories and/or tags on the front page, > and the recently updated / most viewed / top contributors could go into > a side panel. Also there should be some slogan / text telling the > visitor on which kind of website she is. Like it is now, I wouldn't know > where I am and leave again. Also, I personally don't like the black in > combination with the quite light blue of the logo. > I quite like how the new design looks visually. Putting less different things on it than on the current scipy-central site makes sense, especially the tag cloud and list of contributors don't add much. I would put the name "SciPy Central" somewhere though (on the black bar or in/next to the logo?). Having one list of direct links to contributions that are ranked highest (as determined by a combination of recent activity and popularity?) under the search would be good imho. Cheers, Ralf > This is just my 2 cents. As someone said earlier, I think the best way > for you is to just proceed and ask the list about your results, not > about any single step you want to take. Just go ahead :) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sat Feb 2 08:01:29 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 02 Feb 2013 15:01:29 +0200 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: 02.02.2013 14:41, Ralf Gommers kirjoitti: [clip] > I quite like how the new design looks visually. Putting less different > things on it than on the current scipy-central site makes sense, > especially the tag cloud and list of contributors don't add much. I > would put the name "SciPy Central" somewhere though (on the black bar or > in/next to the logo?). Having one list of direct links to contributions > that are ranked highest (as determined by a combination of recent > activity and popularity?) under the search would be good imho. The popularity measure is however probably only useful if search engine robots are not counted. I think at present there is no differentiation between bone-and-flesh and mechanical visitors. It seems likely there is an existing Django plugin that does this already. Pauli From sturla at molden.no Sat Feb 2 10:44:59 2013 From: sturla at molden.no (Sturla Molden) Date: Sat, 02 Feb 2013 16:44:59 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510CE218.3090908@aip.de> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> Message-ID: <510D347B.2000207@molden.no> On 02.02.2013 10:53, Frank Breitling wrote: > Hi, > > From the matplotlib developers it was pointed out, that there is a > NonUniformImage which might be suite for representing interpolated > variable bin size 2D histograms > (https://github.com/matplotlib/matplotlib/issues/1729#issuecomment-13014723). > There even exists an example > (http://matplotlib.org/examples/pylab_examples/image_nonuniform.html) > but it is very isolated and therefore not well known. > It would be very useful to explain its usage or at least link to it in > the histogram2d example at > http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html. > > In addition a pcolor example (attached below) shouldn't be missing. Even > though it is slow and can't do interpolation, it can at least do a > correct representation for academic purposes. > > Can anybody do that or would you like me to do that myself? > > Frank Since it is at the top of your head, why don't you do it? But it might be better for the SciPy Cookbook's matplotlib section than the NumPy docs. I'm not sure if they want matplotlib examples in the NumPy documentation (ask on the NumPy list before you waste your time on it). http://www.scipy.org/Cookbook/Matplotlib Sturla From fbreitling at aip.de Sat Feb 2 14:59:03 2013 From: fbreitling at aip.de (Frank Breitling) Date: Sat, 02 Feb 2013 20:59:03 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510D347B.2000207@molden.no> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> <510D347B.2000207@molden.no> Message-ID: <510D7007.5000808@aip.de> Hi, So I registered an account, but I have to request write permission by email to scipy-dev at scipy.org first. So could somebody give me write permission to the page http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html and maybe also to http://www.scipy.org/Cookbook/Matplotlib ? Or otherwise could somebody add the example below for me? Frank --- import numpy as np, matplotlib.pyplot as plt x = np.random.normal(3, 2, 1000) y = np.random.normal(3, 1, 1000) yedges=xedges=[0,2,3,4,6] H, yedges, xedges = np.histogram2d(y,x, bins=(yedges,xedges)) extent = [xedges[0], xedges[-1], yedges[-1], yedges[0]] #If bin size is equal imshow can be used. It is fast and provides interpolation. #plt.imshow(H, extent=extent, interpolation='None', aspect='auto') #To display variable bin size pcolar can be used X,Y = np.meshgrid(xedges, yedges) plt.pcolor(X, Y, H) #If interpolation is needed in addition matplotlib provides the NonUniformImage: #http://matplotlib.org/examples/pylab_examples/image_nonuniform.html plt.colorbar() plt.show() On 2013-02-02 16:44, Sturla Molden wrote: > On 02.02.2013 10:53, Frank Breitling wrote: >> Hi, >> >> From the matplotlib developers it was pointed out, that there is a >> NonUniformImage which might be suite for representing interpolated >> variable bin size 2D histograms >> (https://github.com/matplotlib/matplotlib/issues/1729#issuecomment-13014723). >> There even exists an example >> (http://matplotlib.org/examples/pylab_examples/image_nonuniform.html) >> but it is very isolated and therefore not well known. >> It would be very useful to explain its usage or at least link to it in >> the histogram2d example at >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html. >> >> In addition a pcolor example (attached below) shouldn't be missing. Even >> though it is slow and can't do interpolation, it can at least do a >> correct representation for academic purposes. >> >> Can anybody do that or would you like me to do that myself? >> >> Frank > Since it is at the top of your head, why don't you do it? > > But it might be better for the SciPy Cookbook's matplotlib section > than the NumPy docs. I'm not sure if they want matplotlib examples in > the NumPy documentation (ask on the NumPy list before you waste your > time on it). > > > http://www.scipy.org/Cookbook/Matplotlib > > > > Sturla > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From sturla at molden.no Sat Feb 2 15:52:04 2013 From: sturla at molden.no (Sturla Molden) Date: Sat, 02 Feb 2013 21:52:04 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510D7007.5000808@aip.de> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> <510D347B.2000207@molden.no> <510D7007.5000808@aip.de> Message-ID: <510D7C74.8040901@molden.no> That is not how it works. If you have a suggestion for changing the NumPy (including docs) you fork NumPy on GitHub.com and post a pull-request with your changes. And that would be after asking on the NumPy list (not on scipy-dev!). They might also want you to open an issue on their GitHub tracker. All users on scipy.org should be able to update the cookbook. At least that it how it worked before. If you want to create a new page on the wiki you just navigate to it with your browser. Sturla On 02.02.2013 20:59, Frank Breitling wrote: > Hi, > > So I registered an account, but I have to request write permission by > email to scipy-dev at scipy.org first. > So could somebody give me write permission to the page > http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html > and maybe also to http://www.scipy.org/Cookbook/Matplotlib ? > > Or otherwise could somebody add the example below for me? > > Frank > > --- > import numpy as np, matplotlib.pyplot as plt > > x = np.random.normal(3, 2, 1000) > y = np.random.normal(3, 1, 1000) > > yedges=xedges=[0,2,3,4,6] > > H, yedges, xedges = np.histogram2d(y,x, bins=(yedges,xedges)) > extent = [xedges[0], xedges[-1], yedges[-1], yedges[0]] > > #If bin size is equal imshow can be used. It is fast and provides > interpolation. > #plt.imshow(H, extent=extent, interpolation='None', > aspect='auto') > > #To display variable bin size pcolar can be used > X,Y = np.meshgrid(xedges, yedges) > plt.pcolor(X, Y, > H) > > #If interpolation is needed in addition matplotlib provides the > NonUniformImage: > #http://matplotlib.org/examples/pylab_examples/image_nonuniform.html > > plt.colorbar() > plt.show() > > > > On 2013-02-02 16:44, Sturla Molden wrote: >> On 02.02.2013 10:53, Frank Breitling wrote: >>> Hi, >>> >>> From the matplotlib developers it was pointed out, that there is a >>> NonUniformImage which might be suite for representing interpolated >>> variable bin size 2D histograms >>> (https://github.com/matplotlib/matplotlib/issues/1729#issuecomment-13014723). >>> There even exists an example >>> (http://matplotlib.org/examples/pylab_examples/image_nonuniform.html) >>> but it is very isolated and therefore not well known. >>> It would be very useful to explain its usage or at least link to it in >>> the histogram2d example at >>> http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html. >>> >>> In addition a pcolor example (attached below) shouldn't be missing. Even >>> though it is slow and can't do interpolation, it can at least do a >>> correct representation for academic purposes. >>> >>> Can anybody do that or would you like me to do that myself? >>> >>> Frank >> Since it is at the top of your head, why don't you do it? >> >> But it might be better for the SciPy Cookbook's matplotlib section >> than the NumPy docs. I'm not sure if they want matplotlib examples in >> the NumPy documentation (ask on the NumPy list before you waste your >> time on it). >> >> >> http://www.scipy.org/Cookbook/Matplotlib >> >> >> >> Sturla >> >> >> _______________________________________________ >> 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 fbreitling at aip.de Sat Feb 2 16:37:04 2013 From: fbreitling at aip.de (Frank Breitling) Date: Sat, 02 Feb 2013 22:37:04 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510D7C74.8040901@molden.no> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> <510D347B.2000207@molden.no> <510D7007.5000808@aip.de> <510D7C74.8040901@molden.no> Message-ID: <510D8700.2020804@aip.de> On 2013-02-02 21:52, Sturla Molden wrote: > That is not how it works. > > If you have a suggestion for changing the NumPy (including docs) you > fork NumPy on GitHub.com and post a pull-request with your changes. And > that would be after asking on the NumPy list (not on scipy-dev!). > They might also want you to open an issue on their GitHub tracker. Oh, that sounds complicated. But the edit link on the left at http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html and the instruction to ask for write permission through the scipy-dev at scipy.org suggest that one should be able to edit this page directly? Unfortunately my registration for the http://www.scipy.org/Cookbook/Matplotlib/UnfilledHistograms three hours ago timed out with the following message: "Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root at enthought.com and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log." Meanwhile I haven't received an answer from the root at enthought.com. After all the threshold for a contribution seems quite high. Frank From sturla at molden.no Sat Feb 2 16:47:10 2013 From: sturla at molden.no (Sturla Molden) Date: Sat, 02 Feb 2013 22:47:10 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510D8700.2020804@aip.de> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> <510D347B.2000207@molden.no> <510D7007.5000808@aip.de> <510D7C74.8040901@molden.no> <510D8700.2020804@aip.de> Message-ID: <510D895E.50900@molden.no> On 02.02.2013 22:37, Frank Breitling wrote: > > But the edit link on the left at > http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html > and the instruction to ask for write permission through the > scipy-dev at scipy.org suggest that one should be able to edit this page > directly? It believe it is generated from this: https://github.com/numpy/numpy/tree/master/doc Sturla From fbreitling at aip.de Sun Feb 3 04:25:51 2013 From: fbreitling at aip.de (Frank Breitling) Date: Sun, 03 Feb 2013 10:25:51 +0100 Subject: [SciPy-Dev] 2D histogram: request for plotting variable bin size In-Reply-To: <510D895E.50900@molden.no> References: <510A794D.7050102@aip.de> <510A845E.8030008@molden.no> <510A85CF.2050609@molden.no> <510A8E85.7030300@aip.de> <510A9426.9080401@molden.no> <510B9AA8.4030401@aip.de> <510BE65B.7040300@molden.no> <510CE218.3090908@aip.de> <510D347B.2000207@molden.no> <510D7007.5000808@aip.de> <510D7C74.8040901@molden.no> <510D8700.2020804@aip.de> <510D895E.50900@molden.no> Message-ID: <510E2D1F.5070106@aip.de> Hi, It seems like my account for the cookbook is working now. But when clicking on create new page http://www.scipy.org/Cookbook/Histograms?action=edit I received the error below. I don't know how to fix this. Frank --- OSError [Errno 31] Too many links: '/home/scipy/wiki/data/pages/Cookbook(2f)Histograms' If you want to report a bug, please save this page and attach it to your bug report. Show debugging information Report bug Visit MoinMoin wiki Traceback A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /usr/lib/python2.4/site-packages/MoinMoin/request.py in run (self=) 1149 from MoinMoin.wikiaction import getHandler 1150 handler = getHandler(self, action) 1151 handler(self.page.page_name, self) 1152 1153 # generate page footer (actions that do not want this footer use handler = self = self.page = self.page.page_name = u'Cookbook/Histograms' /usr/lib/python2.4/site-packages/MoinMoin/wikiaction.py in do_edit (pagename=u'Cookbook/Histograms', request=) 580 # is invoked without savetext start editing 581 if savetext is None: 582 pg.sendEditor() 583 return 584 pg = pg.sendEditor = > /usr/lib/python2.4/site-packages/MoinMoin/PageEditor.py in sendEditor (self=, **kw={}) 176 except OSError, err: 177 if err.errno != errno.ENAMETOOLONG: 178 raise err 179 msg = _("Page name is too long, try shorter name.") 180 err = OSError [Errno 31] Too many links: '/home/scipy/wiki/data/pages/Cookbook(2f)Histograms' args = (31, 'Too many links') errno = 31 filename = '/home/scipy/wiki/data/pages/Cookbook(2f)Histograms' strerror = 'Too many links' System Details Date: Sun, 03 Feb 2013 09:15:15 +0000 Platform: Linux scipy.org 2.6.32-4-pve #1 SMP Thu Oct 21 09:35:29 CEST 2010 i686 Python: Python 2.4.3 (/usr/bin/python) MoinMoin: Release 1.5.6 (release) Am 02.02.2013 22:47, schrieb Sturla Molden: > On 02.02.2013 22:37, Frank Breitling wrote: >> >> But the edit link on the left at >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram2d.html >> and the instruction to ask for write permission through the >> scipy-dev at scipy.org suggest that one should be able to edit this page >> directly? > > It believe it is generated from this: > > https://github.com/numpy/numpy/tree/master/doc > > > > Sturla > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From warren.weckesser at gmail.com Sun Feb 3 11:57:35 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 3 Feb 2013 11:57:35 -0500 Subject: [SciPy-Dev] How is generate_ufuncs.py (in scipy/seciall) used? Message-ID: Could someone explain how generate_ufuncs.py in scipy/special is used (if it is, in fact, used)? I don't see any references to it anywhere. Thanks, Warren From pav at iki.fi Sun Feb 3 12:24:54 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 03 Feb 2013 19:24:54 +0200 Subject: [SciPy-Dev] How is generate_ufuncs.py (in scipy/seciall) used? In-Reply-To: References: Message-ID: Hi, 03.02.2013 18:57, Warren Weckesser kirjoitti: > Could someone explain how generate_ufuncs.py in scipy/special is used > (if it is, in fact, used)? I don't see any references to it anywhere. The top of the file says: #!/usr/bin/python """ generate_ufuncs.py Generate Ufunc definition source files for scipy.special. Produces files '_ufuncs.c' and '_ufuncs_cxx.c' by first producing Cython. -- Pauli Virtanen From warren.weckesser at gmail.com Sun Feb 3 13:00:15 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 3 Feb 2013 13:00:15 -0500 Subject: [SciPy-Dev] How is generate_ufuncs.py (in scipy/seciall) used? In-Reply-To: References: Message-ID: On 2/3/13, Pauli Virtanen wrote: > Hi, > > 03.02.2013 18:57, Warren Weckesser kirjoitti: >> Could someone explain how generate_ufuncs.py in scipy/special is used >> (if it is, in fact, used)? I don't see any references to it anywhere. > > The top of the file says: > > #!/usr/bin/python > """ > generate_ufuncs.py > > Generate Ufunc definition source files for scipy.special. Produces > files '_ufuncs.c' and '_ufuncs_cxx.c' by first producing Cython. > I saw that, but I was looking for something else that runs the script. I guess this is always run "by hand"? Warren P.S. I see that this file will be removed if PR 403 (https://github.com/scipy/scipy/pull/403) is accepted. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From pav at iki.fi Sun Feb 3 13:15:53 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 03 Feb 2013 20:15:53 +0200 Subject: [SciPy-Dev] How is generate_ufuncs.py (in scipy/seciall) used? In-Reply-To: References: Message-ID: 03.02.2013 20:00, Warren Weckesser kirjoitti: [clip] > I saw that, but I was looking for something else that runs the script. > I guess this is always run "by hand"? Yes, it's run manually, like the rest of the `generate_*` scripts. It could also be run at build time, in principle, provided Cython is available. > P.S. I see that this file will be removed if PR 403 > (https://github.com/scipy/scipy/pull/403) is accepted. Hmm, it at least shouldn't be removed by that PR... -- Pauli Virtanen From warren.weckesser at gmail.com Sun Feb 3 13:22:04 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sun, 3 Feb 2013 13:22:04 -0500 Subject: [SciPy-Dev] How is generate_ufuncs.py (in scipy/seciall) used? In-Reply-To: References: Message-ID: On 2/3/13, Pauli Virtanen wrote: > 03.02.2013 20:00, Warren Weckesser kirjoitti: > [clip] >> I saw that, but I was looking for something else that runs the script. >> I guess this is always run "by hand"? > > Yes, it's run manually, like the rest of the `generate_*` scripts. > It could also be run at build time, in principle, provided Cython is > available. > >> P.S. I see that this file will be removed if PR 403 >> (https://github.com/scipy/scipy/pull/403) is accepted. > > Hmm, it at least shouldn't be removed by that PR... > Sorry, I misread the github page. The file is not removed in the PR. Warren > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From suryak at ieee.org Sun Feb 3 22:12:59 2013 From: suryak at ieee.org (Surya Kasturi) Date: Mon, 4 Feb 2013 08:42:59 +0530 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: On Sat, Feb 2, 2013 at 6:11 PM, Ralf Gommers wrote: > > > > On Thu, Jan 31, 2013 at 3:27 PM, Andreas Hilboll wrote: > >> > Any updates? >> > >> > Please let me know how it is? what could be added? (Firstly whether you >> > like it to put as scipy-central home page) >> > >> >> I think the convention on this list is to bottom-post. >> >> Well, so far it doesn't look like finished. I guess everyone is waiting >> for you to just continue, and basically show some more final result. >> >> If you ask me, I would want categories and/or tags on the front page, >> and the recently updated / most viewed / top contributors could go into >> a side panel. Also there should be some slogan / text telling the >> visitor on which kind of website she is. Like it is now, I wouldn't know >> where I am and leave again. Also, I personally don't like the black in >> combination with the quite light blue of the logo. >> > > I quite like how the new design looks visually. Putting less different > things on it than on the current scipy-central site makes sense, especially > the tag cloud and list of contributors don't add much. I would put the name > "SciPy Central" somewhere though (on the black bar or in/next to the > logo?). Having one list of direct links to contributions that are ranked > highest (as determined by a combination of recent activity and popularity?) > under the search would be good imho. > > Cheers, > Ralf > > Nice! I will continue my work. Will post new updates on the list (may take 2 weeks). Actually there are two home designs we can use 1. A clean simple home page with a search input.. of course, couple of links below search bar (ex: google.com) 2. A "modern" forum style page. We can have a search bar on the center-top while, the rest of the page is neatly occupied with latest/ new updates. We can put "tags" on the right side. I guess this should be developer friendly! Stackexchange sites are a good example. Also, http://social.msdn.microsoft.com/Forums should be a nice example.. (The above links have inspired me. we can actually understand what kind of design suites well) Actually, I am unable to decide which one to choose. So, was asking on the forum. May be you guys can might already have something in mind. >> This is just my 2 cents. As someone said earlier, I think the best way >> for you is to just proceed and ask the list about your results, not >> about any single step you want to take. Just go ahead :) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sun Feb 3 22:44:42 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 3 Feb 2013 22:44:42 -0500 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: On Sun, Feb 3, 2013 at 10:12 PM, Surya Kasturi wrote: > > > > On Sat, Feb 2, 2013 at 6:11 PM, Ralf Gommers wrote: >> >> >> >> >> On Thu, Jan 31, 2013 at 3:27 PM, Andreas Hilboll wrote: >>> >>> > Any updates? >>> > >>> > Please let me know how it is? what could be added? (Firstly whether you >>> > like it to put as scipy-central home page) >>> > >>> >>> I think the convention on this list is to bottom-post. >>> >>> Well, so far it doesn't look like finished. I guess everyone is waiting >>> for you to just continue, and basically show some more final result. >>> >>> If you ask me, I would want categories and/or tags on the front page, >>> and the recently updated / most viewed / top contributors could go into >>> a side panel. Also there should be some slogan / text telling the >>> visitor on which kind of website she is. Like it is now, I wouldn't know >>> where I am and leave again. Also, I personally don't like the black in >>> combination with the quite light blue of the logo. >> >> >> I quite like how the new design looks visually. Putting less different >> things on it than on the current scipy-central site makes sense, especially >> the tag cloud and list of contributors don't add much. I would put the name >> "SciPy Central" somewhere though (on the black bar or in/next to the logo?). >> Having one list of direct links to contributions that are ranked highest (as >> determined by a combination of recent activity and popularity?) under the >> search would be good imho. >> >> Cheers, >> Ralf >> > > Nice! I will continue my work. Will post new updates on the list (may take 2 > weeks). Actually there are two home designs we can use > > 1. A clean simple home page with a search input.. of course, couple of links > below search bar (ex: google.com) > 2. A "modern" forum style page. We can have a search bar on the center-top > while, the rest of the page is neatly occupied with latest/ new updates. We > can put "tags" on the right side. I guess this should be developer friendly! > Stackexchange sites are a good example. Also, > http://social.msdn.microsoft.com/Forums should be a nice example.. > > (The above links have inspired me. we can actually understand what kind of > design suites well) > > Actually, I am unable to decide which one to choose. So, was asking on the > forum. May be you guys can might already have something in mind. http://www.mathworks.com/matlabcentral/fileexchange/ no GOOGLE please, I would like to quickly be able to browse and get an overview. (did you ever try to see what are new python packages on http://code.google.com/ ?) Josef > >>> >>> This is just my 2 cents. As someone said earlier, I think the best way >>> for you is to just proceed and ask the list about your results, not >>> about any single step you want to take. Just go ahead :) > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From josef.pktd at gmail.com Sun Feb 3 23:00:44 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 3 Feb 2013 23:00:44 -0500 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: On Sun, Feb 3, 2013 at 10:44 PM, wrote: > On Sun, Feb 3, 2013 at 10:12 PM, Surya Kasturi wrote: >> >> >> >> On Sat, Feb 2, 2013 at 6:11 PM, Ralf Gommers wrote: >>> >>> >>> >>> >>> On Thu, Jan 31, 2013 at 3:27 PM, Andreas Hilboll wrote: >>>> >>>> > Any updates? >>>> > >>>> > Please let me know how it is? what could be added? (Firstly whether you >>>> > like it to put as scipy-central home page) >>>> > >>>> >>>> I think the convention on this list is to bottom-post. >>>> >>>> Well, so far it doesn't look like finished. I guess everyone is waiting >>>> for you to just continue, and basically show some more final result. >>>> >>>> If you ask me, I would want categories and/or tags on the front page, >>>> and the recently updated / most viewed / top contributors could go into >>>> a side panel. Also there should be some slogan / text telling the >>>> visitor on which kind of website she is. Like it is now, I wouldn't know >>>> where I am and leave again. Also, I personally don't like the black in >>>> combination with the quite light blue of the logo. >>> >>> >>> I quite like how the new design looks visually. Putting less different >>> things on it than on the current scipy-central site makes sense, especially >>> the tag cloud and list of contributors don't add much. I would put the name >>> "SciPy Central" somewhere though (on the black bar or in/next to the logo?). >>> Having one list of direct links to contributions that are ranked highest (as >>> determined by a combination of recent activity and popularity?) under the >>> search would be good imho. >>> >>> Cheers, >>> Ralf >>> >> >> Nice! I will continue my work. Will post new updates on the list (may take 2 >> weeks). Actually there are two home designs we can use >> >> 1. A clean simple home page with a search input.. of course, couple of links >> below search bar (ex: google.com) >> 2. A "modern" forum style page. We can have a search bar on the center-top >> while, the rest of the page is neatly occupied with latest/ new updates. We >> can put "tags" on the right side. I guess this should be developer friendly! >> Stackexchange sites are a good example. Also, >> http://social.msdn.microsoft.com/Forums should be a nice example.. >> >> (The above links have inspired me. we can actually understand what kind of >> design suites well) >> >> Actually, I am unable to decide which one to choose. So, was asking on the >> forum. May be you guys can might already have something in mind. > > http://www.mathworks.com/matlabcentral/fileexchange/ > > no GOOGLE please, I would like to quickly be able to browse and get an overview. > > (did you ever try to see what are new python packages on > http://code.google.com/ ?) to clarify: google doesn't know how to present structured data what are the most popular (by downloads) packages on the fileexchange that use the statistics toolbox? http://www.mathworks.com/matlabcentral/fileexchange/index?sort=downloads_desc&term=+product%3A%22Statistics+Toolbox%22 and you can check their sort-by that I'm missing mostly with google (an administrator of google groups cannot even sort members by date. That was bugging me a few hours ago.) I like browsing every once in a while, and not just searching when I already know what the animal I look for is called. So I would prefer not to have just a big search button. Josef > > Josef > >> >>>> >>>> This is just my 2 cents. As someone said earlier, I think the best way >>>> for you is to just proceed and ask the list about your results, not >>>> about any single step you want to take. Just go ahead :) >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> From lists at hilboll.de Mon Feb 4 04:16:43 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Mon, 04 Feb 2013 10:16:43 +0100 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> <510A7F5E.7090706@hilboll.de> Message-ID: <510F7C7B.5030009@hilboll.de> >>>>> Any updates? >>>>> >>>>> Please let me know how it is? what could be added? (Firstly whether you >>>>> like it to put as scipy-central home page) >>>>> >>>> >>>> I think the convention on this list is to bottom-post. >>>> >>>> Well, so far it doesn't look like finished. I guess everyone is waiting >>>> for you to just continue, and basically show some more final result. >>>> >>>> If you ask me, I would want categories and/or tags on the front page, >>>> and the recently updated / most viewed / top contributors could go into >>>> a side panel. Also there should be some slogan / text telling the >>>> visitor on which kind of website she is. Like it is now, I wouldn't know >>>> where I am and leave again. Also, I personally don't like the black in >>>> combination with the quite light blue of the logo. >>> >>> >>> I quite like how the new design looks visually. Putting less different >>> things on it than on the current scipy-central site makes sense, especially >>> the tag cloud and list of contributors don't add much. I would put the name >>> "SciPy Central" somewhere though (on the black bar or in/next to the logo?). >>> Having one list of direct links to contributions that are ranked highest (as >>> determined by a combination of recent activity and popularity?) under the >>> search would be good imho. >>> >>> Cheers, >>> Ralf >>> >> >> Nice! I will continue my work. Will post new updates on the list (may take 2 >> weeks). Actually there are two home designs we can use >> >> 1. A clean simple home page with a search input.. of course, couple of links >> below search bar (ex: google.com) >> 2. A "modern" forum style page. We can have a search bar on the center-top >> while, the rest of the page is neatly occupied with latest/ new updates. We >> can put "tags" on the right side. I guess this should be developer friendly! >> Stackexchange sites are a good example. Also, >> http://social.msdn.microsoft.com/Forums should be a nice example.. >> >> (The above links have inspired me. we can actually understand what kind of >> design suites well) >> >> Actually, I am unable to decide which one to choose. So, was asking on the >> forum. May be you guys can might already have something in mind. > > http://www.mathworks.com/matlabcentral/fileexchange/ > > no GOOGLE please, I would like to quickly be able to browse and get an overview. +1. With google.com, everyone knows what the site is about. scipy-central.org should not assume that the users know what the site can do. So it must tell users what it can do. An "about" box, tags. Also searches. Categories? Your challenge, Surya, is to put all this on the homepage without making the site visually cluttered =) Cheers, Andreas. From fbreitling at aip.de Mon Feb 4 05:35:35 2013 From: fbreitling at aip.de (Frank Breitling) Date: Mon, 04 Feb 2013 11:35:35 +0100 Subject: [SciPy-Dev] OSError with Cookbook Message-ID: <510F8EF7.7010502@aip.de> Hi, I have been trying to create a new page for the SciPy cookbook via http://www.scipy.org/Cookbook/Matplotlib/Histograms?action=edit but received the error below. Who can solve this? Frank --- OSError [Errno 31] Too many links: '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' If you want to report a bug, please save this page and attach it to your bug report. Show debugging information Report bug Visit MoinMoin wiki Traceback A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /usr/lib/python2.4/site-packages/MoinMoin/request.py in run (self=) 1149 from MoinMoin.wikiaction import getHandler 1150 handler = getHandler(self, action) 1151 handler(self.page.page_name, self) 1152 1153 # generate page footer (actions that do not want this footer use handler = self = self.page = self.page.page_name = u'Cookbook/Matplotlib/Histograms' /usr/lib/python2.4/site-packages/MoinMoin/wikiaction.py in do_edit (pagename=u'Cookbook/Matplotlib/Histograms', request=) 580 # is invoked without savetext start editing 581 if savetext is None: 582 pg.sendEditor() 583 return 584 pg = pg.sendEditor = > /usr/lib/python2.4/site-packages/MoinMoin/PageEditor.py in sendEditor (self=, **kw={}) 176 except OSError, err: 177 if err.errno != errno.ENAMETOOLONG: 178 raise err 179 msg = _("Page name is too long, try shorter name.") 180 err = OSError [Errno 31] Too many links: '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' args = (31, 'Too many links') errno = 31 filename = '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' strerror = 'Too many links' System Details Date: Mon, 04 Feb 2013 10:25:58 +0000 Platform: Linux scipy.org 2.6.32-4-pve #1 SMP Thu Oct 21 09:35:29 CEST 2010 i686 Python: Python 2.4.3 (/usr/bin/python) MoinMoin: Release 1.5.6 (release) From sturla at molden.no Mon Feb 4 06:24:51 2013 From: sturla at molden.no (Sturla Molden) Date: Mon, 04 Feb 2013 12:24:51 +0100 Subject: [SciPy-Dev] flapack and the GIL Message-ID: <510F9A83.7000302@molden.no> It seems arbitrary if the flapack f2py interfaces have a 'threadsafe' statement or not. Why is that? https://github.com/scipy/scipy/blob/master/scipy/linalg/flapack.pyf.src I'd assume the whole of BLAS/LAPACK would be reeantrant or not. And this would possibly depend on the libraries itself, e.g. if they are compiled to assume all local variables are 'STATIC' by default. Which means that the right place to determine threadsafety of flapack routines would be in the build process. Sturla From pav at iki.fi Mon Feb 4 13:28:23 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 04 Feb 2013 20:28:23 +0200 Subject: [SciPy-Dev] flapack and the GIL In-Reply-To: <510F9A83.7000302@molden.no> References: <510F9A83.7000302@molden.no> Message-ID: Hi, 04.02.2013 13:24, Sturla Molden kirjoitti: > It seems arbitrary if the flapack f2py interfaces have a 'threadsafe' > statement or not. Why is that? > > https://github.com/scipy/scipy/blob/master/scipy/linalg/flapack.pyf.src > > I'd assume the whole of BLAS/LAPACK would be reeantrant or not. And this > would possibly depend on the libraries itself, e.g. if they are compiled > to assume all local variables are 'STATIC' by default. > Which means that the right place to determine threadsafety of flapack > routines would be in the build process. I think those have been added randomly, so there's no logic behind it AFAIK, *all* of Lapack is threadsafe --- there are no SAVE or COMMON statements. The same is probably true for any modified LAPACK routines in MKL, Accelerate and the ilk. -- Pauli Virtanen From sturla at molden.no Mon Feb 4 13:43:47 2013 From: sturla at molden.no (Sturla Molden) Date: Mon, 04 Feb 2013 19:43:47 +0100 Subject: [SciPy-Dev] flapack and the GIL In-Reply-To: References: <510F9A83.7000302@molden.no> Message-ID: <51100163.9070207@molden.no> On 04.02.2013 19:28, Pauli Virtanen wrote: >> I'd assume the whole of BLAS/LAPACK would be reeantrant or not. And this >> would possibly depend on the libraries itself, e.g. if they are compiled >> to assume all local variables are 'STATIC' by default. >> Which means that the right place to determine threadsafety of flapack >> routines would be in the build process. > > I think those have been added randomly, so there's no logic behind it Yes, that is what it looks like :) > AFAIK, *all* of Lapack is threadsafe --- there are no SAVE or COMMON > statements. The same is probably true for any modified LAPACK routines > in MKL, Accelerate and the ilk. But SAVE can be implicit too. AFAIK, it even used to be (or still is?) the default compiler setting in many f77 compilers. Which means we have to know how LAPACK was built to avoid the problem. I don't think there is an implicit SAVE in MKL or Accelerate though ;-) It's mainly an issue for those who build their own BLAS or LAPACK. Sturla From pav at iki.fi Mon Feb 4 14:09:12 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 04 Feb 2013 21:09:12 +0200 Subject: [SciPy-Dev] flapack and the GIL In-Reply-To: <51100163.9070207@molden.no> References: <510F9A83.7000302@molden.no> <51100163.9070207@molden.no> Message-ID: Hi, 04.02.2013 20:43, Sturla Molden kirjoitti: [clip] > But SAVE can be implicit too. AFAIK, it even used to be (or still is?) > the default compiler setting in many f77 compilers. Which means we have > to know how LAPACK was built to avoid the problem. > > I don't think there is an implicit SAVE in MKL or Accelerate though ;-) > > It's mainly an issue for those who build their own BLAS or LAPACK. ... and reading carefully Gfortran man page shows that it by default puts local variables larger than 32768 bytes in static storage. Ouch. Seems to have bit some people: http://icl.cs.utk.edu/lapack-forum/viewtopic.php?t=1930 Recent LAPACK versions (>= 3.3) claim to be fully thread safe. If we can detect that the LAPACK version (how?) is at least that, we could enable the threadsafe declarations (and do so also for MKL et al.). -- Pauli Virtanen From nils106 at googlemail.com Mon Feb 4 15:11:31 2013 From: nils106 at googlemail.com (Nils Wagner) Date: Mon, 4 Feb 2013 20:11:31 +0000 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-NW-non-integer-slice-parameter.patch Type: application/octet-stream Size: 1124 bytes Desc: not available URL: From pav at iki.fi Mon Feb 4 15:19:39 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 04 Feb 2013 22:19:39 +0200 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: 04.02.2013 22:11, Nils Wagner kirjoitti: [clip: patch] M = int(M) on top of the routine would do the same thing. However, it probably should raise an error, not truncate, when M is not an integer. -- Pauli Virtanen From pav at iki.fi Mon Feb 4 15:40:24 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 04 Feb 2013 22:40:24 +0200 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: 04.02.2013 22:19, Pauli Virtanen kirjoitti: > 04.02.2013 22:11, Nils Wagner kirjoitti: > [clip: patch] > > M = int(M) > > on top of the routine would do the same thing. Ok, I'm wrong --- this is due to `type(4/2) is float`. The division operations should be replaced by // -- Pauli Virtanen From warren.weckesser at gmail.com Mon Feb 4 15:47:39 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 4 Feb 2013 15:47:39 -0500 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: Thanks Nils. I took a look at the patch. It might be simpler to just put `M = int(M)` at the beginning of the function, and (now that the latest version of the file in the master branch imports division from __future__), change any divisions that look like they expected integer arguments from `/` to `//`. Could you explain the problem that motivated you to create the patch? It might help provide a useful unit test. Warren On Mon, Feb 4, 2013 at 3:11 PM, Nils Wagner wrote: > > > _______________________________________________ > 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 nils106 at googlemail.com Mon Feb 4 15:53:00 2013 From: nils106 at googlemail.com (Nils Wagner) Date: Mon, 4 Feb 2013 20:53:00 +0000 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: Running scipy.test() results in several errors of the form ERROR: iterating a structure 2 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/ndimage/tests/test_ndimage.py", line 3063, in test_iterate_structure02 out = ndimage.iterate_structure(struct, 2) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/ndimage/morphology.py", line 118, in iterate_structure out[slc] = structure != 0 DeprecationWarning: non-integer slice parameter. In a future numpy release, this will raise an error. ====================================================================== ERROR: test_cases (test_solvers.TestSolveDiscreteARE) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 129, in test_cases self.check_case(case[0], case[1], case[2], case[3]) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 123, in check_case x = solve_discrete_are(a, b, q, r) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/_solvers.py", line 272, in solve_discrete_are u11 = u[0:m/2, 0:n/2] DeprecationWarning: non-integer slice parameter. In a future numpy release, this will raise an error. Cheers Nils On Mon, Feb 4, 2013 at 8:47 PM, Warren Weckesser wrote: > Thanks Nils. I took a look at the patch. It might be simpler to just put > `M = int(M)` at the beginning of the function, and (now that the latest > version of the file in the master branch imports division from > __future__), change any divisions that look like they expected integer > arguments from `/` to `//`. > > Could you explain the problem that motivated you to create the patch? It > might help provide a useful unit test. > > Warren > > > > On Mon, Feb 4, 2013 at 3:11 PM, Nils Wagner wrote: > >> >> >> _______________________________________________ >> 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 pav at iki.fi Mon Feb 4 16:38:50 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 04 Feb 2013 23:38:50 +0200 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: 04.02.2013 22:53, Nils Wagner kirjoitti: > scipy.test() > > results in several errors of the form [clip] Indeed, this is a consequence of from __future__ import division The warnings indicate that this state of matters existed on Python 3 (2to3 doesn't change / to //) since Scipy 0.9.0, but nobody noticed... Steps to catch 'em - Recent Numpy git maste - scipy.test("not slow", verbose=2, raise_warnings="develop") -- Pauli Virtanen From nils106 at googlemail.com Tue Feb 5 14:11:28 2013 From: nils106 at googlemail.com (Nils Wagner) Date: Tue, 5 Feb 2013 19:11:28 +0000 Subject: [SciPy-Dev] Patch for scipy/signal/windows.py In-Reply-To: References: Message-ID: ====================================================================== ERROR: test_cases (test_solvers.TestSolveDiscreteARE) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 129, in test_cases self.check_case(case[0], case[1], case[2], case[3]) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/tests/test_solvers.py", line 123, in check_case x = solve_discrete_are(a, b, q, r) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/linalg/_solvers.py", line 272, in solve_discrete_are u11 = u[0:m/2, 0:n/2] DeprecationWarning: non-integer slice parameter. In a future numpy release, this will raise an error. ====================================================================== ERROR: test_real_valid_mode (test_signaltools.TestFFTConvolve) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/signal/tests/test_signaltools.py", line 168, in test_real_valid_mode c = signal.fftconvolve(a,b,'valid') File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/signal/signaltools.py", line 164, in fftconvolve return _centered(ret, abs(s2 - s1) + 1) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/signal/signaltools.py", line 133, in _centered return arr[tuple(myslice)] DeprecationWarning: non-integer slice parameter. In a future numpy release, this will raise an error. ====================================================================== ERROR: iterating a structure 3 ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/ndimage/tests/test_ndimage.py", line 3075, in test_iterate_structure03 out = ndimage.iterate_structure(struct, 2, 1) File "/home/nwagner/local/lib64/python2.7/site-packages/scipy/ndimage/morphology.py", line 118, in iterate_structure out[slc] = structure != 0 DeprecationWarning: non-integer slice parameter. In a future numpy release, this will raise an error. On Mon, Feb 4, 2013 at 9:38 PM, Pauli Virtanen wrote: > 04.02.2013 22:53, Nils Wagner kirjoitti: > > scipy.test() > > > > results in several errors of the form > [clip] > > Indeed, this is a consequence of > > from __future__ import division > > The warnings indicate that this state of matters existed on Python 3 > (2to3 doesn't change / to //) since Scipy 0.9.0, but nobody noticed... > > Steps to catch 'em > > - Recent Numpy git maste > > - scipy.test("not slow", verbose=2, raise_warnings="develop") > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Wed Feb 6 00:58:26 2013 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 5 Feb 2013 21:58:26 -0800 Subject: [SciPy-Dev] Fwd: Re: [Numpy-discussion] Dealing with the mode argument in qr. In-Reply-To: References: Message-ID: Dear scipy-dev, What do you are think of these names for the qr modes? It would be nice if scipy and numpy could get these aligned (right now they have different defaults and multiple modes with the same name but different semantics...). -n ---------- Forwarded message ---------- From: "Charles R Harris" Date: 5 Feb 2013 21:13 Subject: Re: [Numpy-discussion] Dealing with the mode argument in qr. To: "numpy-discussion" Cc: On Tue, Feb 5, 2013 at 2:23 PM, Charles R Harris wrote: > Hi All, > > This post is to bring the discussion of PR #2965to the attention of the list. There are at least three issues in play here. > > 1) The PR adds modes 'big' and 'thin' to the current modes 'full', 'r', > 'economic' for qr factorization. The problem is that the current 'full' is > actually 'thin' and 'big' should be 'full'. The solution here was to raise > a FutureWarning on use of 'full', alias it to 'thin' for the time being, > and at some distant time change 'full' to alias 'big'. > > 2) The 'economic' mode serves little purpose. I propose to deprecate it > and add a 'qrf' mode instead, corresponding to scipy's 'raw' mode. We can't > use 'raw' itself as traditionally the mode may be specified using the first > letter only and that leads to a conflict with 'r'. > > 3) As suggested in 2, the use of single letter abbreviations can constrain > the options in choosing mode names and they are not as informative as the > full name. A possibility here is to deprecate the use of the abbreviations > in favor of the full names. > > A longer term problem is the divergence between the numpy and scipy > versions of qr. The divergence is enough that I don't see any easy way to > come to a common interface, but that is something that would be desirable > if possible. > > Thoughts? > > bfroehle has suggested the names 1. complete: Q is a M-by-M matrix, i.e. a complete orthogonal basis. 2. reduced: Q is a M-by-K matrix. 3. r: Only return R 4. raw: Return Householder reflectors Q and TAU Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.daniel.br at gmail.com Wed Feb 6 17:48:13 2013 From: smith.daniel.br at gmail.com (Daniel Smith) Date: Wed, 6 Feb 2013 17:48:13 -0500 Subject: [SciPy-Dev] Expanding Scipy's KDE functionality In-Reply-To: References: Message-ID: Hello, I've updated the github repository with some new code: https://github.com/Daniel-B-Smith/KDE-for-SciPy I added a data generating process class and subclassed it with the examples from the Botev, Grotowski, and Kroese paper. I could have subclassed scipy's rv_continuous, but I thought that class was a lot bigger and bulkier than we need. The script test_plots.py produces a bunch of pdf's that show how well the KDE estimate aligns with the probability distribution function. Next, I will write some code to compare the square error of the new method with the square error from SciPy's current implementation. Finally, I am still planning on writing some Cython code to calculate the derivative using a minimal number of Fourier basis vectors. Thanks, Daniel From smith.daniel.br at gmail.com Thu Feb 7 11:22:14 2013 From: smith.daniel.br at gmail.com (Daniel Smith) Date: Thu, 7 Feb 2013 11:22:14 -0500 Subject: [SciPy-Dev] Pull Request Message-ID: Hello, I fixed the behavior for ticket #1075 and added fancy slicing to lil_matrix. I will probably do the same for CSR and CSC sparse matrices in the near future. The pull request is here: https://github.com/scipy/scipy/pull/425 Thanks, Daniel From rmcgibbo at gmail.com Fri Feb 8 02:46:11 2013 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Thu, 7 Feb 2013 23:46:11 -0800 Subject: [SciPy-Dev] The New Scipy Central Home page In-Reply-To: References: <51093EC5.6030809@hilboll.de> Message-ID: <58681FD2-8DC0-42E8-869F-C3457315BEA7@gmail.com> > Any updates? > > Please let me know how it is? what could be added? (Firstly whether you like it to put as scipy-central home page) > I'm a big fan! Personally, I think the default bootstrap CSS is a bit overused, but I'm sure the color of the header bar could be changed very easily. As you continue to add more of the features/content from scipy-central.org, I think it will only get better! It'll be great to see this as it matures. -Robert From kroeger.niklas at gmail.com Fri Feb 8 08:00:12 2013 From: kroeger.niklas at gmail.com (=?ISO-8859-1?Q?Niklas_Kr=F6ger?=) Date: Fri, 8 Feb 2013 14:00:12 +0100 Subject: [SciPy-Dev] New function in scipy.signal.lti to generate Nyquist plot Message-ID: Hi Scipy-Dev team, I am new to the development of open source software, so please don't be too harsh if I make/made any major mistakes. I recently forked the scipy main branch on github and added a function in the "signal" submodule. I have been using it during this semester in one of my classes and I missed the ability to generate a Nyquist plot, so I implemented it myself and figured others might find this useful too. Eagerly I quickly coded something and created a pull request on github where I then learned, that the decision about adding new functionality is made on this mailing list. If you want to take a look at the code you can find my commits in this pull request: https://github.com/scipy/scipy/pull/418 Like I said, I am entirely new to all of this and just hope to provide something useful to this great project I enjoy using. Best regards, -Niklas Kr?ger. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.haessig at crans.org Fri Feb 8 09:16:55 2013 From: pierre.haessig at crans.org (Pierre Haessig) Date: Fri, 08 Feb 2013 15:16:55 +0100 Subject: [SciPy-Dev] New function in scipy.signal.lti to generate Nyquist plot In-Reply-To: References: Message-ID: <511508D7.5090201@crans.org> Hi Niklas, Le 08/02/2013 14:00, Niklas Kr?ger a ?crit : > I am new to the development of open source software, so please don't > be too harsh if I make/made any major mistakes. > I recently forked the scipy main branch on github and added a function > in the "signal" submodule. I have been using it during this semester > in one of my classes and I missed the ability to generate a Nyquist > plot, so I implemented it myself and figured others might find this > useful too. I think your PR is a valuable addition to scipy.signal. I've a few comments though but I should just state first that I'm not a regular user of scipy.signal so that my comments may not be entirely appropriate. Main comment is about changing the name "nyquist". I think there are two separate things in your PR: one is the ability to evaluate the frequency response over some frequency grid. A separate this is plotting a Nyquist diagram, i.e. plotting this frequency response in the complex plane. Plotting is not (and I guess should not) be implemented in the function you propose. Therefore, I think the function you propose (which is a great complement to the preexisting bode function by the way) should be named more something like "freqresp". I just did a bit of homework in matlab documentation and that's how I got this name "freqresp": http://www.mathworks.fr/fr/help/control/ref/freqresp.html Of course we could use a slight variation of this name, but I've no better idea. This being said, I like your docstring. In particular, plotting a Nyquist diagram in the docstring a is very nice and short usecase. Only I would change the first line """Calculate nyquist plot of a continuous-time system.""" to """Calculate the frequency response of a continuous-time system over a grid""" Finally, I think the default value for the grid size "n" should be set to the same default as bode(..). I've no guidelines on how to choose this number though. Bode is 100, you propose 10^4. What about 10^3 ;-) ? best, Pierre PS : within your PR, you may correct a tiny preexisting docstring glitch in _default_response_frequencies(A, n) (line 617). I think n : int The number of time samples to generate should read instead n : int The number of *frequency* samples to generate -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From kroeger.niklas at gmail.com Fri Feb 8 10:13:28 2013 From: kroeger.niklas at gmail.com (=?ISO-8859-1?Q?Niklas_Kr=F6ger?=) Date: Fri, 8 Feb 2013 16:13:28 +0100 Subject: [SciPy-Dev] New function in scipy.signal.lti to generate Nyquist plot In-Reply-To: <511508D7.5090201@crans.org> References: <511508D7.5090201@crans.org> Message-ID: Hi Pierre, I think you are right. I chose the name because of the nyquist function from octave, which I used before I had this python version coded. However since my function doesn't generate the plot but just the values, you are right. Regarding the grid size "n": I was unsure of that value and I just chose 10^4 based on the plots I generated with the function. For simple functions like the example this number is very high. However I ran into some functions which could not be plotted precisely because of too few generated values. I will append an example of what I mean (only showing the plot for w->+inf to make the plot less crowded). [image: Inline-Bild 1] [image: Inline-Bild 2] As you can see n=10^4 is still not enough to make a really nice and round plot. But in my opinion it's close enough to see the actual plot. Of course you could argue, that anyone who generates plots of such complex transfer functions, could just set the value of n up himself. For me it's not important what default n is set to, 10^4 was just the first value that seemed to fit my needs. Anyway, I will change the name of the function as you said and adjust the docstring. Best regards, -Niklas. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 30138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 32481 bytes Desc: not available URL: From ralf.gommers at gmail.com Sun Feb 10 17:45:03 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 10 Feb 2013 23:45:03 +0100 Subject: [SciPy-Dev] 0.12.0 release schedule In-Reply-To: References: Message-ID: On Fri, Jan 25, 2013 at 11:14 PM, Ralf Gommers wrote: > Hi all, > > It's time to start thinking about the 0.12.0 release. There's a number of > cool new features, and a huge amount of maintenance work (thanks in large > part to Pauli). > > I don't think there's any real blockers at the moment. We should merge as > many open PRs as possible though. Does anyone still have important fixes or > other things that should go in? > > I propose the following release schedule: > Feb 9 : beta 1 > Feb 23 : rc 1 > Mar 9 : rc 2 (if needed) > Mar 16 : final release > Hi, I ran out of time for this weekend unfortunately. New target is to branch 0.12.x by Thursday. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla at molden.no Wed Feb 13 08:52:35 2013 From: sturla at molden.no (Sturla Molden) Date: Wed, 13 Feb 2013 14:52:35 +0100 Subject: [SciPy-Dev] flapack and the GIL In-Reply-To: References: <510F9A83.7000302@molden.no> Message-ID: <511B9AA3.3050207@molden.no> On 04.02.2013 19:28, Pauli Virtanen wrote: > AFAIK, *all* of Lapack is threadsafe --- there are no SAVE or COMMON > statements. The same is probably true for any modified LAPACK routines > in MKL, Accelerate and the ilk. Do you mind if I put a 'threadsafe' in all of them? :) If one LAPACK method is tread-safe there is no reason to assume the others are not. Sturla From orion at cora.nwra.com Wed Feb 13 19:06:09 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 13 Feb 2013 17:06:09 -0700 Subject: [SciPy-Dev] [Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion In-Reply-To: References: <20120920210154.D759123187@bastion01.phx2.fedoraproject.org> <505B9109.60607@cora.nwra.com> Message-ID: <511C2A71.1090502@cora.nwra.com> On 09/21/2012 11:41 AM, Ond?ej ?ert?k wrote: > Hi Orion, > > On Thu, Sep 20, 2012 at 2:56 PM, Orion Poplawski wrote: >> This is a plea for some help. We've been having trouble getting scipy to >> pass all of the tests in the Fedora 18 build with python 3.3 (although it >> seems to build okay in Fedora 19). Below are the logs of the build. There >> appears to be some kind of memory corruption that manifests itself a little >> differently on 32-bit vs. 64-bit. I really have no idea myself how to >> pursue debugging this, though I'm happy to provide any more needed >> information. > > Thanks for testing the latest beta2 release. > >> Task 4509077 on buildvm-35.phx2.fedoraproject.org >> Task Type: buildArch (scipy-0.11.0-0.1.rc2.fc18.src.rpm, i686) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=4509077&name=build.log > > This link has the following stacktrace: > > /lib/libpython3.3m.so.1.0(PyMem_Free+0x1c)[0xbf044c] > /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0x4d52b)[0x42252b] > /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcb7c5)[0x4a07c5] > /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcbc5e)[0x4a0c5e] > > Which indeed looks like in NumPy. Would you be able to obtain full stacktrace? > > There has certainly been segfaults in Python 3.3 with NumPy, but we've > fixed all that we could reproduce. That doesn't mean there couldn't be > more. If you could nail it down a little bit more, that would be > great. I'll help once I can reproduce it somehow. > > Ondrej > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > Trying to get back to this as we still see it with numpy 1.7.0 and scipy 0.11. I'm seeing a segfault in malloc_consolidate(), which seems like would only occur if there were problems earlier, so I'm not sure a stack trace is all that useful. Starting program: /usr/bin/python3 /export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/tests/test_decomp.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". .............. Program received signal SIGSEGV, Segmentation fault. 0x0000003d8d67bdad in malloc_consolidate (av=av at entry=0x3d8d9b1740 ) at malloc.c:4151 4151 unlink(av, nextchunk, bck, fwd); Here's some: #0 0x0000003d8d67bdad in malloc_consolidate (av=av at entry=0x3d8d9b1740 ) at malloc.c:4151 #1 0x0000003d8d67d09e in _int_malloc (av=0x3d8d9b1740 , bytes=) at malloc.c:3422 #2 0x0000003d8d67f443 in __GI___libc_malloc (bytes=2632) at malloc.c:2862 #3 0x00007ffff121816c in PyArray_IterNew (obj=) at numpy/core/src/multiarray/iterators.c:385 #4 0x00007ffff1218201 in PyArray_IterAllButAxis (obj=obj at entry= , inaxis=inaxis at entry=0x7fffffff873c) at numpy/core/src/multiarray/iterators.c:488 #5 0x00007ffff1257970 in _new_argsort (which=NPY_QUICKSORT, axis=0, op=0xe02fd0) at numpy/core/src/multiarray/item_selection.c:815 #6 PyArray_ArgSort (op=op at entry=0xe02fd0, axis=0, which=NPY_QUICKSORT) at numpy/core/src/multiarray/item_selection.c:1104 #7 0x00007ffff125873a in array_argsort (self=0xe02fd0, args=, kwds=) at numpy/core/src/multiarray/methods.c:1213 #8 0x0000003b74d0cc8e in call_function (oparg=, pp_stack=0x7fffffff8998) at /usr/src/debug/Python-3.3.0/Python/ceval.c:4091 #9 PyEval_EvalFrameEx (f=f at entry= Frame 0xd3ecb0, for file /usr/lib64/python3.3/site-packages/numpy/core/fromnumeric.py, line 681, in argsort (a=, axis=-1, kind='quicksort', order=None, argsort=), throwflag=throwflag at entry=0) at /usr/src/debug/Python-3.3.0/Python/ceval.c:2703 #10 0x0000003b74d0de63 in PyEval_EvalCodeEx (_co=_co at entry=, globals=, locals=locals at entry=0x0, args=, argcount=argcount at entry=1, kws=0xe23ab8, kwcount=kwcount at entry=0, defs=0x7ffff1a965b8, defcount=3, kwdefs=0x0, closure=0x0) at /usr/src/debug/Python-3.3.0/Python/ceval.c:3462 #11 0x0000003b74d0c707 in fast_function (nk=0, na=1, n=, pp_stack= 0x7fffffff8c88, func=) at /usr/src/debug/Python-3.3.0/Python/ceval.c:4189 #12 call_function (oparg=, pp_stack=0x7fffffff8c88) at /usr/src/debug/Python-3.3.0/Python/ceval.c:4112 (gdb) up 3 #3 0x00007ffff121816c in PyArray_IterNew (obj=) at numpy/core/src/multiarray/iterators.c:385 385 it = (PyArrayIterObject *)PyArray_malloc(sizeof(PyArrayIterObject)); (gdb) print *obj $4 = {ob_refcnt = 5, ob_type = 0x7ffff14c6900 } (gdb) list 380 PyErr_BadInternalCall(); 381 return NULL; 382 } 383 ao = (PyArrayObject *)obj; 384 385 it = (PyArrayIterObject *)PyArray_malloc(sizeof(PyArrayIterObject)); 386 PyObject_Init((PyObject *)it, &PyArrayIter_Type); 387 /* it = PyObject_New(PyArrayIterObject, &PyArrayIter_Type);*/ 388 if (it == NULL) { 389 return NULL; valgrind reports problems like: ==10886== Invalid write of size 8 ==10886== at 0x3D9C5CB576: dlacpy_ (in /usr/lib64/atlas/liblapack.so.3.0) ==10886== by 0x3D9C6481F7: dsbevx_ (in /usr/lib64/atlas/liblapack.so.3.0) ==10886== by 0x115D8212: ??? (in /export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so) ==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082) ==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311) ==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74C8547F: function_call (funcobject.c:633) ==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082) ==10886== by 0x3B74D05F7F: PyEval_EvalFrameEx (ceval.c:4406) ==10886== Address 0xbbc8cd0 is 0 bytes after a block of size 80 alloc'd ==10886== at 0x4A0883C: malloc (vg_replace_malloc.c:270) ==10886== by 0xE8A103A: PyDataMem_NEW (multiarraymodule.c:3492) ==10886== by 0xE8C3F74: PyArray_NewFromDescr (ctors.c:970) ==10886== by 0x115E032B: array_from_pyobj (in /export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so) ==10886== by 0x115D7F5E: ??? (in /export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so) ==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082) ==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311) ==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74C8547F: function_call (funcobject.c:633) ==10886== ==10886== Invalid read of size 8 ==10886== at 0x3D9C61DAD5: dlasr_ (in /usr/lib64/atlas/liblapack.so.3.0) ==10886== by 0x3D9C663092: dsteqr_ (in /usr/lib64/atlas/liblapack.so.3.0) ==10886== by 0x3D9C648290: dsbevx_ (in /usr/lib64/atlas/liblapack.so.3.0) ==10886== by 0x115D8212: ??? (in /export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so) ==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082) ==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311) ==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189) ==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462) ==10886== by 0x3B74C8547F: function_call (funcobject.c:633) ==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082) ==10886== Address 0xbbc8dc0 is not stack'd, malloc'd or (recently) free'd So perhaps an atlas issue, or the way scipy/numpy calls it. I'll try to look into it more. Suggestions welcome. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From largeddysimulation at gmail.com Thu Feb 14 09:05:48 2013 From: largeddysimulation at gmail.com (Nikola Mirkov) Date: Thu, 14 Feb 2013 15:05:48 +0100 Subject: [SciPy-Dev] spectral methods in Python Message-ID: Hello guys! I'm new to this list. I'm very interested in spectral methods, and for that purpose I use Python, numpy and scipy a lot. Recently I have made an extension module for Python, consisting of some 85 functions, useful for implementation of spectral methods. It is based on D.Funaro's Fortran library *splib*. Therefore I call my project *pysplib*. Here's the link to my github repo: https://github.com/nikola-m/pysplib The naming scheme of functions is very simple and economic (concieved by D.Funaro). It uses three pairs of letters denoting 1) what item we want to return (nodes, derivative matrices, expansion coefficients,function values,etc.), 2) which orthogonal functions we operate on (Chebyshev,Legendre,Jacobi,Hermite), and 3) what set of points we use (Gauss,Gaus-Lobatto,Gauss-radau). So we have: zechgl - ZEros (nodes) of CHebyshev polynomials at Gauss-Lobatto points or colega - COefficients, LEgendre, GAuss etc. There's a very comprehensive documentation in pdf, covering theoretical aspect of these functions. I would like to get some feedback,so send an email if you have any comments or questions. If it proves useful for scipy as a community, you may adopt it, and maybe include in some module. Regards! -- Nikola Mirkov Research Assistant Institute of Nuclear Sciences "Vinca" Laboratory for Thermal Engineering and Energy Belgrade, Serbia -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu Feb 14 13:45:00 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 14 Feb 2013 11:45:00 -0700 Subject: [SciPy-Dev] 0.12.0 release schedule In-Reply-To: References: Message-ID: <511D30AC.30105@cora.nwra.com> On 02/10/2013 03:45 PM, Ralf Gommers wrote: > > > > On Fri, Jan 25, 2013 at 11:14 PM, Ralf Gommers > wrote: > > Hi all, > > It's time to start thinking about the 0.12.0 release. There's a number of > cool new features, and a huge amount of maintenance work (thanks in large > part to Pauli). > > I don't think there's any real blockers at the moment. We should merge as > many open PRs as possible though. Does anyone still have important fixes > or other things that should go in? > > I propose the following release schedule: > Feb 9 : beta 1 > Feb 23 : rc 1 > Mar 9 : rc 2 (if needed) > Mar 16 : final release > > > Hi, I ran out of time for this weekend unfortunately. New target is to branch > 0.12.x by Thursday. > > Ralf Build with python3.3 on Fedora 18 fails for me. Filed http://projects.scipy.org/scipy/ticket/1843 This would be a blocker for the Fedora scipy package as we've been shipping python3 versions for a while. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From ralf.gommers at gmail.com Thu Feb 14 15:52:24 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Thu, 14 Feb 2013 21:52:24 +0100 Subject: [SciPy-Dev] 0.12.0 release schedule In-Reply-To: <511D30AC.30105@cora.nwra.com> References: <511D30AC.30105@cora.nwra.com> Message-ID: On Thu, Feb 14, 2013 at 7:45 PM, Orion Poplawski wrote: > On 02/10/2013 03:45 PM, Ralf Gommers wrote: > > > > > > > > On Fri, Jan 25, 2013 at 11:14 PM, Ralf Gommers > > wrote: > > > > Hi all, > > > > It's time to start thinking about the 0.12.0 release. There's a > number of > > cool new features, and a huge amount of maintenance work (thanks in > large > > part to Pauli). > > > > I don't think there's any real blockers at the moment. We should > merge as > > many open PRs as possible though. Does anyone still have important > fixes > > or other things that should go in? > > > > I propose the following release schedule: > > Feb 9 : beta 1 > > Feb 23 : rc 1 > > Mar 9 : rc 2 (if needed) > > Mar 16 : final release > > > > > > Hi, I ran out of time for this weekend unfortunately. New target is to > branch > > 0.12.x by Thursday. > > > > Ralf > > Build with python3.3 on Fedora 18 fails for me. Filed > http://projects.scipy.org/scipy/ticket/1843 > > This would be a blocker for the Fedora scipy package as we've been shipping > python3 versions for a while. > Should be fixed before the first RC. The 0.12.x branch has been created. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Fri Feb 15 03:24:31 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 15 Feb 2013 13:54:31 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally Message-ID: Hi there, Finally, I tried to make a Scipy Central design (home page) looking close to scipy.org Please take a look and let me know how it is.. what could be changed and all. http://ksurya.github.com/scipy-central-design/home.html Also: Few changes/ new features might be required like changing font size, color, background color etc.. Please do comment on them too! The rest of the pages would be looking very similar to this.. (Note: this was the previous version http://ksurya.github.com/scipycentral/.. Looks a lot like search engine and probably won't work for this site). Looking for your comments.. is this has any chance of merging into main-stream (of course with some small changes) -- Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Fri Feb 15 03:25:21 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 15 Feb 2013 13:55:21 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally Message-ID: Hi there, Finally, I tried to make a Scipy Central design (home page) looking close to scipy.org Please take a look and let me know how it is.. what could be changed and all. http://ksurya.github.com/scipy-central-design/home.html Also: Few changes/ new features might be required like changing font size, color, background color etc.. Please do comment on them too! The rest of the pages would be looking very similar to this.. (Note: this was the previous version http://ksurya.github.com/scipycentral/ .. Looks a lot like search engine and probably won't work for this site). Looking for your comments.. is this has any chance of merging into main-stream (of course with some small changes) -- Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Fri Feb 15 07:41:34 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 15 Feb 2013 07:41:34 -0500 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Fri, Feb 15, 2013 at 3:24 AM, Surya Kasturi wrote: > Hi there, > > Finally, I tried to make a Scipy Central design (home page) looking close to > scipy.org > > Please take a look and let me know how it is.. what could be changed and > all. > > http://ksurya.github.com/scipy-central-design/home.html > > Also: Few changes/ new features might be required like changing font size, > color, background color etc.. > > Please do comment on them too! > > The rest of the pages would be looking very similar to this.. > > (Note: this was the previous version http://ksurya.github.com/scipycentral/ > .. Looks a lot like search engine and probably won't work for this site). > > > Looking for your comments.. is this has any chance of merging into > main-stream (of course with some small changes) some quick impressions: I think the layout is pretty usable, I like the tabs for recently changed and most visited (maybe "most visited" could be replaced by "most popular" or "most downloaded" if we want to use download statistic instead of visits, which might include robots as Pauli mentioned most downloaded won't work for packages that have a link instead of code to download) I have problems reading low contrast headers and tags (blue on blue or grey on grey) I don't like blue borders much anymore, they give it a bit of old-fashioned look. Josef > > > -- Surya > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From suryak at ieee.org Fri Feb 15 08:04:01 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 15 Feb 2013 18:34:01 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Fri, Feb 15, 2013 at 6:11 PM, wrote: > On Fri, Feb 15, 2013 at 3:24 AM, Surya Kasturi wrote: > > Hi there, > > > > Finally, I tried to make a Scipy Central design (home page) looking > close to > > scipy.org > > > > Please take a look and let me know how it is.. what could be changed and > > all. > > > > http://ksurya.github.com/scipy-central-design/home.html > > > > Also: Few changes/ new features might be required like changing font > size, > > color, background color etc.. > > > > Please do comment on them too! > > > > The rest of the pages would be looking very similar to this.. > > > > (Note: this was the previous version > http://ksurya.github.com/scipycentral/ > > .. Looks a lot like search engine and probably won't work for this site). > > > > > > Looking for your comments.. is this has any chance of merging into > > main-stream (of course with some small changes) > > some quick impressions: > > I think the layout is pretty usable, I like the tabs for recently > changed and most visited I like them too (maybe "most visited" could be replaced by "most popular" or "most > downloaded" if we want to use download statistic instead of visits, > which might include robots as Pauli mentioned > most downloaded won't work for packages that have a link instead of > code to download) > > We can change it. Not an issue! > I have problems reading low contrast headers and tags (blue on blue or > grey on grey) > > Well, I was actually not making huge changes in the "look".. This page is more or less same like scipy.github.com (and few parts of scipy.org). I used those sites as blue-print because.. and don't really want to make a website that doesn't look similar to others!. I guess this blue is scipy's identity! > I don't like blue borders much anymore, they give it a bit of > old-fashioned look. > > Josef > > > > > > > -- Surya > > > > _______________________________________________ > > 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 > probably, we can even use background patterns (http://subtlepatterns.com/), make the background little less dark.. what do you say? We could use brown color as base for website.. as in (scipy.github.com).. but .. scipy.org is totally blue. what do you say? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hodge at stsci.edu Fri Feb 15 08:40:17 2013 From: hodge at stsci.edu (Phil Hodge) Date: Fri, 15 Feb 2013 08:40:17 -0500 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: <511E3AC1.8080201@stsci.edu> On 02/15/2013 07:41 AM, josef.pktd at gmail.com wrote: > I have problems reading low contrast headers and tags (blue on blue or > grey on grey) Grey type is supposed to mean that the item is "greyed out." There's really no good reason to use light type (of any color) for text that someone is expected to read. (This is one of my pet peeves, in case that wasn't obvious.) Phil From lists at hilboll.de Fri Feb 15 08:47:18 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Fri, 15 Feb 2013 14:47:18 +0100 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: <511E3C66.1070805@hilboll.de> > Finally, I tried to make a Scipy Central design (home page) looking > close to scipy.org > > Please take a look and let me know how it is.. what could be changed and > all. > > http://ksurya.github.com/scipy-central-design/home.html > > Also: Few changes/ new features might be required like changing font > size, color, background color etc.. > > Please do comment on them too! > > The rest of the pages would be looking very similar to this.. > > (Note: this was the previous > version http://ksurya.github.com/scipycentral/ .. Looks a lot like > search engine and probably won't work for this site). > > > Looking for your comments.. is this has any chance of merging into > main-stream (of course with some small changes) Nice work, we're going down the right path, I think. Just very quick comments: I also like the tabbed content in the center. The fonts in the header look ugly on my machine. I'm also +1 against grey fonts in the header. I'd like to see a tabcloud somewhere (either in the sidebar, or in a third tab). The 'new' SciPy-Central logo should be used. How do the tabs behave without Javascript? How on mobile devices/small screens? A. From suryak at ieee.org Fri Feb 15 09:57:49 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 15 Feb 2013 20:27:49 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: <511E3AC1.8080201@stsci.edu> References: <511E3AC1.8080201@stsci.edu> Message-ID: On Fri, Feb 15, 2013 at 7:10 PM, Phil Hodge wrote: > On 02/15/2013 07:41 AM, josef.pktd at gmail.com wrote: > > I have problems reading low contrast headers and tags (blue on blue or > > grey on grey) > > Grey type is supposed to mean that the item is "greyed out." There's > really no good reason to use light type (of any color) for text that > someone is expected to read. (This is one of my pet peeves, in case > that wasn't obvious.) > You mean Grey.. on "right side bar" heading? That was a default color.. (point noted). > > Phil > _______________________________________________ > 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 fperez.net at gmail.com Thu Feb 14 17:56:22 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 14 Feb 2013 14:56:22 -0800 Subject: [SciPy-Dev] Python trademark in legal trouble in Europe, please help Message-ID: Hi all, please do NOT respond to this thread or to me directly. This is strictly to spread this message as widely as possible, so that anyone who receives it and can act on it does so. Needless to say, do forward this to anyone you think might be in a position to take useful action. The Python trademark is in serious risk across Europe due to the actions of a UK-based IP troll. If you operate in Europe, please help the Python Software Foundation gather evidence in the legal battle to protect the Python trademark across the EU. You can find the official blog post from the PSF with instructions on how to help here: http://pyfound.blogspot.com/2013/02/python-trademark-at-risk-in-europe-we.html and this thread on Hacker News is being monitored by the PSF Chairman Van Lindberg in case you want to ask the team directly any questions: http://news.ycombinator.com/item?id=5221093 Cheers, f From hodge at stsci.edu Fri Feb 15 11:07:09 2013 From: hodge at stsci.edu (Phil Hodge) Date: Fri, 15 Feb 2013 11:07:09 -0500 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: <511E3AC1.8080201@stsci.edu> Message-ID: <511E5D2D.20606@stsci.edu> On 02/15/2013 09:57 AM, Surya Kasturi wrote: > You mean Grey.. on "right side bar" heading? That was a default > color.. (point noted). I meant anywhere, but in this case I noticed it in the search bar ("Search code snippets, modules, links here...") and the headings on the right side, yes. Otherwise, I do like the layout. Thanks for all your work on this! Phil From ralf.gommers at gmail.com Sat Feb 16 07:34:04 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 13:34:04 +0100 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: > Hi there, > > Finally, I tried to make a Scipy Central design (home page) looking close > to scipy.org > > Please take a look and let me know how it is.. what could be changed and > all. > > http://ksurya.github.com/scipy-central-design/home.html > > Also: Few changes/ new features might be required like changing font size, > color, background color etc.. > > Please do comment on them too! > > The rest of the pages would be looking very similar to this.. > > (Note: this was the previous version > http://ksurya.github.com/scipycentral/ .. Looks a lot like search engine > and probably won't work for this site). > > > Looking for your comments.. is this has any chance of merging into > main-stream (of course with some small changes) > I think this can certainly be merged. We should however first pick up the scipy-central code, domain names, etc. that were offered by Kevin Dunn (the original author) for transfer to the community last year ( http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) I would propose to transfer some of the domain names to NumFOCUS, and put the main scipy-central repo under github.com/scipy. I can take care of that, if everyone agrees. Then we do need to move the site to a new server and do some maintenance when needed. Is there someone who is willing to help with that? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Sat Feb 16 08:19:49 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 16 Feb 2013 18:49:49 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: > > > > On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: > >> Hi there, >> >> Finally, I tried to make a Scipy Central design (home page) looking close >> to scipy.org >> >> Please take a look and let me know how it is.. what could be changed and >> all. >> >> http://ksurya.github.com/scipy-central-design/home.html >> >> Also: Few changes/ new features might be required like changing font >> size, color, background color etc.. >> >> Please do comment on them too! >> >> The rest of the pages would be looking very similar to this.. >> >> (Note: this was the previous version >> http://ksurya.github.com/scipycentral/ .. Looks a lot like search engine >> and probably won't work for this site). >> >> >> Looking for your comments.. is this has any chance of merging into >> main-stream (of course with some small changes) >> > > I think this can certainly be merged. We should however first pick up the > scipy-central code, domain names, etc. that were offered by Kevin Dunn (the > original author) for transfer to the community last year ( > http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) > > I would propose to transfer some of the domain names to NumFOCUS, and put > the main scipy-central repo under github.com/scipy. I can take care of > that, if everyone agrees. Then we do need to move the site to a new server > and do some maintenance when needed. Is there someone who is willing to > help with that? > *Myself.* > > > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > Actually I just want to know one thing.. is the "blue" of scipy.org a kind of identity or symbol for the community/ site? Could we possibly use a different kind of blue? (just asking) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Feb 16 09:20:02 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 15:20:02 +0100 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 2:19 PM, Surya Kasturi wrote: > > > > On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: > >> >> >> >> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >> >>> Hi there, >>> >>> Finally, I tried to make a Scipy Central design (home page) looking >>> close to scipy.org >>> >>> Please take a look and let me know how it is.. what could be changed and >>> all. >>> >>> http://ksurya.github.com/scipy-central-design/home.html >>> >>> Also: Few changes/ new features might be required like changing font >>> size, color, background color etc.. >>> >>> Please do comment on them too! >>> >>> The rest of the pages would be looking very similar to this.. >>> >>> (Note: this was the previous version >>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>> engine and probably won't work for this site). >>> >>> >>> Looking for your comments.. is this has any chance of merging into >>> main-stream (of course with some small changes) >>> >> >> I think this can certainly be merged. We should however first pick up the >> scipy-central code, domain names, etc. that were offered by Kevin Dunn (the >> original author) for transfer to the community last year ( >> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >> >> I would propose to transfer some of the domain names to NumFOCUS, and put >> the main scipy-central repo under github.com/scipy. I can take care of >> that, if everyone agrees. Then we do need to move the site to a new server >> and do some maintenance when needed. Is there someone who is willing to >> help with that? >> > > *Myself.* > Awesome. > >> >> >> Ralf >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > Actually I just want to know one thing.. is the "blue" of scipy.org a > kind of identity or symbol for the community/ site? > I don't think so, the scipy.org site has just always used it but that may be simply due to a lack of design skills or manpower. > Could we possibly use a different kind of blue? (just asking) > Yes please! The current color has annoyed me for a long time. Anything that looks more modern would be an improvement. Doesn't even have to be blue imho. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.dunn at mcmaster.ca Sat Feb 16 09:23:06 2013 From: kevin.dunn at mcmaster.ca (Kevin Dunn) Date: Sat, 16 Feb 2013 09:23:06 -0500 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: > > > > On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: > >> >> >> >> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >> >>> Hi there, >>> >>> Finally, I tried to make a Scipy Central design (home page) looking >>> close to scipy.org >>> >>> Please take a look and let me know how it is.. what could be changed and >>> all. >>> >>> http://ksurya.github.com/scipy-central-design/home.html >>> >>> Also: Few changes/ new features might be required like changing font >>> size, color, background color etc.. >>> >>> Please do comment on them too! >>> >>> The rest of the pages would be looking very similar to this.. >>> >>> (Note: this was the previous version >>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>> engine and probably won't work for this site). >>> >>> >>> Looking for your comments.. is this has any chance of merging into >>> main-stream (of course with some small changes) >>> >> >> I think this can certainly be merged. We should however first pick up the >> scipy-central code, domain names, etc. that were offered by Kevin Dunn (the >> original author) for transfer to the community last year ( >> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >> >> I would propose to transfer some of the domain names to NumFOCUS, and put >> the main scipy-central repo under github.com/scipy. I can take care of >> that, if everyone agrees. Then we do need to move the site to a new server >> and do some maintenance when needed. Is there someone who is willing to >> help with that? >> > > *Myself.* > > >> >> >> Ralf >> >> >> Actually I just want to know one thing.. is the "blue" of scipy.org a > kind of identity or symbol for the community/ site? Could we possibly use a > different kind of blue? (just asking) > > Hi everyone, As Ralf mentioned above, and based on a previous message I wrote ( http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), the domains are absolutely available for transfer. Just let me know who to transfer to and when. This coming week is a good time frame for me to do this. I like the new look, thanks Surya, I'm glad you can continue on with it and improve the site. -- Kevin Dunn Dept. of Chemical Engineering McMaster University http://learnche.mcmaster.ca/contact-info -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Feb 16 10:19:40 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 16:19:40 +0100 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 3:23 PM, Kevin Dunn wrote: > > On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: > >> >> >> >> On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >>> >>>> Hi there, >>>> >>>> Finally, I tried to make a Scipy Central design (home page) looking >>>> close to scipy.org >>>> >>>> Please take a look and let me know how it is.. what could be changed >>>> and all. >>>> >>>> http://ksurya.github.com/scipy-central-design/home.html >>>> >>>> Also: Few changes/ new features might be required like changing font >>>> size, color, background color etc.. >>>> >>>> Please do comment on them too! >>>> >>>> The rest of the pages would be looking very similar to this.. >>>> >>>> (Note: this was the previous version >>>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>>> engine and probably won't work for this site). >>>> >>>> >>>> Looking for your comments.. is this has any chance of merging into >>>> main-stream (of course with some small changes) >>>> >>> >>> I think this can certainly be merged. We should however first pick up >>> the scipy-central code, domain names, etc. that were offered by Kevin Dunn >>> (the original author) for transfer to the community last year ( >>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >>> >>> I would propose to transfer some of the domain names to NumFOCUS, and >>> put the main scipy-central repo under github.com/scipy. I can take care >>> of that, if everyone agrees. Then we do need to move the site to a new >>> server and do some maintenance when needed. Is there someone who is willing >>> to help with that? >>> >> >> *Myself.* >> >> >>> >>> >>> Ralf >>> >>> >>> Actually I just want to know one thing.. is the "blue" of scipy.org a >> kind of identity or symbol for the community/ site? Could we possibly use a >> different kind of blue? (just asking) >> >> > Hi everyone, > > As Ralf mentioned above, and based on a previous message I wrote ( > http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), the > domains are absolutely available for transfer. > > Just let me know who to transfer to and when. This coming week is a good > time frame for me to do this. > Does it make sense to transfer these 4 domains, and let the other ones lapse? scipy-central.org scipy-central.com scipycentral.org scipycentral.com Ralf > I like the new look, thanks Surya, I'm glad you can continue on with it > and improve the site. > > -- > Kevin Dunn > Dept. of Chemical Engineering > McMaster University > http://learnche.mcmaster.ca/contact-info > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Feb 16 11:05:43 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 17:05:43 +0100 Subject: [SciPy-Dev] spectral methods in Python In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 3:05 PM, Nikola Mirkov wrote: > > Hello guys! I'm new to this list. > Hi, welcome. > > I'm very interested in spectral methods, and for that purpose I use > Python, numpy and scipy a lot. > > Recently I have made an extension module for Python, consisting of some 85 > functions, useful for implementation of spectral methods. > > It is based on D.Funaro's Fortran library *splib*. Therefore I call my > project *pysplib*. > > Here's the link to my github repo: > https://github.com/nikola-m/pysplib > > The naming scheme of functions is very simple and economic (concieved by > D.Funaro). It uses three pairs of letters denoting 1) what item we want to > return (nodes, derivative matrices, expansion coefficients,function > values,etc.), 2) which orthogonal functions we operate on > (Chebyshev,Legendre,Jacobi,Hermite), and 3) what set of points we use > (Gauss,Gaus-Lobatto,Gauss-radau). So we have: > > zechgl - ZEros (nodes) of CHebyshev polynomials at Gauss-Lobatto points > or > colega - COefficients, LEgendre, GAuss > etc. > > There's a very comprehensive documentation in pdf, covering theoretical > aspect of these functions. > Link: http://cdm.unimo.it/home/matematica/funaro.daniele/rout.htm > I would like to get some feedback,so send an email if you have any > comments or questions. > If it proves useful for scipy as a community, you may adopt it, and maybe > include in some module. > First observation: licensing seems problematic. The original code doesn't contain a license as far as I can see. Did you ask Prof. Funaro if he's OK with you redistributing his code under the GPL? Even if you did, GPL code is not OK for inclusion in SciPy, it needs to be BSD-compatible. The functionality sounds interesting though. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Sat Feb 16 11:22:32 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 16 Feb 2013 21:52:32 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 8:49 PM, Ralf Gommers wrote: > > > > On Sat, Feb 16, 2013 at 3:23 PM, Kevin Dunn wrote: > >> >> On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: >> >>> >>> >>> >>> On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >>>> >>>>> Hi there, >>>>> >>>>> Finally, I tried to make a Scipy Central design (home page) looking >>>>> close to scipy.org >>>>> >>>>> Please take a look and let me know how it is.. what could be changed >>>>> and all. >>>>> >>>>> http://ksurya.github.com/scipy-central-design/home.html >>>>> >>>>> Also: Few changes/ new features might be required like changing font >>>>> size, color, background color etc.. >>>>> >>>>> Please do comment on them too! >>>>> >>>>> The rest of the pages would be looking very similar to this.. >>>>> >>>>> (Note: this was the previous version >>>>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>>>> engine and probably won't work for this site). >>>>> >>>>> >>>>> Looking for your comments.. is this has any chance of merging into >>>>> main-stream (of course with some small changes) >>>>> >>>> >>>> I think this can certainly be merged. We should however first pick up >>>> the scipy-central code, domain names, etc. that were offered by Kevin Dunn >>>> (the original author) for transfer to the community last year ( >>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >>>> >>>> I would propose to transfer some of the domain names to NumFOCUS, and >>>> put the main scipy-central repo under github.com/scipy. I can take >>>> care of that, if everyone agrees. Then we do need to move the site to a new >>>> server and do some maintenance when needed. Is there someone who is willing >>>> to help with that? >>>> >>> >>> *Myself.* >>> >>> >>>> >>>> >>>> Ralf >>>> >>>> >>>> Actually I just want to know one thing.. is the "blue" of scipy.org a >>> kind of identity or symbol for the community/ site? Could we possibly use a >>> different kind of blue? (just asking) >>> >>> >> Hi everyone, >> >> As Ralf mentioned above, and based on a previous message I wrote ( >> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), the >> domains are absolutely available for transfer. >> >> Just let me know who to transfer to and when. This coming week is a good >> time frame for me to do this. >> > > Does it make sense to transfer these 4 domains, and let the other ones > lapse? > scipy-central.org > scipy-central.com > scipycentral.org > scipycentral.com > > scpyce makes no sense to me! (I don't know about its url hits) may be, can't we make the "scipycentral.org" as main domain.. rather than "scipy-central".. why hyphen?..If its not that readable.. why not "scipy.org/central" ?? This looks interesting > Ralf > > >> I like the new look, thanks Surya, I'm glad you can continue on with it >> and improve the site. >> >> -- >> Kevin Dunn >> Dept. of Chemical Engineering >> McMaster University >> http://learnche.mcmaster.ca/contact-info >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Feb 16 11:45:33 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 17:45:33 +0100 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 5:22 PM, Surya Kasturi wrote: > > > > On Sat, Feb 16, 2013 at 8:49 PM, Ralf Gommers wrote: > >> >> >> >> On Sat, Feb 16, 2013 at 3:23 PM, Kevin Dunn wrote: >> >>> >>> On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: >>> >>>> >>>> >>>> >>>> On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >>>>> >>>>>> Hi there, >>>>>> >>>>>> Finally, I tried to make a Scipy Central design (home page) looking >>>>>> close to scipy.org >>>>>> >>>>>> Please take a look and let me know how it is.. what could be changed >>>>>> and all. >>>>>> >>>>>> http://ksurya.github.com/scipy-central-design/home.html >>>>>> >>>>>> Also: Few changes/ new features might be required like changing font >>>>>> size, color, background color etc.. >>>>>> >>>>>> Please do comment on them too! >>>>>> >>>>>> The rest of the pages would be looking very similar to this.. >>>>>> >>>>>> (Note: this was the previous version >>>>>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>>>>> engine and probably won't work for this site). >>>>>> >>>>>> >>>>>> Looking for your comments.. is this has any chance of merging into >>>>>> main-stream (of course with some small changes) >>>>>> >>>>> >>>>> I think this can certainly be merged. We should however first pick up >>>>> the scipy-central code, domain names, etc. that were offered by Kevin Dunn >>>>> (the original author) for transfer to the community last year ( >>>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >>>>> >>>>> I would propose to transfer some of the domain names to NumFOCUS, and >>>>> put the main scipy-central repo under github.com/scipy. I can take >>>>> care of that, if everyone agrees. Then we do need to move the site to a new >>>>> server and do some maintenance when needed. Is there someone who is willing >>>>> to help with that? >>>>> >>>> >>>> *Myself.* >>>> >>>> >>>>> >>>>> >>>>> Ralf >>>>> >>>>> >>>>> Actually I just want to know one thing.. is the "blue" of scipy.org a >>>> kind of identity or symbol for the community/ site? Could we possibly use a >>>> different kind of blue? (just asking) >>>> >>>> >>> Hi everyone, >>> >>> As Ralf mentioned above, and based on a previous message I wrote ( >>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), the >>> domains are absolutely available for transfer. >>> >>> Just let me know who to transfer to and when. This coming week is a good >>> time frame for me to do this. >>> >> >> Does it make sense to transfer these 4 domains, and let the other ones >> lapse? >> scipy-central.org >> scipy-central.com >> scipycentral.org >> scipycentral.com >> >> scpyce makes no sense to me! (I don't know about its url hits) > I suspect that that was registered before we decided on the final name of the site. > may be, can't we make the "scipycentral.org" as main domain.. rather than > "scipy-central".. why hyphen?..If its not that readable.. > Either one works for me. > > why not "scipy.org/central" ?? This looks interesting > That's also fine. We don't have to worry about any domain names under scipy.org at least (besides the current cleanup in preparation of moving scipy.org to a Sphinx-based site). Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Feb 16 16:07:19 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 22:07:19 +0100 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: <510F8EF7.7010502@aip.de> References: <510F8EF7.7010502@aip.de> Message-ID: On Mon, Feb 4, 2013 at 11:35 AM, Frank Breitling wrote: > Hi, > > I have been trying to create a new page for the SciPy cookbook via > > http://www.scipy.org/Cookbook/Matplotlib/Histograms?action=edit > > but received the error below. > > Who can solve this? > I'm running into the same issue. If it's one "kick the server" action away, it would be great if someone does that. Otherwise, hurrying up with the new scipy.org site may be effort better spent. Ralf > > Frank > > --- > > OSError > > [Errno 31] Too many links: > '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' > > If you want to report a bug, please save this page and attach it to your > bug report. > > Show debugging information > Report bug > Visit MoinMoin wiki > > Traceback > > A problem occurred in a Python script. Here is the sequence of function > calls leading up to the error, in the order they occurred. > > /usr/lib/python2.4/site-packages/MoinMoin/request.py in run > (self=) > 1149 from MoinMoin.wikiaction import getHandler > 1150 handler = getHandler(self, action) > 1151 handler(self.page.page_name, self) > 1152 > 1153 # generate page footer (actions that do not want this > footer use > handler = > self = > self.page = > self.page.page_name = u'Cookbook/Matplotlib/Histograms' > > /usr/lib/python2.4/site-packages/MoinMoin/wikiaction.py in do_edit > (pagename=u'Cookbook/Matplotlib/Histograms', > request=) > 580 # is invoked without savetext start editing > 581 if savetext is None: > 582 pg.sendEditor() > 583 return > 584 > pg = > pg.sendEditor = > > > /usr/lib/python2.4/site-packages/MoinMoin/PageEditor.py in > sendEditor (self=, **kw={}) > 176 except OSError, err: > 177 if err.errno != errno.ENAMETOOLONG: > 178 raise err > 179 msg = _("Page name is too long, try shorter name.") > 180 > err = > > OSError > > [Errno 31] Too many links: > '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' > > args = (31, 'Too many links') > errno = 31 > filename = > '/home/scipy/wiki/data/pages/Cookbook(2f)Matplotlib(2f)Histograms' > strerror = 'Too many links' > > System Details > > Date: Mon, 04 Feb 2013 10:25:58 +0000 > Platform: Linux scipy.org 2.6.32-4-pve #1 SMP Thu Oct 21 09:35:29 > CEST 2010 i686 > Python: Python 2.4.3 (/usr/bin/python) > MoinMoin: Release 1.5.6 (release) > > > _______________________________________________ > 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 Sat Feb 16 16:34:44 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 16 Feb 2013 22:34:44 +0100 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 beta 1 release Message-ID: Hi, I am pleased to announce the availability of the first beta release of SciPy 0.12.0. This is shaping up to be another solid release, with some cool new features (see highlights below) and a large amount of bug fixes and maintenance work under the hood. The number of contributors also keeps rising steadily, we're at 74 so far for this release. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.12.0b1/, release notes are copied below. A Python 3.3 Windows installer will follow soon. Please try this release and report any problems on the mailing list. Cheers, Ralf ========================== SciPy 0.12.0 Release Notes ========================== .. note:: Scipy 0.12.0 is not released yet! SciPy 0.12.0 is the culmination of 7 months of hard work. It contains many new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.12.x branch, and on adding new features on the master branch. Some of the highlights of this release are: - Completed QHull wrappers in scipy.spatial. - cKDTree now a drop-in replacement for KDTree. - A new global optimizer, basinhopping. - Support for Python 2 and Python 3 from the same code base (no more 2to3). This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. Support for Python 2.4 and 2.5 has been dropped as of this release. New features ============ ``scipy.spatial`` improvements ------------------------------ cKDTree feature-complete ^^^^^^^^^^^^^^^^^^^^^^^^ Cython version of KDTree, cKDTree, is now feature-complete. Most operations (construction, query, query_ball_point, query_pairs, count_neighbors and sparse_distance_matrix) are between 200 and 1000 times faster in cKDTree than in KDTree. With very minor caveats, cKDTree has exactly the same interface as KDTree, and can be used as a drop-in replacement. Voronoi diagrams and convex hulls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `scipy.spatial` now contains functionality for computing Voronoi diagrams and convex hulls using the Qhull library. (Delaunay triangulation was available since Scipy 0.9.0.) Delaunay improvements ^^^^^^^^^^^^^^^^^^^^^ It's now possible to pass in custom Qhull options in Delaunay triangulation. Coplanar points are now also recorded, if present. Incremental construction of Delaunay triangulations is now also possible. Spectral estimators (``scipy.signal``) -------------------------------------- The functions ``scipy.signal.periodogram`` and ``scipy.signal.welch`` were added, providing DFT-based spectral estimators. ``scipy.optimize`` improvements ------------------------------- Callback functions in L-BFGS-B and TNC ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A callback mechanism was added to L-BFGS-B and TNC minimization solvers. Basin hopping global optimization (``scipy.optimize.basinhopping``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A new global optimization algorithm. Basinhopping is designed to efficiently find the global minimum of a smooth function. ``scipy.special`` improvements ------------------------------ Revised complex error functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The computation of special functions related to the error function now uses a new `Faddeeva library from MIT `__ which increases their numerical precision. The scaled and imaginary error functions ``erfcx`` and ``erfi`` were also added, and the Dawson integral ``dawsn`` can now be evaluated for a complex argument. Faster orthogonal polynomials ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Evaluation of orthogonal polynomials (the ``eval_*`` routines) in now faster in ``scipy.special``, and their ``out=`` argument functions properly. ``scipy.sparse.linalg`` features -------------------------------- - In ``scipy.sparse.linalg.spsolve``, the ``b`` argument can now be either a vector or a matrix. - ``scipy.sparse.linalg.inv`` was added. This uses ``spsolve`` to compute a sparse matrix inverse. - ``scipy.sparse.linalg.expm`` was added. This computes the exponential of a sparse matrix using a similar algorithm to the existing dense array implementation in ``scipy.linalg.expm``. Listing Matlab(R) file contents in ``scipy.io`` ----------------------------------------------- A new function ``whosmat`` is available in ``scipy.io`` for inspecting contents of MAT files without reading them to memory. Documented BLAS and LAPACK low-level interfaces (``scipy.linalg``) ------------------------------------------------------------------ The modules `scipy.linalg.blas` and `scipy.linalg.lapack` can be used to access low-level BLAS and LAPACK functions. Polynomial interpolation improvements (``scipy.interpolate``) ------------------------------------------------------------- The barycentric, Krogh, piecewise and pchip polynomial interpolators in ``scipy.interpolate`` accept now an ``axis`` argument. Deprecated features =================== `scipy.lib.lapack` ------------------ The module `scipy.lib.lapack` is deprecated. You can use `scipy.linalg.lapack` instead. The module `scipy.lib.blas` was deprecated earlier in Scipy 0.10.0. `fblas` and `cblas` ------------------- Accessing the modules `scipy.linalg.fblas`, `cblas`, `flapack`, `clapack` is deprecated. Instead, use the modules `scipy.linalg.lapack` and `scipy.linalg.blas`. Backwards incompatible changes ============================== Removal of ``scipy.io.save_as_module`` -------------------------------------- The function ``scipy.io.save_as_module`` was deprecated in Scipy 0.11.0, and is now removed. Its private support modules ``scipy.io.dumbdbm_patched`` and ``scipy.io.dumb_shelve`` are also removed. Other changes ============= Authors ======= * Anton Akhmerov + * Alexander Ebersp?cher + * Anne Archibald * Jisk Attema + * K.-Michael Aye + * bemasc + * Sebastian Berg + * Fran?ois Boulogne + * Matthew Brett * Lars Buitinck * Steven Byrnes + * Tim Cera + * Christian + * Keith Clawson + * David Cournapeau * Nathan Crock + * endolith * Bradley M. Froehle + * Matty G * Christoph Gohlke * Ralf Gommers * Robert David Grant + * Yaroslav Halchenko * Charles Harris * Jonathan Helmus * Andreas Hilboll * Hugo + * Oleksandr Huziy * Jeroen Demeyer + * Johannes Sch?nberger + * Steven G. Johnson + * Chris Jordan-Squire * Jonathan Taylor + * Niklas Kroeger + * Jerome Kieffer + * kingson + * Josh Lawrence * Denis Laxalde * Alex Leach + * Lorenzo Luengo + * Stephen McQuay + * MinRK * Sturla Molden + * Eric Moore + * mszep + * Matt Newville + * Vlad Niculae * Travis Oliphant * David Parker + * Fabian Pedregosa * Josef Perktold * Zach Ploskey + * Alex Reinhart + * richli + * Gilles Rochefort + * Ciro Duran Santillli + * Jan Schlueter + * Jonathan Scholz + * Anthony Scopatz * Skipper Seabold * Fabrice Silva + * Scott Sinclair * Jacob Stevenson + * Sturla Molden + * Julian Taylor + * thorstenkranz + * John Travers + * trueprice + * Nicky van Foreest * Jacob Vanderplas * Patrick Varilly * Daniel Velkov + * Pauli Virtanen * Stefan van der Walt * Warren Weckesser A total of 74 people contributed to this release. People with a "+" by their names contributed a patch for the first time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Sat Feb 16 19:23:42 2013 From: robert.kern at gmail.com (Robert Kern) Date: Sun, 17 Feb 2013 00:23:42 +0000 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: References: <510F8EF7.7010502@aip.de> Message-ID: On Sat, Feb 16, 2013 at 9:07 PM, Ralf Gommers wrote: > > On Mon, Feb 4, 2013 at 11:35 AM, Frank Breitling wrote: >> >> Hi, >> >> I have been trying to create a new page for the SciPy cookbook via >> >> http://www.scipy.org/Cookbook/Matplotlib/Histograms?action=edit >> >> but received the error below. >> >> Who can solve this? > > I'm running into the same issue. If it's one "kick the server" action away, > it would be great if someone does that. Otherwise, hurrying up with the new > scipy.org site may be effort better spent. Please try again. As the spam pages accumulate, they eventually hit the maximum number of files allowed in a directory. I have removed all non-current page directories away. -- Robert Kern From suryak at ieee.org Sat Feb 16 23:31:31 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sun, 17 Feb 2013 10:01:31 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 10:15 PM, Ralf Gommers wrote: > > > > On Sat, Feb 16, 2013 at 5:22 PM, Surya Kasturi wrote: > >> >> >> >> On Sat, Feb 16, 2013 at 8:49 PM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Sat, Feb 16, 2013 at 3:23 PM, Kevin Dunn wrote: >>> >>>> >>>> On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >>>>>> >>>>>>> Hi there, >>>>>>> >>>>>>> Finally, I tried to make a Scipy Central design (home page) looking >>>>>>> close to scipy.org >>>>>>> >>>>>>> Please take a look and let me know how it is.. what could be changed >>>>>>> and all. >>>>>>> >>>>>>> http://ksurya.github.com/scipy-central-design/home.html >>>>>>> >>>>>>> Also: Few changes/ new features might be required like changing font >>>>>>> size, color, background color etc.. >>>>>>> >>>>>>> Please do comment on them too! >>>>>>> >>>>>>> The rest of the pages would be looking very similar to this.. >>>>>>> >>>>>>> (Note: this was the previous version >>>>>>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>>>>>> engine and probably won't work for this site). >>>>>>> >>>>>>> >>>>>>> Looking for your comments.. is this has any chance of merging into >>>>>>> main-stream (of course with some small changes) >>>>>>> >>>>>> >>>>>> I think this can certainly be merged. We should however first pick up >>>>>> the scipy-central code, domain names, etc. that were offered by Kevin Dunn >>>>>> (the original author) for transfer to the community last year ( >>>>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >>>>>> >>>>>> I would propose to transfer some of the domain names to NumFOCUS, and >>>>>> put the main scipy-central repo under github.com/scipy. I can take >>>>>> care of that, if everyone agrees. Then we do need to move the site to a new >>>>>> server and do some maintenance when needed. Is there someone who is willing >>>>>> to help with that? >>>>>> >>>>> >>>>> *Myself.* >>>>> >>>>> >>>>>> >>>>>> >>>>>> Ralf >>>>>> >>>>>> >>>>>> Actually I just want to know one thing.. is the "blue" of scipy.orga kind of identity or symbol for the community/ site? Could we possibly use >>>>> a different kind of blue? (just asking) >>>>> >>>>> >>>> Hi everyone, >>>> >>>> As Ralf mentioned above, and based on a previous message I wrote ( >>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), >>>> the domains are absolutely available for transfer. >>>> >>>> Just let me know who to transfer to and when. This coming week is a >>>> good time frame for me to do this. >>>> >>> >>> Does it make sense to transfer these 4 domains, and let the other ones >>> lapse? >>> scipy-central.org >>> scipy-central.com >>> scipycentral.org >>> scipycentral.com >>> >>> scpyce makes no sense to me! (I don't know about its url hits) >> > > I suspect that that was registered before we decided on the final name of > the site. > > >> may be, can't we make the "scipycentral.org" as main domain.. rather >> than "scipy-central".. why hyphen?..If its not that readable.. >> > > Either one works for me. > >> >> why not "scipy.org/central" ?? This looks interesting >> > > That's also fine. We don't have to worry about any domain names under > scipy.org at least (besides the current cleanup in preparation of moving > scipy.org to a Sphinx-based site). > > Ralf > > Hi.. take a look at new design http://ksurya.github.com/scipy-central-design/home.html (I removed the traditional scipy blue)!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Sun Feb 17 00:03:50 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sun, 17 Feb 2013 10:33:50 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sun, Feb 17, 2013 at 10:01 AM, Surya Kasturi wrote: > > > > On Sat, Feb 16, 2013 at 10:15 PM, Ralf Gommers wrote: > >> >> >> >> On Sat, Feb 16, 2013 at 5:22 PM, Surya Kasturi wrote: >> >>> >>> >>> >>> On Sat, Feb 16, 2013 at 8:49 PM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Sat, Feb 16, 2013 at 3:23 PM, Kevin Dunn wrote: >>>> >>>>> >>>>> On Sat, Feb 16, 2013 at 8:19 AM, Surya Kasturi wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Feb 16, 2013 at 6:04 PM, Ralf Gommers >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Feb 15, 2013 at 9:24 AM, Surya Kasturi wrote: >>>>>>> >>>>>>>> Hi there, >>>>>>>> >>>>>>>> Finally, I tried to make a Scipy Central design (home page) looking >>>>>>>> close to scipy.org >>>>>>>> >>>>>>>> Please take a look and let me know how it is.. what could be >>>>>>>> changed and all. >>>>>>>> >>>>>>>> http://ksurya.github.com/scipy-central-design/home.html >>>>>>>> >>>>>>>> Also: Few changes/ new features might be required like changing >>>>>>>> font size, color, background color etc.. >>>>>>>> >>>>>>>> Please do comment on them too! >>>>>>>> >>>>>>>> The rest of the pages would be looking very similar to this.. >>>>>>>> >>>>>>>> (Note: this was the previous version >>>>>>>> http://ksurya.github.com/scipycentral/ .. Looks a lot like search >>>>>>>> engine and probably won't work for this site). >>>>>>>> >>>>>>>> >>>>>>>> Looking for your comments.. is this has any chance of merging into >>>>>>>> main-stream (of course with some small changes) >>>>>>>> >>>>>>> >>>>>>> I think this can certainly be merged. We should however first pick >>>>>>> up the scipy-central code, domain names, etc. that were offered by Kevin >>>>>>> Dunn (the original author) for transfer to the community last year ( >>>>>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html) >>>>>>> >>>>>>> I would propose to transfer some of the domain names to NumFOCUS, >>>>>>> and put the main scipy-central repo under github.com/scipy. I can >>>>>>> take care of that, if everyone agrees. Then we do need to move the site to >>>>>>> a new server and do some maintenance when needed. Is there someone who is >>>>>>> willing to help with that? >>>>>>> >>>>>> >>>>>> *Myself.* >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Ralf >>>>>>> >>>>>>> >>>>>>> Actually I just want to know one thing.. is the "blue" of scipy.orga kind of identity or symbol for the community/ site? Could we possibly use >>>>>> a different kind of blue? (just asking) >>>>>> >>>>>> >>>>> Hi everyone, >>>>> >>>>> As Ralf mentioned above, and based on a previous message I wrote ( >>>>> http://mail.scipy.org/pipermail/scipy-dev/2012-August/017911.html), >>>>> the domains are absolutely available for transfer. >>>>> >>>>> Just let me know who to transfer to and when. This coming week is a >>>>> good time frame for me to do this. >>>>> >>>> >>>> Does it make sense to transfer these 4 domains, and let the other ones >>>> lapse? >>>> scipy-central.org >>>> scipy-central.com >>>> scipycentral.org >>>> scipycentral.com >>>> >>>> scpyce makes no sense to me! (I don't know about its url hits) >>> >> >> I suspect that that was registered before we decided on the final name of >> the site. >> >> >>> may be, can't we make the "scipycentral.org" as main domain.. rather >>> than "scipy-central".. why hyphen?..If its not that readable.. >>> >> >> Either one works for me. >> >>> >>> why not "scipy.org/central" ?? This looks interesting >>> >> >> That's also fine. We don't have to worry about any domain names under >> scipy.org at least (besides the current cleanup in preparation of moving >> scipy.org to a Sphinx-based site). >> >> Ralf >> >> > Hi.. take a look at new design > http://ksurya.github.com/scipy-central-design/home.html > (I removed the traditional scipy blue)!! > Does it look any modern? Actually, my background is more inclined towards Python.. Joined to write some python.. but somehow, I scipycentral found intetesting (may be because, there is a lot to do on it -- and I could do it from scratch). So, I am even interested in writing some Python.. (if there is anything specific I can try.. small initially..). -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sun Feb 17 00:13:36 2013 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 16 Feb 2013 21:13:36 -0800 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sat, Feb 16, 2013 at 9:03 PM, Surya Kasturi wrote: > Does it look any modern? Actually, my background is more inclined towards > Python.. Joined to write some python.. but somehow, I scipycentral found > intetesting (may be because, there is a lot to do on it -- and I could do it > from scratch). Minor suggestion: use sans serif fonts. Those small serif ones really don't work very well in normal screen resolutions... Cheers, and thanks for working on this! f From lists at hilboll.de Sun Feb 17 03:49:11 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sun, 17 Feb 2013 09:49:11 +0100 Subject: [SciPy-Dev] scipy 0.11 packages for Ubuntu 12.04LTS Message-ID: <51209987.6070505@hilboll.de> Good morning, I finally managed to package scipy 0.11 for Ubuntu Precise (12.04LTS), and uploaded the packages to the pylab PPA: ppa:pylab/stable I ran ``scipy.test('full')`` for both the Python2 and Python3 packages, and with both packages, I get one failure (called slightly different for py3, but also related to #651): FAIL: Regression test for #651: better handling of badly conditioned Is this something to worry about? I basically just took the current 'stable' package from Ubuntu Precise (which is 0.9.0) and adapted the packaging in minor places as to eliminate any packaging errors (there was some patching around which didn't seem to make sense for 0.11.0). Please feel free to use this PPA and report any bugs back to me. Any wishes and further suggestions are also welcoome =) Cheers, Andreas. From suryak at ieee.org Sun Feb 17 07:08:04 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sun, 17 Feb 2013 17:38:04 +0530 Subject: [SciPy-Dev] Scipy Central Home Page .. finally In-Reply-To: References: Message-ID: On Sun, Feb 17, 2013 at 10:43 AM, Fernando Perez wrote: > On Sat, Feb 16, 2013 at 9:03 PM, Surya Kasturi wrote: > > Does it look any modern? Actually, my background is more inclined towards > > Python.. Joined to write some python.. but somehow, I scipycentral found > > intetesting (may be because, there is a lot to do on it -- and I could > do it > > from scratch). > > > Minor suggestion: use sans serif fonts. Those small serif ones really > don't work very well in normal screen resolutions... > > Cheers, and thanks for working on this! > > Please take a look into another page: http://ksurya.github.com/scipy-central-design/snippet.html previous was home page.. this is how a snippet page might look like.. (Note: the syntax highlighting was done using pygments.. I just used 
here.. don't worry abt that one.)


> f
> _______________________________________________
> 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  Sun Feb 17 07:36:36 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 17 Feb 2013 07:36:36 -0500
Subject: [SciPy-Dev] Scipy Central Home Page .. finally
In-Reply-To: 
References: 
	
	
	
	
	
	
	
	
	
	
Message-ID: 

On Sun, Feb 17, 2013 at 7:08 AM, Surya Kasturi  wrote:
>
>
>
> On Sun, Feb 17, 2013 at 10:43 AM, Fernando Perez 
> wrote:
>>
>> On Sat, Feb 16, 2013 at 9:03 PM, Surya Kasturi  wrote:
>> > Does it look any modern? Actually, my background is more inclined
>> > towards
>> > Python.. Joined to write some python.. but somehow, I scipycentral found
>> > intetesting (may be because, there is a lot to do on it -- and I could
>> > do it
>> > from scratch).

scipy.signal is waiting for improvements, but I and, I think, we all
appreciate the improvements to scipy-central.

>>
>>
>> Minor suggestion: use sans serif fonts.  Those small serif ones really
>> don't work very well in normal screen resolutions...
>>
>> Cheers, and thanks for working on this!
>>
>
> Please take a look into another page:
> http://ksurya.github.com/scipy-central-design/snippet.html
> previous was home page.. this is how a snippet page might look like..
> (Note: the syntax highlighting was done using pygments.. I just used 
> here.. don't worry abt that one.)

I like the design, it's *much* better than the blue.

two minor points
is it possible to use a darker blue for the links (especially the side bar)?

in the matlab fileexchange I usually check the date for created and
updated. time stamp of first version, time stamp of this version.   I
don't know if that's easy to get here.


What we haven't discussed yet in this thread is a commenting system.
IIRC, last time we discussed this, the general opinion was that this
would be useful to have, but noone worked on it.

Josef

>
>>
>> f
>> _______________________________________________
>> 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 pav at iki.fi  Sun Feb 17 08:10:52 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 17 Feb 2013 15:10:52 +0200
Subject: [SciPy-Dev] Scipy Central Home Page .. finally
In-Reply-To: 
References: 
	
	
	
	
	
	
	
	
Message-ID: 

Hi,

17.02.2013 07:03, Surya Kasturi kirjoitti:
[clip]
> So, I am even interested in writing some Python.. (if there is anything
> specific I can try.. small initially..).

Some suggestions given previously by Ralf:

http://thread.gmane.org/gmane.comp.python.scientific.devel/17173

This one should be quick to do (< 1 hour of work):

http://projects.scipy.org/scipy/ticket/1621

The fftconvolve() routine in scipy.signal currently pads arrays to
powers of two. However, the FFTPACK engine works well (I think) also
with factors of 2, 3, and 5. (You might have to do some benchmarking or
looking into the FFTPACK fortran source files to verify this.)

That ticket already contains a function to do this (for some other sets
of factors), so the only thing here is to integrate this to
scipy.signal. If you want some practice, taking this, and forming it up
to a pull request in Scipy could be a useful idea.

-- 
Pauli Virtanen



From pav at iki.fi  Sun Feb 17 08:15:59 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 17 Feb 2013 15:15:59 +0200
Subject: [SciPy-Dev] scipy 0.11 packages for Ubuntu 12.04LTS
In-Reply-To: <51209987.6070505@hilboll.de>
References: <51209987.6070505@hilboll.de>
Message-ID: 

17.02.2013 10:49, Andreas Hilboll kirjoitti:
[clip]
> I ran ``scipy.test('full')`` for both the Python2 and Python3 packages,
> and with both packages, I get one failure (called slightly different for
> py3, but also related to #651):
> 
>    FAIL: Regression test for #651: better handling of badly conditioned
> 
> Is this something to worry about?

It tests whether some routine raises a warning.

However, if some other test also raises the warning, then it's possible
it does not appear for the second time. You can grep the test output for
BadCoefficients to see if this happened.

-- 
Pauli Virtanen



From suryak at ieee.org  Sun Feb 17 08:58:44 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Sun, 17 Feb 2013 19:28:44 +0530
Subject: [SciPy-Dev] Scipy Central Home Page .. finally
In-Reply-To: 
References: 
	
	
	
	
	
	
	
	
	
	
	
Message-ID: 

On Sun, Feb 17, 2013 at 6:06 PM,  wrote:

> On Sun, Feb 17, 2013 at 7:08 AM, Surya Kasturi  wrote:
> >
> >
> >
> > On Sun, Feb 17, 2013 at 10:43 AM, Fernando Perez 
> > wrote:
> >>
> >> On Sat, Feb 16, 2013 at 9:03 PM, Surya Kasturi  wrote:
> >> > Does it look any modern? Actually, my background is more inclined
> >> > towards
> >> > Python.. Joined to write some python.. but somehow, I scipycentral
> found
> >> > intetesting (may be because, there is a lot to do on it -- and I could
> >> > do it
> >> > from scratch).
>
> scipy.signal is waiting for improvements, but I and, I think, we all
> appreciate the improvements to scipy-central.
>
> >>
> >>
> >> Minor suggestion: use sans serif fonts.  Those small serif ones really
> >> don't work very well in normal screen resolutions...
> >>
> >> Cheers, and thanks for working on this!
> >>
> >
> > Please take a look into another page:
> > http://ksurya.github.com/scipy-central-design/snippet.html
> > previous was home page.. this is how a snippet page might look like..
> > (Note: the syntax highlighting was done using pygments.. I just used
> 
> > here.. don't worry abt that one.)
>
> I like the design, it's *much* better than the blue.
>
> thanks!

> two minor points
> is it possible to use a darker blue for the links (especially the side
> bar)?
>
> Of course. what you see there is default settings.. However, bootstrap
default settings are quite stable and decent to use.

> in the matlab fileexchange I usually check the date for created and
> updated. time stamp of first version, time stamp of this version.   I
> don't know if that's easy to get here.
>
> I guess we can do it..(what's there on the current site can be neatly
presented .. as for now)

>
> What we haven't discussed yet in this thread is a commenting system.
> IIRC, last time we discussed this, the general opinion was that this
> would be useful to have, but noone worked on it.
>
> Exactly! You really got the right point. Scipy Central doesn't have
commenting system. However, my initial target is to "change" the
"design".Later, the server side improvements.

I initially wanted to add open-id functionality to the site.. So, I tried
to setup the website to run locally but I ran into too many toubles
configuring it.. I think some areas of the website are too system/
package-version dependent. So, configuring the system was horribile for me.
Thought to put the task aside for a while.. and pick the "design" as there
was a lot to do (in fact, I am just a novice in design part.. thought to
improve skills too) what do you say?..

Also, reading others code isn't part of my 1st task (which is very hard -
at least for me) as I just got to develope things from scratch!!

> Josef
>
> >
> >>
> >> f
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ralf.gommers at gmail.com  Sun Feb 17 13:47:40 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 17 Feb 2013 19:47:40 +0100
Subject: [SciPy-Dev] OSError with Cookbook
In-Reply-To: 
References: <510F8EF7.7010502@aip.de>
	
	
Message-ID: 

On Sun, Feb 17, 2013 at 1:23 AM, Robert Kern  wrote:

> On Sat, Feb 16, 2013 at 9:07 PM, Ralf Gommers 
> wrote:
> >
> > On Mon, Feb 4, 2013 at 11:35 AM, Frank Breitling 
> wrote:
> >>
> >> Hi,
> >>
> >> I have been trying to create a new page for the SciPy cookbook via
> >>
> >> http://www.scipy.org/Cookbook/Matplotlib/Histograms?action=edit
> >>
> >> but received the error below.
> >>
> >> Who can solve this?
> >
> > I'm running into the same issue. If it's one "kick the server" action
> away,
> > it would be great if someone does that. Otherwise, hurrying up with the
> new
> > scipy.org site may be effort better spent.
>
> Please try again. As the spam pages accumulate, they eventually hit
> the maximum number of files allowed in a directory. I have removed all
> non-current page directories away.


Thanks Robert, it's working again.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jsseabold at gmail.com  Mon Feb 18 13:02:17 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Mon, 18 Feb 2013 13:02:17 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
Message-ID: 

Hi,

Just curious what the status of migrating the issues to github for scipy
is? I think this was on the table right?

Thanks,

Skipper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pav at iki.fi  Mon Feb 18 13:19:04 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 18 Feb 2013 20:19:04 +0200
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
Message-ID: 

Hi,

18.02.2013 20:02, Skipper Seabold kirjoitti:
> Just curious what the status of migrating the issues to github for scipy
> is? I think this was on the table right?

It's on the table, but AFAIK nobody is actively working on it.

Though, I'm still kind of wondering a bit how I'd do bugreports such as
this: http://projects.scipy.org/scipy/ticket/1840

The data file is an integral part of the report, and cannot easily be
factored out. If I put it in Dropbox or some random place like that, it
won't stay there necessarily for long...

-- 
Pauli Virtanen



From jsseabold at gmail.com  Mon Feb 18 13:28:59 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Mon, 18 Feb 2013 13:28:59 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
Message-ID: 

On Mon, Feb 18, 2013 at 1:19 PM, Pauli Virtanen  wrote:

> Hi,
>
> 18.02.2013 20:02, Skipper Seabold kirjoitti:
> > Just curious what the status of migrating the issues to github for scipy
> > is? I think this was on the table right?
>
> It's on the table, but AFAIK nobody is actively working on it.
>
> Though, I'm still kind of wondering a bit how I'd do bugreports such as
> this: http://projects.scipy.org/scipy/ticket/1840
>
> The data file is an integral part of the report, and cannot easily be
> factored out. If I put it in Dropbox or some random place like that, it
> won't stay there necessarily for long...
>
>
It's a hack, but since the trac links are persistent, we could make the
Trac read-only or something and insert issue attachments as links into the
github issues. I haven't looked at the migration scripts how easy it would
be to do this.

Trac Attachment (2/06/13): [Test data file](
http://projects.scipy.org/scipy/attachment/ticket/1840/estimate_gradients_hang.npy
)

Just a thought.

Skipper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From thouis at gmail.com  Mon Feb 18 13:53:36 2013
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Mon, 18 Feb 2013 13:53:36 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
Message-ID: 

On Mon, Feb 18, 2013 at 1:28 PM, Skipper Seabold  wrote:
>
> On Mon, Feb 18, 2013 at 1:19 PM, Pauli Virtanen  wrote:
>>
>> Hi,
>>
>> 18.02.2013 20:02, Skipper Seabold kirjoitti:
>> > Just curious what the status of migrating the issues to github for scipy
>> > is? I think this was on the table right?
>>
>> It's on the table, but AFAIK nobody is actively working on it.
>>
>> Though, I'm still kind of wondering a bit how I'd do bugreports such as
>> this: http://projects.scipy.org/scipy/ticket/1840
>>
>> The data file is an integral part of the report, and cannot easily be
>> factored out. If I put it in Dropbox or some random place like that, it
>> won't stay there necessarily for long...
>>
>
> It's a hack, but since the trac links are persistent, we could make the Trac read-only or something and insert issue attachments as links into the github issues. I haven't looked at the migration scripts how easy it would be to do this.
>
> Trac Attachment (2/06/13): [Test data file](http://projects.scipy.org/scipy/attachment/ticket/1840/estimate_gradients_hang.npy)

That's what we did for the numpy trac->github migration.  All the
attachments from Trac still live there.

An example: https://github.com/numpy/numpy/issues/2490

Ray


From pav at iki.fi  Mon Feb 18 15:29:30 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 18 Feb 2013 22:29:30 +0200
Subject: [SciPy-Dev] flapack and the GIL
In-Reply-To: <511B9AA3.3050207@molden.no>
References: <510F9A83.7000302@molden.no> 
	<511B9AA3.3050207@molden.no>
Message-ID: 

13.02.2013 15:52, Sturla Molden kirjoitti:
> On 04.02.2013 19:28, Pauli Virtanen wrote:
>> AFAIK, *all* of Lapack is threadsafe --- there are no SAVE or COMMON
>> statements. The same is probably true for any modified LAPACK routines
>> in MKL, Accelerate and the ilk.
> 
> Do you mind if I put a 'threadsafe' in all of them? :)
> 
> If one LAPACK method is tread-safe there is no reason to assume the 
> others are not.

This would be otherwise fine, except that for Lapack < 3.2, we *know*
some (= only a couple?) of the methods are not threadsafe.

However, I guess if a methd is marked threadsafe in LAPACK >= 3.0.0, we
should mark it so also in our wrappers...

	Pauli



From pav at iki.fi  Mon Feb 18 15:25:08 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 18 Feb 2013 22:25:08 +0200
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
Message-ID: 

18.02.2013 20:28, Skipper Seabold kirjoitti:
[clip]
> It's a hack, but since the trac links are persistent, we could make the
> Trac read-only or something and insert issue attachments as links into
> the github issues. I haven't looked at the migration scripts how easy it
> would be to do this.

Yes, we can deal with it in migration, but the point is that that won't
work for new bug reports...

-- 
Pauli Virtanen




From jsseabold at gmail.com  Mon Feb 18 15:49:17 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Mon, 18 Feb 2013 15:49:17 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
Message-ID: 

On Mon, Feb 18, 2013 at 3:25 PM, Pauli Virtanen  wrote:

> 18.02.2013 20:28, Skipper Seabold kirjoitti:
> [clip]
> > It's a hack, but since the trac links are persistent, we could make the
> > Trac read-only or something and insert issue attachments as links into
> > the github issues. I haven't looked at the migration scripts how easy it
> > would be to do this.
>
> Yes, we can deal with it in migration, but the point is that that won't
> work for new bug reports...
>
>
Ah. "do" meant report not fix. Well, the short answer I guess is that you
can't. You could, however, always attach files to the mailing list, or you
can just copy-paste that code into the actual issue, which is a bit easier
on github IMO. It changes the reporting workflow a bit, but I don't think
it's a deal breaker. I think the positives outweigh the negatives here.

The reason I bring this up is that I find Trac to be a disincentive to
report things, file enhancement issues, etc. now that almost all projects I
work with regularly are on github. I doubt I'm the only one, but maybe I am.

Skipper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pav at iki.fi  Mon Feb 18 17:03:43 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 19 Feb 2013 00:03:43 +0200
Subject: [SciPy-Dev] 64-bit sparse matrix indices
In-Reply-To: 
References: 
Message-ID: 


FYI: https://github.com/scipy/scipy/pull/442

If you're interested in sparse matrices with nnz > 2**31, if you can
play around with the above code, it would be appreciated.

-- 
Pauli Virtanen



From fperez.net at gmail.com  Mon Feb 18 17:35:46 2013
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 18 Feb 2013 14:35:46 -0800
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

On Mon, Feb 18, 2013 at 12:49 PM, Skipper Seabold  wrote:
> I doubt I'm the only one, but maybe I am.

You're not ;)


From matthew.brett at gmail.com  Mon Feb 18 17:43:11 2013
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 18 Feb 2013 14:43:11 -0800
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
	
	
Message-ID: 

On Mon, Feb 18, 2013 at 2:35 PM, Fernando Perez  wrote:
> On Mon, Feb 18, 2013 at 12:49 PM, Skipper Seabold  wrote:
>> I doubt I'm the only one, but maybe I am.
>
> You're not ;)

Most certainly not :)

Matthew


From anandps20 at gmail.com  Tue Feb 19 02:44:12 2013
From: anandps20 at gmail.com (anand parthasarathy)
Date: Tue, 19 Feb 2013 13:14:12 +0530
Subject: [SciPy-Dev] Like to contribute to Scipy
Message-ID: 

Hi,

I would like to start contribute to Scipy - signal processing module. I
have been using MATLAB for a very long time, to the extend that i have
implemented many signal processing algorithms targeting the applications in
the field of Communications & wireless PHY Layer .

 I am currently a Research Intern at Centre of Excellence in Wireless
Technology (CEWiT), India. I am so much fascinated by Scipy and though i am
new to python, i started love to code in python environment.

Since this field is like a ocean , i would like to get suggestions from you
guys on this like where to start , and after decided with a specific part
to work on , i will start and contribute many things to Scipy to the extend
that i can.






Regards,
Anand Parthasarathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jsseabold at gmail.com  Tue Feb 19 07:01:21 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Tue, 19 Feb 2013 07:01:21 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
Message-ID: 

On Mon, Feb 18, 2013 at 1:53 PM, Thouis (Ray) Jones wrote:

> On Mon, Feb 18, 2013 at 1:28 PM, Skipper Seabold 
> wrote:
> >
> > On Mon, Feb 18, 2013 at 1:19 PM, Pauli Virtanen  wrote:
> >>
> >> Hi,
> >>
> >> 18.02.2013 20:02, Skipper Seabold kirjoitti:
> >> > Just curious what the status of migrating the issues to github for
> scipy
> >> > is? I think this was on the table right?
> >>
> >> It's on the table, but AFAIK nobody is actively working on it.
> >>
> >> Though, I'm still kind of wondering a bit how I'd do bugreports such as
> >> this: http://projects.scipy.org/scipy/ticket/1840
> >>
> >> The data file is an integral part of the report, and cannot easily be
> >> factored out. If I put it in Dropbox or some random place like that, it
> >> won't stay there necessarily for long...
> >>
> >
> > It's a hack, but since the trac links are persistent, we could make the
> Trac read-only or something and insert issue attachments as links into the
> github issues. I haven't looked at the migration scripts how easy it would
> be to do this.
> >
> > Trac Attachment (2/06/13): [Test data file](
> http://projects.scipy.org/scipy/attachment/ticket/1840/estimate_gradients_hang.npy
> )
>
> That's what we did for the numpy trac->github migration.  All the
> attachments from Trac still live there.
>
> An example: https://github.com/numpy/numpy/issues/2490
>
>
Hi Ray,

This looks nice. Do the scripts for this migration live somewhere? Could
you give an estimate (developer time-wise) how much work it was?

Skipper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jsseabold at gmail.com  Tue Feb 19 11:01:51 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Tue, 19 Feb 2013 11:01:51 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

On Tue, Feb 19, 2013 at 7:01 AM, Skipper Seabold  wrote:
> On Mon, Feb 18, 2013 at 1:53 PM, Thouis (Ray) Jones 
> wrote:
>>
>> On Mon, Feb 18, 2013 at 1:28 PM, Skipper Seabold 
>> wrote:
>> >
>> > On Mon, Feb 18, 2013 at 1:19 PM, Pauli Virtanen  wrote:
>> >>
>> >> Hi,
>> >>
>> >> 18.02.2013 20:02, Skipper Seabold kirjoitti:
>> >> > Just curious what the status of migrating the issues to github for
>> >> > scipy
>> >> > is? I think this was on the table right?
>> >>
>> >> It's on the table, but AFAIK nobody is actively working on it.
>> >>
>> >> Though, I'm still kind of wondering a bit how I'd do bugreports such as
>> >> this: http://projects.scipy.org/scipy/ticket/1840
>> >>
>> >> The data file is an integral part of the report, and cannot easily be
>> >> factored out. If I put it in Dropbox or some random place like that, it
>> >> won't stay there necessarily for long...
>> >>
>> >
>> > It's a hack, but since the trac links are persistent, we could make the
>> > Trac read-only or something and insert issue attachments as links into the
>> > github issues. I haven't looked at the migration scripts how easy it would
>> > be to do this.
>> >
>> > Trac Attachment (2/06/13): [Test data
>> > file](http://projects.scipy.org/scipy/attachment/ticket/1840/estimate_gradients_hang.npy)
>>
>> That's what we did for the numpy trac->github migration.  All the
>> attachments from Trac still live there.
>>
>> An example: https://github.com/numpy/numpy/issues/2490
>>
>
> Hi Ray,
>
> This looks nice. Do the scripts for this migration live somewhere? Could you
> give an estimate (developer time-wise) how much work it was?
>

Parking this link here.

https://github.com/roskakori/tratihubis

Skipper


From thouis at gmail.com  Tue Feb 19 22:31:38 2013
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Tue, 19 Feb 2013 22:31:38 -0500
Subject: [SciPy-Dev] Status of Migrating Issues to Github?
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

https://github.com/thouis/numpy-trac-migration

Testing was key.  I used my own repo for that, and did maybe 20 test
imports before the real one (and still made a few mistakes).

Tratihubis looks more polished.

Ray


On Tue, Feb 19, 2013 at 7:01 AM, Skipper Seabold  wrote:
> On Mon, Feb 18, 2013 at 1:53 PM, Thouis (Ray) Jones 
> wrote:
>>
>> On Mon, Feb 18, 2013 at 1:28 PM, Skipper Seabold 
>> wrote:
>> >
>> > On Mon, Feb 18, 2013 at 1:19 PM, Pauli Virtanen  wrote:
>> >>
>> >> Hi,
>> >>
>> >> 18.02.2013 20:02, Skipper Seabold kirjoitti:
>> >> > Just curious what the status of migrating the issues to github for
>> >> > scipy
>> >> > is? I think this was on the table right?
>> >>
>> >> It's on the table, but AFAIK nobody is actively working on it.
>> >>
>> >> Though, I'm still kind of wondering a bit how I'd do bugreports such as
>> >> this: http://projects.scipy.org/scipy/ticket/1840
>> >>
>> >> The data file is an integral part of the report, and cannot easily be
>> >> factored out. If I put it in Dropbox or some random place like that, it
>> >> won't stay there necessarily for long...
>> >>
>> >
>> > It's a hack, but since the trac links are persistent, we could make the
>> > Trac read-only or something and insert issue attachments as links into the
>> > github issues. I haven't looked at the migration scripts how easy it would
>> > be to do this.
>> >
>> > Trac Attachment (2/06/13): [Test data
>> > file](http://projects.scipy.org/scipy/attachment/ticket/1840/estimate_gradients_hang.npy)
>>
>> That's what we did for the numpy trac->github migration.  All the
>> attachments from Trac still live there.
>>
>> An example: https://github.com/numpy/numpy/issues/2490
>>
>
> Hi Ray,
>
> This looks nice. Do the scripts for this migration live somewhere? Could you
> give an estimate (developer time-wise) how much work it was?
>
> Skipper
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From pierre.haessig at crans.org  Wed Feb 20 12:18:45 2013
From: pierre.haessig at crans.org (Pierre Haessig)
Date: Wed, 20 Feb 2013 18:18:45 +0100
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
Message-ID: <51250575.9060700@crans.org>

Hello,

Just a quick question about filter design using scipy.signal.butter :
(using scipy '0.10.1')

>>> import scipy.signal as sig
>>> B,A = sig.butter(N=4, Wn=1, analog=1) # 4rth order low-pass filter
with cutoff at 1 rad/s
>>> A,B
(array([ 1.00000000 +0.00000000e+00j,  2.61312593 -1.11022302e-16j,
        3.41421356 +0.00000000e+00j,  2.61312593 -1.11022302e-16j,
        1.00000000 -1.66533454e-16j]),
 array([ 1.+0.j]))

I was surprised by the result since I was expecting real numbers and not
complex numbers. And indeed the imaginary part is zero with respect to
floating point precision. For comparison, bessel function return real
coefficients.

So my question is : is the return of complex coefficients the expected
behavior ? or should I place an issue on Trac ?

best,
Pierre

(Maybe I didn't use the proper keywords because a quick Google search
didn't give me preexisting discussion on this topic)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 

From jsseabold at gmail.com  Wed Feb 20 17:20:56 2013
From: jsseabold at gmail.com (Skipper Seabold)
Date: Wed, 20 Feb 2013 17:20:56 -0500
Subject: [SciPy-Dev] small issue with fftconvolve in 0.12.0 beta.
Message-ID: 

See my comment on this commit. Not a big deal, but might be worth a doc
clarification if not a deprecation warning.

https://github.com/scipy/scipy/commit/66fe7c892906373caf64f116d72f9d2edb97f53e#commitcomment-2661418

Skipper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ewm at redtetrahedron.org  Wed Feb 20 18:58:55 2013
From: ewm at redtetrahedron.org (Eric Moore)
Date: Wed, 20 Feb 2013 18:58:55 -0500
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
In-Reply-To: <51250575.9060700@crans.org>
References: <51250575.9060700@crans.org>
Message-ID: <5125633F.909@redtetrahedron.org>

Pierre Haessig wrote:
> Hello,
>
> Just a quick question about filter design using scipy.signal.butter :
> (using scipy '0.10.1')
>
>  >>> import scipy.signal as sig
>  >>> B,A = sig.butter(N=4, Wn=1, analog=1) # 4rth order low-pass filter
> with cutoff at 1 rad/s
>  >>> A,B
> (array([ 1.00000000 +0.00000000e+00j, 2.61312593 -1.11022302e-16j,
> 3.41421356 +0.00000000e+00j, 2.61312593 -1.11022302e-16j,
> 1.00000000 -1.66533454e-16j]),
> array([ 1.+0.j]))
>
> I was surprised by the result since I was expecting real numbers and not
> complex numbers. And indeed the imaginary part is zero with respect to
> floating point precision. For comparison, bessel function return real
> coefficients.
>
> So my question is : is the return of complex coefficients the expected
> behavior ? or should I place an issue on Trac ?
>
> best,
> Pierre
>
> (Maybe I didn't use the proper keywords because a quick Google search
> didn't give me preexisting discussion on this topic)
>

I'd say that no it isn't expected.  What is happening here is that the 
code in np.poly which constructs a polynomial from its zeros tries to 
detect that you have pairs of complex conjugate roots and then return a 
real array.  That code is failing in this particular case.  (The code in 
question is lines 137-145 of numpy/lib/polynomial.py: 
https://github.com/numpy/numpy/blob/master/numpy/lib/polynomial.py#L137)

I'm not sure that the correct fix would be, perhaps signal.buttap should 
calculate the poles by calculating half of them, and then conjugating. 
Since I'd bet that the ultimate cause is that we aren't getting exact 
conjugates from the complex exponential.

Eric



From cmiller730 at gmail.com  Wed Feb 20 19:30:53 2013
From: cmiller730 at gmail.com (Christopher Miller)
Date: Wed, 20 Feb 2013 19:30:53 -0500
Subject: [SciPy-Dev] Introduction and feature proposal.
Message-ID: <51256ABD.2040908@gmail.com>

Hello,

My name is Chris Miller and I'm a recent applied math PhD from 
University of Maryland. I have some matlab and C/C++ code for computing 
multi-dimensional integrals using Smolyak sparse grids that I think 
might fit well inside scipy.integrate. Sparse grid quadrature delays the 
onset of the so called "curse of dimensionality," and is very efficient 
for evaluating integrals with a 'moderate' number of variables, say 
~<50. Sparse grids rules can also be tailored to perform integration 
with respect to various measures (uniform, Gaussian, beta-distribution, 
etc.). I'd appreciate any feedback on whether or not people would find 
this useful.

I also have a pretty good background in sparse numerical linear algebra 
and multigrid preconditioners, and would like to contribute code in that 
vein some time down the road. I'm looking forward to working with all of 
you and hope I can be helpful.

Chris

p.s. Here are some references. Most of my work with these was in solving 
stochastic PDEs, so the references tilt that way, but they are generally 
useful tools for multi-dimensional integration/interpolation.

D. Xiu and J. Hesthaven. High-order collocation methods for differential 
equa-
tions with random inputs. SIAM Journal on Scientific Computing, 27:1118?
1139, 2005.

F. Nobile, R. Tempone, and C.G. Webster. An anisotropic sparse grid col-
location algorithm for the solution of stochastic differential 
equations. SIAM
Journal on Numerical Analysis, 46:2411?2442, 2008.



From charlesr.harris at gmail.com  Wed Feb 20 23:57:15 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 20 Feb 2013 21:57:15 -0700
Subject: [SciPy-Dev] Splines
Message-ID: 

Hi All,

There have been several threads on the list about splines and consolidation
of splines. For instance, there are several uniform spline implementations
for images and signal processing, various low level functions in fitlib
that are unexposed, and perhaps useful altenatives to b-splines for some
applications like straight interpolation. For myself, I've started
implementing several functions in pure Python with an eye to converting
them to Cython once the interface and documentation is in place, mostly for
doing things that fitpack doesn't do because it is very integrated, as
opposed to supplying a basic toolset. As part of this project, I'd like to
get some feedback on which functions people use most and what features they
would like to see. I'm not interested in the high level classes at this
point, either the current classes or combo functions like fpcurf, but
rather a collection of good lower level function that could be used to
implement the higher level functions in a more flexible way.

Thoughts?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pav at iki.fi  Thu Feb 21 04:41:37 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 21 Feb 2013 09:41:37 +0000 (UTC)
Subject: [SciPy-Dev] Splines
References: 
Message-ID: 

Hi,

Charles R Harris  gmail.com> writes:
> There have been several threads on the list about splines
> and consolidation of splines. For instance, there are several
> uniform spline implementations for images and signal processing,
> various low level functions in fitlib that are unexposed, and
> perhaps useful altenatives to b-splines for some applications
> like straight interpolation. For myself, I've started implementing
> several functions in pure Python with an eye to converting them
> to Cython once the interface and documentation is in place,
> mostly for doing things that fitpack doesn't do because it is
> very integrated, as opposed to supplying a basic toolset.
> As part of this project, I'd like to get some feedback
> on which functions people use most and what features they
> would like to see. I'm not interested in the high level classes
> at this point, either the current classes or combo functions
> like fpcurf, but rather a collection of good lower level function
> that could be used to implement the higher level functions
> in a more flexible way. Thoughts?

Great! I was going to start on this for 0.13.0, but this should
speed things up considerably :)

Overall, I think what we need is are (i) a well-specified spline
format, and (ii) solid basic functions for evaluating and
manipulating them, (iii) ditto for tensor product splines.

How to construct the splines (interpolation, smoothing, etc.) should
be considered as a separate problem. We can turn to FITPACK for
smoothing splines, but it should not be used for interpolating 
splines.

    ***

Some misc thoughts on this:

* The spline data format should be documented and set in
stone as a first step. Users (and future developers) will
want to toy around with it.

Also, the data format for tensor product N-dim splines needs
to be set. They are what we are missing, and what people are
constantly asking for. We don't want them turn to
`ndimage.map_coordinates`, which is clunky to use.

The Fitpack tck format looks like this:

https://github.com/pv/scipy-work/commits/spline-unify

Currently, there's also a second B-spline data format used in
scipy.interpolate with different padding, but we may want to
stick with the FITPACK one, it's probably as good as any.

* Functions for splines with varying x-coordinates are needed.
Uniform grid splines would be a nice bonus as a speed-gain
optimization.

* The 1-D spline routines should be able to work over an
arbitrary axis of multidimensional data. Even better if this
can be done without reshaping and copying the input data
(e.g. with Numpy iterators).

This sounds like providing strided 1-D loops for heavy lifting,
and bolting array iterators on top.

* Functions for integration + differentiation of splines
as as abstract objects would be useful. For efficiency,
evaluation of derivatives & integrals probably might need
to be provided separately.

* For tensor product splines, evaluation on a scattered point
set + on a grid would be useful.

* It will probably be easiest to start from a clean slate,
rather than trying to reuse scipy.interpolate.

* FITPACK should not be used as a basis for this work, no
need to use ancient FORTRAN 77 code for simple stuff. We can
use its routines for generating smoothing splines, though.

* Routines for constructing interpolating splines --- I think most
of the time people will use these for simple gridded data interpolation
rather than smoothing. FITPACK's knot selection is nice when it works,
but often it doesn't (or requires careful fiddling), so we should have
something simple and robust as a default algorithm.

* I'm not sure what to do with the various boundary conditions
and out-of-bounds value handling. It's probably best to leave room
for various ways to do this...

* Scipy also has two implementations of piecewise polynomials
--- these should be consolidated into one, too.

Cheers,
Pauli




From njs at pobox.com  Thu Feb 21 04:54:51 2013
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 21 Feb 2013 01:54:51 -0800
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
Message-ID: 

I'm not an expert on spline implementation in general, but for statistical
regression applications, we need to be able to evaluate the individual
functions in an arbitrary spline basis at irregular x points, which is not
well supported by the current API. (splev only computes linear combinations
of the full basis set, so to get individual basis functions we have to do
multiple evaluations with linear combinations like [0, 0, 1].) So keeping
this use case in mind would be nice :-).

-n
On 21 Feb 2013 05:57, "Charles R Harris"  wrote:

> Hi All,
>
> There have been several threads on the list about splines and
> consolidation of splines. For instance, there are several uniform spline
> implementations for images and signal processing, various low level
> functions in fitlib that are unexposed, and perhaps useful altenatives to
> b-splines for some applications like straight interpolation. For myself,
> I've started implementing several functions in pure Python with an eye to
> converting them to Cython once the interface and documentation is in place,
> mostly for doing things that fitpack doesn't do because it is very
> integrated, as opposed to supplying a basic toolset. As part of this
> project, I'd like to get some feedback on which functions people use most
> and what features they would like to see. I'm not interested in the high
> level classes at this point, either the current classes or combo functions
> like fpcurf, but rather a collection of good lower level function that
> could be used to implement the higher level functions in a more flexible
> way.
>
> Thoughts?
>
> Chuck
>
> _______________________________________________
> 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 suryak at ieee.org  Thu Feb 21 05:28:43 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Thu, 21 Feb 2013 15:58:43 +0530
Subject: [SciPy-Dev] getting 500 on scipycentral
Message-ID: 

what happened to scipy-central? I am getting 500 Error. Did you take it
down for transferring domains etc?

(Actually, I am a bit busy these days -- require some time to get back to
its work) -- any problem with it? Let me know
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pablo.winant at gmail.com  Thu Feb 21 05:33:33 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 11:33:33 +0100
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
Message-ID: <5125F7FD.7030602@gmail.com>

Hi,

It's good to see people working in that direction. I will be more than 
happy to participate if I can.

As a user : I really wish I had a cubic spline interpolation with 
natural bounding conditions (which implies linear extrapolation). This 
is what is implemented in Matlab's griddedInterpolator and is missing 
from the existing options in scipy (right?). Being able to evaluate the 
derivatives is also a big advantage.

As a developper : there is the Einspline library that has a 
straightforward implementation in C. In particular, the representation 
of spline objects (C structs) and the low-level API are very 
straightforward and may be a good of inspiration. The library is 
currently GPL, but the author told me it could be made BSD if some m4 
macros are removed.
For what it's worth, I have made a simple Cython wrapper around some of 
its functions 
(https://github.com/albop/dolo/tree/master/dolo/numeric/interpolation) 
and was considering repackaging it. I had some other plans (like writing 
code for higher dimensions using some kind of templating, and updating 
SIMD evaluation). If there is a more elegant alternative, I would be 
happy to jump on the bandwagon.
I agree completely about the remarks on the spline format: it should be 
left as simple as possible. Having it isomorphic to C structs would be a 
good thing too as it permits easy experiments with extensions (for 
instance PyCuda kernels)

Best,

Pablo

On 21/02/2013 10:41, Pauli Virtanen wrote:
> Hi,
>
> Charles R Harris  gmail.com> writes:
>> There have been several threads on the list about splines
>> and consolidation of splines. For instance, there are several
>> uniform spline implementations for images and signal processing,
>> various low level functions in fitlib that are unexposed, and
>> perhaps useful altenatives to b-splines for some applications
>> like straight interpolation. For myself, I've started implementing
>> several functions in pure Python with an eye to converting them
>> to Cython once the interface and documentation is in place,
>> mostly for doing things that fitpack doesn't do because it is
>> very integrated, as opposed to supplying a basic toolset.
>> As part of this project, I'd like to get some feedback
>> on which functions people use most and what features they
>> would like to see. I'm not interested in the high level classes
>> at this point, either the current classes or combo functions
>> like fpcurf, but rather a collection of good lower level function
>> that could be used to implement the higher level functions
>> in a more flexible way. Thoughts?
> Great! I was going to start on this for 0.13.0, but this should
> speed things up considerably :)
>
> Overall, I think what we need is are (i) a well-specified spline
> format, and (ii) solid basic functions for evaluating and
> manipulating them, (iii) ditto for tensor product splines.
>
> How to construct the splines (interpolation, smoothing, etc.) should
> be considered as a separate problem. We can turn to FITPACK for
> smoothing splines, but it should not be used for interpolating
> splines.
>
>      ***
>
> Some misc thoughts on this:
>
> * The spline data format should be documented and set in
> stone as a first step. Users (and future developers) will
> want to toy around with it.
>
> Also, the data format for tensor product N-dim splines needs
> to be set. They are what we are missing, and what people are
> constantly asking for. We don't want them turn to
> `ndimage.map_coordinates`, which is clunky to use.
>
> The Fitpack tck format looks like this:
>
> https://github.com/pv/scipy-work/commits/spline-unify
>
> Currently, there's also a second B-spline data format used in
> scipy.interpolate with different padding, but we may want to
> stick with the FITPACK one, it's probably as good as any.
>
> * Functions for splines with varying x-coordinates are needed.
> Uniform grid splines would be a nice bonus as a speed-gain
> optimization.
>
> * The 1-D spline routines should be able to work over an
> arbitrary axis of multidimensional data. Even better if this
> can be done without reshaping and copying the input data
> (e.g. with Numpy iterators).
>
> This sounds like providing strided 1-D loops for heavy lifting,
> and bolting array iterators on top.
>
> * Functions for integration + differentiation of splines
> as as abstract objects would be useful. For efficiency,
> evaluation of derivatives & integrals probably might need
> to be provided separately.
>
> * For tensor product splines, evaluation on a scattered point
> set + on a grid would be useful.
>
> * It will probably be easiest to start from a clean slate,
> rather than trying to reuse scipy.interpolate.
>
> * FITPACK should not be used as a basis for this work, no
> need to use ancient FORTRAN 77 code for simple stuff. We can
> use its routines for generating smoothing splines, though.
>
> * Routines for constructing interpolating splines --- I think most
> of the time people will use these for simple gridded data interpolation
> rather than smoothing. FITPACK's knot selection is nice when it works,
> but often it doesn't (or requires careful fiddling), so we should have
> something simple and robust as a default algorithm.
>
> * I'm not sure what to do with the various boundary conditions
> and out-of-bounds value handling. It's probably best to leave room
> for various ways to do this...
>
> * Scipy also has two implementations of piecewise polynomials
> --- these should be consolidated into one, too.
>
> Cheers,
> Pauli
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From robert.kern at gmail.com  Thu Feb 21 06:10:48 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Feb 2013 11:10:48 +0000
Subject: [SciPy-Dev] Splines
In-Reply-To: <5125F7FD.7030602@gmail.com>
References: 
	 <5125F7FD.7030602@gmail.com>
Message-ID: 

On Thu, Feb 21, 2013 at 10:33 AM, Pablo Winant  wrote:
> Hi,
>
> It's good to see people working in that direction. I will be more than
> happy to participate if I can.
>
> As a user : I really wish I had a cubic spline interpolation with
> natural bounding conditions (which implies linear extrapolation). This
> is what is implemented in Matlab's griddedInterpolator and is missing
> from the existing options in scipy (right?). Being able to evaluate the
> derivatives is also a big advantage.
>
> As a developper : there is the Einspline library that has a
> straightforward implementation in C. In particular, the representation
> of spline objects (C structs) and the low-level API are very
> straightforward and may be a good of inspiration. The library is
> currently GPL, but the author told me it could be made BSD if some m4
> macros are removed.

Which macros? The only M4 macros I see are for autoconf, which
shouldn't affect the license of the library itself and wouldn't be
used anyways if Einspline were merged into scipy.

-- 
Robert Kern


From pablo.winant at gmail.com  Thu Feb 21 06:27:40 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 12:27:40 +0100
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	<5125F7FD.7030602@gmail.com>
	
Message-ID: <512604AC.6090500@gmail.com>

On 21/02/2013 12:10, Robert Kern wrote:
> On Thu, Feb 21, 2013 at 10:33 AM, Pablo Winant  wrote:
>> Hi,
>>
>> It's good to see people working in that direction. I will be more than
>> happy to participate if I can.
>>
>> As a user : I really wish I had a cubic spline interpolation with
>> natural bounding conditions (which implies linear extrapolation). This
>> is what is implemented in Matlab's griddedInterpolator and is missing
>> from the existing options in scipy (right?). Being able to evaluate the
>> derivatives is also a big advantage.
>>
>> As a developper : there is the Einspline library that has a
>> straightforward implementation in C. In particular, the representation
>> of spline objects (C structs) and the low-level API are very
>> straightforward and may be a good of inspiration. The library is
>> currently GPL, but the author told me it could be made BSD if some m4
>> macros are removed.
> Which macros? The only M4 macros I see are for autoconf, which
> shouldn't affect the license of the library itself and wouldn't be
> used anyways if Einspline were merged into scipy.
>
Well, I didn't know that. The author was indeed refering to the autoconf 
macros and said there was room to modernize the build system anyway. So 
it's not worth the effort ? That would be one problem less.

Not sure whether merging it as it is would be a good idea. There is a 
lot code repetition that make it hard to maintain. But it is 
conceptually very simple and the code it could be greatly simplified 
maybe using some code generation.


From pav at iki.fi  Thu Feb 21 06:41:13 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 21 Feb 2013 11:41:13 +0000 (UTC)
Subject: [SciPy-Dev] Splines
References: 
	
	<5125F7FD.7030602@gmail.com>
	
	<512604AC.6090500@gmail.com>
Message-ID: 

Pablo Winant  gmail.com> writes:
[clip]
> Not sure whether merging it as it is would be a good idea. There is a 
> lot code repetition that make it hard to maintain. But it is 
> conceptually very simple and the code it could be greatly simplified 
> maybe using some code generation.

It's limited to ndim <= 3, which would be too restrictive at least for
me. Being a bit more ambitious than using this library could pay off,
although I'm sure good ideas would come from looking at its implementation.

-- 
Pauli Virtanen



From pablo.winant at gmail.com  Thu Feb 21 06:52:42 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 12:52:42 +0100
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	<5125F7FD.7030602@gmail.com>
	
	<512604AC.6090500@gmail.com>
	
Message-ID: <51260A8A.6000101@gmail.com>

On 21/02/2013 12:41, Pauli Virtanen wrote:
> Pablo Winant  gmail.com> writes:
> [clip]
>> Not sure whether merging it as it is would be a good idea. There is a
>> lot code repetition that make it hard to maintain. But it is
>> conceptually very simple and the code it could be greatly simplified
>> maybe using some code generation.
> It's limited to ndim <= 3, which would be too restrictive at least for
> me. Being a bit more ambitious than using this library could pay off,
> although I'm sure good ideas would come from looking at its implementation.
>

<=3 too restricted for me too. That's why code generation could be used 
for dimension >=4 and it would certainly have excellent performance.
Apart from that I agree that a more general implementation is desirable.


From pablo.winant at gmail.com  Thu Feb 21 07:08:46 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 13:08:46 +0100
Subject: [SciPy-Dev] Multilinear interpolation
Message-ID: <51260E4E.4010405@gmail.com>

Hi,

Continuing a series of thread about interpolation, I have an almost 
ready implementation of multilinear implementation, that is linear 
interpolation in each dimension.  I have been toying with several 
implementations

- in pure numpy (quite memory hungry)
- in cython
- using pycuda

Obviously, if there is some interest for it in scipy, it would be a good 
motivation to finish it. There are two main differences with respect to 
the existing interp routine :

- it is independent of fitpack
- it extrapolates linearly while the existing routine returns a constant 
(or NaN)

Now I have some questions about it:

- in this case I several implementations, in the same library that can 
potentially be enabled on different systems (with a compiler, with a 
gpu). I made a python file that tries to import one version after all 
shadowing slower ones by faster ones. It is meant to replicate the 
.m/.mex file behavior of Matlab. Is there a better approach ?
- the cython code is meant to operate on double* inputs, and is limited 
to 4 dimensions. It is however very easy to generate single or higher 
order code. What would you use for that purpose ?

Best,

Pablo


From charlesr.harris at gmail.com  Thu Feb 21 08:45:49 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 06:45:49 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
Message-ID: 

On Thu, Feb 21, 2013 at 2:41 AM, Pauli Virtanen  wrote:

> Hi,
>
> Charles R Harris  gmail.com> writes:
> > There have been several threads on the list about splines
> > and consolidation of splines. For instance, there are several
> > uniform spline implementations for images and signal processing,
> > various low level functions in fitlib that are unexposed, and
> > perhaps useful altenatives to b-splines for some applications
> > like straight interpolation. For myself, I've started implementing
> > several functions in pure Python with an eye to converting them
> > to Cython once the interface and documentation is in place,
> > mostly for doing things that fitpack doesn't do because it is
> > very integrated, as opposed to supplying a basic toolset.
> > As part of this project, I'd like to get some feedback
> > on which functions people use most and what features they
> > would like to see. I'm not interested in the high level classes
> > at this point, either the current classes or combo functions
> > like fpcurf, but rather a collection of good lower level function
> > that could be used to implement the higher level functions
> > in a more flexible way. Thoughts?
>
> Great! I was going to start on this for 0.13.0, but this should
> speed things up considerably :)
>
>
Heh. The time has come :)


> Overall, I think what we need is are (i) a well-specified spline
> format, and (ii) solid basic functions for evaluating and
> manipulating them, (iii) ditto for tensor product splines.
>

We probably need more than one, I'd guess at least two, b-splines and
piecewise polynomials, with conversion from b-splines to piecewise.


> How to construct the splines (interpolation, smoothing, etc.) should
> be considered as a separate problem. We can turn to FITPACK for
> smoothing splines, but it should not be used for interpolating
> splines.
>
>
Agree. In particular, the construction of splines with optimal knot
positions is an ongoing research area with no generally useful solution as
far as I know, although there are some interesting papers out there.


>     ***
>
> Some misc thoughts on this:
>
> * The spline data format should be documented and set in
> stone as a first step. Users (and future developers) will
> want to toy around with it.
>

We will probably want a least two formats, maybe three: b-splines, uniform
b-splines, and piecewise polynomials. The format should contain the minimal
data needed to specify the spline. For b-splines I don't see a problem with
the (t,c,k) format for 1-D, but for gridded data in higher dimensions we
might want t and k to be lists and c to be a multidimensional array. That
format can also be adapted for uniform splines, but as the latter have
enough simplifying properties that it might be better to have a separate
format for them.


>
> Also, the data format for tensor product N-dim splines needs
> to be set. They are what we are missing, and what people are
> constantly asking for. We don't want them turn to
> `ndimage.map_coordinates`, which is clunky to use.
>
> The Fitpack tck format looks like this:
>
> https://github.com/pv/scipy-work/commits/spline-unify
>
>
That class is already pretty high level ;)


> Currently, there's also a second B-spline data format used in
> scipy.interpolate with different padding, but we may want to
> stick with the FITPACK one, it's probably as good as any.
>
> * Functions for splines with varying x-coordinates are needed.
> Uniform grid splines would be a nice bonus as a speed-gain
> optimization.
>
> * The 1-D spline routines should be able to work over an
> arbitrary axis of multidimensional data. Even better if this
> can be done without reshaping and copying the input data
> (e.g. with Numpy iterators).
>
> This sounds like providing strided 1-D loops for heavy lifting,
> and bolting array iterators on top.
>
> * Functions for integration + differentiation of splines
> as as abstract objects would be useful. For efficiency,
> evaluation of derivatives & integrals probably might need
> to be provided separately.
>

Agree, but I'd make all these functions separate and also have a conversion
function from b-splines to piecewise polynomial representation.


>
> * For tensor product splines, evaluation on a scattered point
> set + on a grid would be useful.
>
> * It will probably be easiest to start from a clean slate,
> rather than trying to reuse scipy.interpolate.
>
>
Yes.


> * FITPACK should not be used as a basis for this work, no
> need to use ancient FORTRAN 77 code for simple stuff. We can
> use its routines for generating smoothing splines, though.
>
>
Not to mention it is hard to read these days with the goto's, minimal
indentation, and portmanteau functions.


> * Routines for constructing interpolating splines --- I think most
> of the time people will use these for simple gridded data interpolation
> rather than smoothing. FITPACK's knot selection is nice when it works,
> but often it doesn't (or requires careful fiddling), so we should have
> something simple and robust as a default algorithm.
>
> * I'm not sure what to do with the various boundary conditions
> and out-of-bounds value handling. It's probably best to leave room
> for various ways to do this...
>
> * Scipy also has two implementations of piecewise polynomials
> --- these should be consolidated into one, too.
>
>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From charlesr.harris at gmail.com  Thu Feb 21 08:47:50 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 06:47:50 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
Message-ID: 

On Thu, Feb 21, 2013 at 2:54 AM, Nathaniel Smith  wrote:

> I'm not an expert on spline implementation in general, but for statistical
> regression applications, we need to be able to evaluate the individual
> functions in an arbitrary spline basis at irregular x points, which is not
> well supported by the current API. (splev only computes linear combinations
> of the full basis set, so to get individual basis functions we have to do
> multiple evaluations with linear combinations like [0, 0, 1].) So keeping
> this use case in mind would be nice :-).
>
> 

Can you be more specific here? Design matrices?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From charlesr.harris at gmail.com  Thu Feb 21 08:50:25 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 06:50:25 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: <5125F7FD.7030602@gmail.com>
References: 
	
	<5125F7FD.7030602@gmail.com>
Message-ID: 

On Thu, Feb 21, 2013 at 3:33 AM, Pablo Winant wrote:

> Hi,
>
> It's good to see people working in that direction. I will be more than
> happy to participate if I can.
>
> As a user : I really wish I had a cubic spline interpolation with
> natural bounding conditions (which implies linear extrapolation). This
> is what is implemented in Matlab's griddedInterpolator and is missing
> from the existing options in scipy (right?). Being able to evaluate the
> derivatives is also a big advantage.
>
> As a developper : there is the Einspline library that has a
> straightforward implementation in C. In particular, the representation
> of spline objects (C structs) and the low-level API are very
> straightforward and may be a good of inspiration. The library is
> currently GPL, but the author told me it could be made BSD if some m4
> macros are removed.
> For what it's worth, I have made a simple Cython wrapper around some of
> its functions
> (https://github.com/albop/dolo/tree/master/dolo/numeric/interpolation)
> and was considering repackaging it. I had some other plans (like writing
> code for higher dimensions using some kind of templating, and updating
> SIMD evaluation). If there is a more elegant alternative, I would be
> happy to jump on the bandwagon.
> I agree completely about the remarks on the spline format: it should be
> left as simple as possible. Having it isomorphic to C structs would be a
> good thing too as it permits easy experiments with extensions (for
> instance PyCuda kernels)
>

C structs tend to be non-portable, although we could work around that. Do
you use PyCuda? Is it mostly float32?



Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From josef.pktd at gmail.com  Thu Feb 21 08:51:10 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 21 Feb 2013 08:51:10 -0500
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	
Message-ID: 

On Thu, Feb 21, 2013 at 8:47 AM, Charles R Harris
 wrote:
>
>
> On Thu, Feb 21, 2013 at 2:54 AM, Nathaniel Smith  wrote:
>>
>> I'm not an expert on spline implementation in general, but for statistical
>> regression applications, we need to be able to evaluate the individual
>> functions in an arbitrary spline basis at irregular x points, which is not
>> well supported by the current API. (splev only computes linear combinations
>> of the full basis set, so to get individual basis functions we have to do
>> multiple evaluations with linear combinations like [0, 0, 1].) So keeping
>> this use case in mind would be nice :-).
>
> 
>
> Can you be more specific here? Design matrices?

The spline analog of np.vander.

Once we have the basis function as a design matrix, we can use all the
regular tools for linear model estimation (statsmodels).
number of knots usually considerably smaller than number of
observations for penalized or smoothing splines.

That's what I see, and Nathaniel might have in mind.

Josef

>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From kgdunn at gmail.com  Thu Feb 21 08:50:40 2013
From: kgdunn at gmail.com (Kevin Dunn)
Date: Thu, 21 Feb 2013 08:50:40 -0500
Subject: [SciPy-Dev] getting 500 on scipycentral
In-Reply-To: 
References: 
Message-ID: 

On Thu, Feb 21, 2013 at 5:28 AM, Surya Kasturi  wrote:

> what happened to scipy-central? I am getting 500 Error. Did you take it
> down for transferring domains etc?
>
> (Actually, I am a bit busy these days -- require some time to get back to
> its work) -- any problem with it? Let me know
>
>
This is not due to the domain transfer; it is due to an issue on the server
at the webhost that periodically shows up. The site is available now.

The domains have been transferred to NumFOCUS though; was initiated
yesterday.
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From charlesr.harris at gmail.com  Thu Feb 21 08:53:37 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 06:53:37 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	
	
Message-ID: 

On Thu, Feb 21, 2013 at 6:51 AM,  wrote:

> On Thu, Feb 21, 2013 at 8:47 AM, Charles R Harris
>  wrote:
> >
> >
> > On Thu, Feb 21, 2013 at 2:54 AM, Nathaniel Smith  wrote:
> >>
> >> I'm not an expert on spline implementation in general, but for
> statistical
> >> regression applications, we need to be able to evaluate the individual
> >> functions in an arbitrary spline basis at irregular x points, which is
> not
> >> well supported by the current API. (splev only computes linear
> combinations
> >> of the full basis set, so to get individual basis functions we have to
> do
> >> multiple evaluations with linear combinations like [0, 0, 1].) So
> keeping
> >> this use case in mind would be nice :-).
> >
> > 
> >
> > Can you be more specific here? Design matrices?
>
> The spline analog of np.vander.
>

OK, that was the first function I wrote ;)


>
> Once we have the basis function as a design matrix, we can use all the
> regular tools for linear model estimation (statsmodels).
> number of knots usually considerably smaller than number of
> observations for penalized or smoothing splines.
>
> That's what I see, and Nathaniel might have in mind.
>
>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From robert.kern at gmail.com  Thu Feb 21 08:54:41 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Feb 2013 13:54:41 +0000
Subject: [SciPy-Dev] Introduction and feature proposal.
In-Reply-To: <51256ABD.2040908@gmail.com>
References: <51256ABD.2040908@gmail.com>
Message-ID: 

On Thu, Feb 21, 2013 at 12:30 AM, Christopher Miller
 wrote:
> Hello,
>
> My name is Chris Miller and I'm a recent applied math PhD from
> University of Maryland. I have some matlab and C/C++ code for computing
> multi-dimensional integrals using Smolyak sparse grids that I think
> might fit well inside scipy.integrate. Sparse grid quadrature delays the
> onset of the so called "curse of dimensionality," and is very efficient
> for evaluating integrals with a 'moderate' number of variables, say
> ~<50. Sparse grids rules can also be tailored to perform integration
> with respect to various measures (uniform, Gaussian, beta-distribution,
> etc.). I'd appreciate any feedback on whether or not people would find
> this useful.

That sounds really cool! Yes, please!

-- 
Robert Kern


From pablo.winant at gmail.com  Thu Feb 21 09:12:33 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 15:12:33 +0100
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	<5125F7FD.7030602@gmail.com>
	
Message-ID: <51262B51.8030707@gmail.com>

On 21/02/2013 14:50, Charles R Harris wrote:
>
>
> On Thu, Feb 21, 2013 at 3:33 AM, Pablo Winant  > wrote:
>
>     Hi,
>
>     It's good to see people working in that direction. I will be more than
>     happy to participate if I can.
>
>     As a user : I really wish I had a cubic spline interpolation with
>     natural bounding conditions (which implies linear extrapolation). This
>     is what is implemented in Matlab's griddedInterpolator and is missing
>     from the existing options in scipy (right?). Being able to
>     evaluate the
>     derivatives is also a big advantage.
>
>     As a developper : there is the Einspline library that has a
>     straightforward implementation in C. In particular, the representation
>     of spline objects (C structs) and the low-level API are very
>     straightforward and may be a good of inspiration. The library is
>     currently GPL, but the author told me it could be made BSD if some m4
>     macros are removed.
>     For what it's worth, I have made a simple Cython wrapper around
>     some of
>     its functions
>     (https://github.com/albop/dolo/tree/master/dolo/numeric/interpolation)
>     and was considering repackaging it. I had some other plans (like
>     writing
>     code for higher dimensions using some kind of templating, and updating
>     SIMD evaluation). If there is a more elegant alternative, I would be
>     happy to jump on the bandwagon.
>     I agree completely about the remarks on the spline format: it
>     should be
>     left as simple as possible. Having it isomorphic to C structs
>     would be a
>     good thing too as it permits easy experiments with extensions (for
>     instance PyCuda kernels)
>
>
> C structs tend to be non-portable, although we could work around that. 
> Do you use PyCuda? Is it mostly float32?

I am experimenting with both float32/float64. Ideally, I would like to 
focus on float64, but gpu devices that work well with that precision are 
much more expensive.

Although, I have used PyCuda so far my concern is also valid with PyCuda 
or any other SIMD framework. I think that performance is a very 
important issue for that kind of computation, and I wonder how hard it 
will be to write a GPU kernel using the objects you implement.
Ideally the spline data would be in a simple format that can be passed 
to these kernels. I think C structs are supported by kernels (at least 
cuda), but I don't know about other kinds of data. It may well be that 
conversion is trivial.

Another example. The evaluation routine written in python could be 
automatically compiled by, say, Numba. In the future, it  will have 
support for GPU computing so that would be an elegant way to compile an 
efficient interpolation function, by adjusting the code only marginally. 
Again, I guess it puts some restriction on the data type.

This may not be the primarly objective of your work (as scipy doesn't do 
gpu computing), but when I hear that a clean complete rewrite is on its 
way, it's tempting to think how the code could be made to work on these 
usecases, with little effort.

>
> 
>
> Chuck
>
>
>
> _______________________________________________
> 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 robert.kern at gmail.com  Thu Feb 21 09:14:00 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Feb 2013 14:14:00 +0000
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: <51260E4E.4010405@gmail.com>
References: <51260E4E.4010405@gmail.com>
Message-ID: 

On Thu, Feb 21, 2013 at 12:08 PM, Pablo Winant  wrote:
> Hi,
>
> Continuing a series of thread about interpolation, I have an almost
> ready implementation of multilinear implementation, that is linear
> interpolation in each dimension.  I have been toying with several
> implementations
>
> - in pure numpy (quite memory hungry)
> - in cython
> - using pycuda
>
> Obviously, if there is some interest for it in scipy, it would be a good
> motivation to finish it.

Yes, please! I have had to rewrite such an implementation a couple of
times already. Just to be clear, by "multilinear" interpolation, do
you mean that you are given a set of values on an orthogonal, but
otherwise irregular N-dimensional grid? Then on the interior of each
grid cell, you do linear interpolation for each axis in turn using the
grid points of the cell, generalizing bilinear interpolation?

Here is the implementation that I keep using, which (ab)uses
ndimage.map_coordinates():

import numpy as np
from scipy import ndimage

def nlinear(x, yp, axes):
    coords = []
    for i in range(x.shape[-1]):
        coords.append(np.interp(x[..., i], axes[i], np.arange(len(axes[i]))))
    coords = np.array(coords)
    return ndimage.map_coordinates(yp, coords, order=1)

> There are two main differences with respect to
> the existing interp routine :
>
> - it is independent of fitpack
> - it extrapolates linearly while the existing routine returns a constant
> (or NaN)
>
> Now I have some questions about it:
>
> - in this case I several implementations, in the same library that can
> potentially be enabled on different systems (with a compiler, with a
> gpu). I made a python file that tries to import one version after all
> shadowing slower ones by faster ones. It is meant to replicate the
> .m/.mex file behavior of Matlab. Is there a better approach ?

I think for scipy, we would just use the plain Cython implementation.
Everyone who installs scipy from source needs a compiler anyways. I
personally don't like GPU versions being used implicitly just because
a GPU is available. I suspect we just wouldn't include the GPU version
in scipy.

> - the cython code is meant to operate on double* inputs, and is limited
> to 4 dimensions. It is however very easy to generate single or higher
> order code. What would you use for that purpose ?

You can take a look at how ndimage does it. It's not pretty.

https://github.com/scipy/scipy/blob/master/scipy/ndimage/src/ni_interpolation.c#L349

--
Robert Kern


From pav at iki.fi  Thu Feb 21 09:19:42 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 21 Feb 2013 14:19:42 +0000 (UTC)
Subject: [SciPy-Dev] Splines
References: 
	
	
Message-ID: 

Charles R Harris  gmail.com> writes:
[clip]
> > https://github.com/pv/scipy-work/commits/spline-unify
> 
> That class is already pretty high level ;)

Well, I was thinking forward on how to force spleval/UnivariateSpline 
be equivalent, by making (t, c, k) and the spline class interchangeable.
I also started trying to force things into FITPACK, but soon
became convinced that this is not the way to go...

I think you are aiming at a similar design as in numpy.polynomial,
which sounds good to me.

-- 
Pauli Virtanen



From njs at pobox.com  Thu Feb 21 09:33:49 2013
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 21 Feb 2013 06:33:49 -0800
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	
	
Message-ID: 

On 21 Feb 2013 13:51,  wrote:
>
> On Thu, Feb 21, 2013 at 8:47 AM, Charles R Harris
>  wrote:
> >
> >
> > On Thu, Feb 21, 2013 at 2:54 AM, Nathaniel Smith  wrote:
> >>
> >> I'm not an expert on spline implementation in general, but for
statistical
> >> regression applications, we need to be able to evaluate the individual
> >> functions in an arbitrary spline basis at irregular x points, which is
not
> >> well supported by the current API. (splev only computes linear
combinations
> >> of the full basis set, so to get individual basis functions we have to
do
> >> multiple evaluations with linear combinations like [0, 0, 1].) So
keeping
> >> this use case in mind would be nice :-).
> >
> > 
> >
> > Can you be more specific here? Design matrices?
>
> The spline analog of np.vander.
>
> Once we have the basis function as a design matrix, we can use all the
> regular tools for linear model estimation (statsmodels).
> number of knots usually considerably smaller than number of
> observations for penalized or smoothing splines.
>
> That's what I see, and Nathaniel might have in mind.

Yes, that's what I meant.

Bonus points if we can easily get compatible implementations of R's bs()
and ns(). (bs() is trivial, we already have it, just inconveniently; I'm
pretty sure ns() is the same thing with those linear boundary conditions
someone else mentioned up-thread.)

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pablo.winant at gmail.com  Thu Feb 21 09:37:27 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 15:37:27 +0100
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: 
References: <51260E4E.4010405@gmail.com>
	
Message-ID: <51263127.7070306@gmail.com>

On 21/02/2013 15:14, Robert Kern wrote:
> On Thu, Feb 21, 2013 at 12:08 PM, Pablo Winant  wrote:
>> Hi,
>>
>> Continuing a series of thread about interpolation, I have an almost
>> ready implementation of multilinear implementation, that is linear
>> interpolation in each dimension.  I have been toying with several
>> implementations
>>
>> - in pure numpy (quite memory hungry)
>> - in cython
>> - using pycuda
>>
>> Obviously, if there is some interest for it in scipy, it would be a good
>> motivation to finish it.
> Yes, please! I have had to rewrite such an implementation a couple of
> times already. Just to be clear, by "multilinear" interpolation, do
> you mean that you are given a set of values on an orthogonal, but
> otherwise irregular N-dimensional grid? Then on the interior of each
> grid cell, you do linear interpolation for each axis in turn using the
> grid points of the cell, generalizing bilinear interpolation?

Yes exactly.

>
> Here is the implementation that I keep using, which (ab)uses
> ndimage.map_coordinates():
>
> import numpy as np
> from scipy import ndimage
>
> def nlinear(x, yp, axes):
>      coords = []
>      for i in range(x.shape[-1]):
>          coords.append(np.interp(x[..., i], axes[i], np.arange(len(axes[i]))))
>      coords = np.array(coords)
>      return ndimage.map_coordinates(yp, coords, order=1)
>
>> There are two main differences with respect to
>> the existing interp routine :
>>
>> - it is independent of fitpack
>> - it extrapolates linearly while the existing routine returns a constant
>> (or NaN)
>>
>> Now I have some questions about it:
>>
>> - in this case I several implementations, in the same library that can
>> potentially be enabled on different systems (with a compiler, with a
>> gpu). I made a python file that tries to import one version after all
>> shadowing slower ones by faster ones. It is meant to replicate the
>> .m/.mex file behavior of Matlab. Is there a better approach ?
> I think for scipy, we would just use the plain Cython implementation.
> Everyone who installs scipy from source needs a compiler anyways. I
> personally don't like GPU versions being used implicitly just because
> a GPU is available. I suspect we just wouldn't include the GPU version
> in scipy.
OK

>> - the cython code is meant to operate on double* inputs, and is limited
>> to 4 dimensions. It is however very easy to generate single or higher
>> order code. What would you use for that purpose ?
> You can take a look at how ndimage does it. It's not pretty.
>
> https://github.com/scipy/scipy/blob/master/scipy/ndimage/src/ni_interpolation.c#L349
hmm
I hesitate between two options that seem be to be used somewhere in 
scipy : Mako templates and code generation via a simple python module. 
Do you have a preference ?
>
> --
> Robert Kern
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From charlesr.harris at gmail.com  Thu Feb 21 09:46:15 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 07:46:15 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	
	
Message-ID: 

On Thu, Feb 21, 2013 at 7:19 AM, Pauli Virtanen  wrote:

> Charles R Harris  gmail.com> writes:
> [clip]
> > > https://github.com/pv/scipy-work/commits/spline-unify
> >
> > That class is already pretty high level ;)
>
> Well, I was thinking forward on how to force spleval/UnivariateSpline
> be equivalent, by making (t, c, k) and the spline class interchangeable.
> I also started trying to force things into FITPACK, but soon
> became convinced that this is not the way to go...
>
> I think you are aiming at a similar design as in numpy.polynomial,
> which sounds good to me.
>

Well, it's what I'm familiar with ;) I think your work on piecewise
polynomials fits in here somewhere also, but I haven't taken a close look
at that yet.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pav at iki.fi  Thu Feb 21 10:46:36 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 21 Feb 2013 15:46:36 +0000 (UTC)
Subject: [SciPy-Dev] Introduction and feature proposal.
References: <51256ABD.2040908@gmail.com>
Message-ID: 

Christopher Miller  gmail.com> writes:
[clip]
> p.s. Here are some references. Most of my work with these was in solving 
> stochastic PDEs, so the references tilt that way, but they are generally 
> useful tools for multi-dimensional integration/interpolation.
> 
> D. Xiu and J. Hesthaven. High-order collocation methods for differential 
> equa-
> tions with random inputs. SIAM Journal on Scientific Computing, 27:1118?
> 1139, 2005.
> 
> F. Nobile, R. Tempone, and C.G. Webster. An anisotropic sparse grid col-
> location algorithm for the solution of stochastic differential 
> equations. SIAM
> Journal on Numerical Analysis, 46:2411?2442, 2008.

Sparse grid quadratures would be a very welcome addition to 
scipy.integrate. Right now, the only N-dim integration routine
there is via nested 1-D integration, which is not efficient.

Adaptive sparse grids for sampling and interpolation in N dimensions
(of functions slow to evaluate and containing singular points) would
also be interesting for me; currently I'm sticking to ad-hoc
triangulation based methods.

Adapting existing Matlab/C code is usually reasonably
straightforward, feel free to ask if you want particular advice!

-- 
Pauli Virtanen



From pierre.haessig at crans.org  Thu Feb 21 10:48:58 2013
From: pierre.haessig at crans.org (Pierre Haessig)
Date: Thu, 21 Feb 2013 16:48:58 +0100
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
In-Reply-To: <5125633F.909@redtetrahedron.org>
References: <51250575.9060700@crans.org> <5125633F.909@redtetrahedron.org>
Message-ID: <512641EA.1090301@crans.org>

Hi Eric,

Thanks for your feedback !

Le 21/02/2013 00:58, Eric Moore a ?crit :
> I'm not sure that the correct fix would be, perhaps signal.buttap should 
> calculate the poles by calculating half of them, and then conjugating. 
> Since I'd bet that the ultimate cause is that we aren't getting exact 
> conjugates from the complex exponential.
That's right. I just made a quick test inspired by signal.buttap code to
check for this "non conjugate roots issue"
(https://github.com/scipy/scipy/blob/master/scipy/signal/filter_design.py#L1376)

N = 4
n = numpy.arange(1, N + 1)
p = numpy.exp(1j * (2 * n - 1) / (2.0 * N) * pi) * 1j
print(p[0])
print(p[3].conj())
print(p[0] == p[3].conj())
print(p[1])
print(p[2].conj())
print(p[1] == p[2].conj())

gives :
(-0.382683432365+0.923879532511j)
(-0.382683432365+0.923879532511j)
False
(-0.923879532511+0.382683432365j)
(-0.923879532511+0.382683432365j)
False

Roots are indeed conjugate at about 1e-16 but the equality check in
np.poly is an exact check.

Now, it may be possible to write signal.buttap in a bit more complex
fashion to generate true complex conjugate roots but I'm not sure it's a
good to rely on np.poly to make some "smart conjugate detection". In the
new polynomial package I'm not sure this is even implemented (
https://github.com/numpy/numpy/blob/master/numpy/polynomial/polynomial.py#L127).
From my unexerced eye, the code of
numpy.polynomial.polynomial.polyfromroots and numpy.poly looks very
different




Anyway, I would feel better adding calls to np.real *after* calling
zpk2tf (s) inside signal.iirfilter :
a =  np.real(a)
b = np.real(b)
at
https://github.com/scipy/scipy/blob/master/scipy/signal/filter_design.py#L638

Other option is to call np.real *inside* zpk2tf but this makes the
restrictive assumption  that zpk2tf should only manipulate real filters.

What do others think ?

best,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 

From pablo.winant at gmail.com  Thu Feb 21 10:58:39 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Thu, 21 Feb 2013 16:58:39 +0100
Subject: [SciPy-Dev] Introduction and feature proposal.
In-Reply-To: 
References: <51256ABD.2040908@gmail.com>
	
Message-ID: <5126442F.7060708@gmail.com>

On 21/02/2013 14:54, Robert Kern wrote:
> On Thu, Feb 21, 2013 at 12:30 AM, Christopher Miller
>  wrote:
>> Hello,
>>
>> My name is Chris Miller and I'm a recent applied math PhD from
>> University of Maryland. I have some matlab and C/C++ code for computing
>> multi-dimensional integrals using Smolyak sparse grids that I think
>> might fit well inside scipy.integrate. Sparse grid quadrature delays the
>> onset of the so called "curse of dimensionality," and is very efficient
>> for evaluating integrals with a 'moderate' number of variables, say
>> ~<50. Sparse grids rules can also be tailored to perform integration
>> with respect to various measures (uniform, Gaussian, beta-distribution,
>> etc.). I'd appreciate any feedback on whether or not people would find
>> this useful.
> That sounds really cool! Yes, please!
>
I'm very interested by it too, mostly by interpolation routines. How 
does the code you have compare to the "sparse grid interpolation 
toolbox" by andreas Klimke ? This one has adaptive dimensions and 
several types of grid, but I found it quite slow and not very useful 
when repeatedly evaluate an interpolated function.

I also have a piece of code in Python for sparse products of Chebychev 
polynomials : 
https://github.com/albop/dolo/tree/master/dolo/numeric/interpolation 
(sorry to send that link again). It is pure vectorized numpy and I'm 
curious to see how it would compare (have no doubt it is very memory 
hungry).

Pablo


From charlesr.harris at gmail.com  Thu Feb 21 11:53:14 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 09:53:14 -0700
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
In-Reply-To: <512641EA.1090301@crans.org>
References: <51250575.9060700@crans.org> <5125633F.909@redtetrahedron.org>
	<512641EA.1090301@crans.org>
Message-ID: 

On Thu, Feb 21, 2013 at 8:48 AM, Pierre Haessig wrote:

>  Hi Eric,
>
> Thanks for your feedback !
>
> Le 21/02/2013 00:58, Eric Moore a ?crit :
>
> I'm not sure that the correct fix would be, perhaps signal.buttap should
> calculate the poles by calculating half of them, and then conjugating.
> Since I'd bet that the ultimate cause is that we aren't getting exact
> conjugates from the complex exponential.
>
>  That's right. I just made a quick test inspired by signal.buttap code to
> check for this "non conjugate roots issue"
> (
> https://github.com/scipy/scipy/blob/master/scipy/signal/filter_design.py#L1376
> )
>
> N = 4
> n = numpy.arange(1, N + 1)
> p = numpy.exp(1j * (2 * n - 1) / (2.0 * N) * pi) * 1j
> print(p[0])
> print(p[3].conj())
> print(p[0] == p[3].conj())
> print(p[1])
> print(p[2].conj())
> print(p[1] == p[2].conj())
>
> gives :
> (-0.382683432365+0.923879532511j)
> (-0.382683432365+0.923879532511j)
> False
> (-0.923879532511+0.382683432365j)
> (-0.923879532511+0.382683432365j)
> False
>
> Roots are indeed conjugate at about 1e-16 but the equality check in
> np.poly is an exact check.
>
> Now, it may be possible to write signal.buttap in a bit more complex
> fashion to generate true complex conjugate roots but I'm not sure it's a
> good to rely on np.poly to make some "smart conjugate detection". In the
> new polynomial package I'm not sure this is even implemented (
> https://github.com/numpy/numpy/blob/master/numpy/polynomial/polynomial.py#L127).
> From my unexerced eye, the code of
> numpy.polynomial.polynomial.polyfromroots and numpy.poly looks very
> different
>

The multiplications in numpy/polynomial/polynomial are done as a sort of
binary tree, multiplying successively higher degree polynomials together
while trying to keep the roots in each widely separated so as to minimize
numerical error, but it make no attempt to detect conjugate roots. It
probably needs an `asreal` attribute so the user, who knows more about the
problem than the computer, can specify the type of the result.



Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From pierre.haessig at crans.org  Thu Feb 21 12:03:39 2013
From: pierre.haessig at crans.org (Pierre Haessig)
Date: Thu, 21 Feb 2013 18:03:39 +0100
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
In-Reply-To: 
References: <51250575.9060700@crans.org> <5125633F.909@redtetrahedron.org>
	<512641EA.1090301@crans.org>
	
Message-ID: <5126536B.2090800@crans.org>

Hi Chuck,

Le 21/02/2013 17:53, Charles R Harris a ?crit :
>
>     Now, it may be possible to write signal.buttap in a bit more
>     complex fashion to generate true complex conjugate roots but I'm
>     not sure it's a good to rely on np.poly to make some "smart
>     conjugate detection". In the new polynomial package I'm not sure
>     this is even implemented (
>     https://github.com/numpy/numpy/blob/master/numpy/polynomial/polynomial.py#L127).
>     From my unexerced eye, the code of
>     numpy.polynomial.polynomial.polyfromroots and numpy.poly looks
>     very different
>
>
> The multiplications in numpy/polynomial/polynomial are done as a sort
> of binary tree, multiplying successively higher degree polynomials
> together while trying to keep the roots in each widely separated so as
> to minimize numerical error, but it make no attempt to detect
> conjugate roots. It probably needs an `asreal` attribute so the user,
> who knows more about the problem than the computer, can specify the
> type of the result.
I fully agree with this "explicit better than implicit" approach.
(and thanks for the explanation of the iterative construction of the
polynomial)

Do you think `asreal` it would be a useful addition to polyfromroots or
is it better to just call np.real in signal.iirfilter ?

best,
Pierre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 

From robert.kern at gmail.com  Thu Feb 21 14:01:04 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Feb 2013 19:01:04 +0000
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: <51263127.7070306@gmail.com>
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
Message-ID: 

On Thu, Feb 21, 2013 at 2:37 PM, Pablo Winant  wrote:

> I hesitate between two options that seem be to be used somewhere in
> scipy : Mako templates and code generation via a simple python module.
> Do you have a preference ?

Since we're already using Mako in scipy.interpolate, I would recommend
giving it a try.

-- 
Robert Kern


From pav at iki.fi  Thu Feb 21 14:04:57 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 21 Feb 2013 21:04:57 +0200
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: 
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
Message-ID: 

21.02.2013 21:01, Robert Kern kirjoitti:
> On Thu, Feb 21, 2013 at 2:37 PM, Pablo Winant  wrote:
> 
>> I hesitate between two options that seem be to be used somewhere in
>> scipy : Mako templates and code generation via a simple python module.
>> Do you have a preference ?
> 
> Since we're already using Mako in scipy.interpolate, I would recommend
> giving it a try.

We're actually not using Mako any more. Using Tempita instead could be
better, as that we can bundle with Scipy.

-- 
Pauli Virtanen



From robert.kern at gmail.com  Thu Feb 21 14:25:18 2013
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 21 Feb 2013 19:25:18 +0000
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: 
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
	
Message-ID: 

On Thu, Feb 21, 2013 at 7:04 PM, Pauli Virtanen  wrote:
> 21.02.2013 21:01, Robert Kern kirjoitti:
>> On Thu, Feb 21, 2013 at 2:37 PM, Pablo Winant  wrote:
>>
>>> I hesitate between two options that seem be to be used somewhere in
>>> scipy : Mako templates and code generation via a simple python module.
>>> Do you have a preference ?
>>
>> Since we're already using Mako in scipy.interpolate, I would recommend
>> giving it a try.
>
> We're actually not using Mako any more. Using Tempita instead could be
> better, as that we can bundle with Scipy.

Sorry, I had an old checkout. Pablo, do check out Tempita, then. It is
pretty nice:

  http://pythonpaste.org/tempita/

--
Robert Kern


From cmiller730 at gmail.com  Thu Feb 21 14:28:30 2013
From: cmiller730 at gmail.com (Christopher Miller)
Date: Thu, 21 Feb 2013 14:28:30 -0500
Subject: [SciPy-Dev] Introduction and feature proposal.
In-Reply-To: <5126442F.7060708@gmail.com>
References: <51256ABD.2040908@gmail.com>
	
	<5126442F.7060708@gmail.com>
Message-ID: 

I haven't looked at his code is a good while and it appears to have matured
a lot since then, so my past judgements may no longer apply.  In the past
I'd noticed the same thing you had, namely that grid generation and
interpolation was rather slow.  Grid generation in particular became very
slow for large dimensional grids. My C/C++ codes for grid generation are
based on algorithms from Sandia's "Dakota" software.  At the time they
significantly out performed Klimke's toolbox.

I also had support for hierarchical grids with piecewise linear or
piecewise cubic Hermite interpolants which I don't think Klimke had at the
time (though his thesis featured these types of grids extensively so he may
have included them since).

The 'killer app' in my codes was support for grid generation for
integrating with respect to arbitrary product measures.  This was
accomplished by numerically approximating the one dimensional orthogonal
polynomials in each dimension and then creating a sparse grid based on the
derived Gaussian quadrature rules. This currently exists in an evolved form
inside Sandia's "Stokhos" package.

I'd prefer to begin with a fixed isotropic grid types, Clenshaw-Curtis,
Gauss-Legendre, Gauss-Hermite, then move to the anisotropic perhaps with
options to compute the anisotropic weights at runtime. Following that I'd
bring in the adaptive hierarchical grids.

Chris


On Thu, Feb 21, 2013 at 10:58 AM, Pablo Winant wrote:

> On 21/02/2013 14:54, Robert Kern wrote:
> > On Thu, Feb 21, 2013 at 12:30 AM, Christopher Miller
> >  wrote:
> >> Hello,
> >>
> >> My name is Chris Miller and I'm a recent applied math PhD from
> >> University of Maryland. I have some matlab and C/C++ code for computing
> >> multi-dimensional integrals using Smolyak sparse grids that I think
> >> might fit well inside scipy.integrate. Sparse grid quadrature delays the
> >> onset of the so called "curse of dimensionality," and is very efficient
> >> for evaluating integrals with a 'moderate' number of variables, say
> >> ~<50. Sparse grids rules can also be tailored to perform integration
> >> with respect to various measures (uniform, Gaussian, beta-distribution,
> >> etc.). I'd appreciate any feedback on whether or not people would find
> >> this useful.
> > That sounds really cool! Yes, please!
> >
> I'm very interested by it too, mostly by interpolation routines. How
> does the code you have compare to the "sparse grid interpolation
> toolbox" by andreas Klimke ? This one has adaptive dimensions and
> several types of grid, but I found it quite slow and not very useful
> when repeatedly evaluate an interpolated function.
>
> I also have a piece of code in Python for sparse products of Chebychev
> polynomials :
> https://github.com/albop/dolo/tree/master/dolo/numeric/interpolation
> (sorry to send that link again). It is pure vectorized numpy and I'm
> curious to see how it would compare (have no doubt it is very memory
> hungry).
>
> Pablo
> _______________________________________________
> 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 charlesr.harris at gmail.com  Thu Feb 21 16:11:05 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 21 Feb 2013 14:11:05 -0700
Subject: [SciPy-Dev] scipy.signal.butter returns complex coefficients
In-Reply-To: <5126536B.2090800@crans.org>
References: <51250575.9060700@crans.org> <5125633F.909@redtetrahedron.org>
	<512641EA.1090301@crans.org>
	
	<5126536B.2090800@crans.org>
Message-ID: 

On Thu, Feb 21, 2013 at 10:03 AM, Pierre Haessig
wrote:

>  Hi Chuck,
>
> Le 21/02/2013 17:53, Charles R Harris a ?crit :
>
>  Now, it may be possible to write signal.buttap in a bit more complex
>> fashion to generate true complex conjugate roots but I'm not sure it's a
>> good to rely on np.poly to make some "smart conjugate detection". In the
>> new polynomial package I'm not sure this is even implemented (
>> https://github.com/numpy/numpy/blob/master/numpy/polynomial/polynomial.py#L127).
>> From my unexerced eye, the code of
>> numpy.polynomial.polynomial.polyfromroots and numpy.poly looks very
>> different
>>
>
> The multiplications in numpy/polynomial/polynomial are done as a sort of
> binary tree, multiplying successively higher degree polynomials together
> while trying to keep the roots in each widely separated so as to minimize
> numerical error, but it make no attempt to detect conjugate roots. It
> probably needs an `asreal` attribute so the user, who knows more about the
> problem than the computer, can specify the type of the result.
>
> I fully agree with this "explicit better than implicit" approach.
> (and thanks for the explanation of the iterative construction of the
> polynomial)
>
> Do you think `asreal` it would be a useful addition to polyfromroots or is
> it better to just call np.real in signal.iirfilter ?
>

I think it, or something with a similar name, should be added, but it won't
be available until the next release at a minimum. So, taking the real part
of the coefficients is probably the way to go. I'm trying to recall which
release the polynomial functions went in... looks like 1.5, so that should
be OK for scipy.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From charlesr.harris at gmail.com  Fri Feb 22 22:49:01 2013
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 22 Feb 2013 20:49:01 -0700
Subject: [SciPy-Dev] Splines
In-Reply-To: 
References: 
	
	
	
	
Message-ID: 

On Thu, Feb 21, 2013 at 7:46 AM, Charles R Harris  wrote:

>
>
> On Thu, Feb 21, 2013 at 7:19 AM, Pauli Virtanen  wrote:
>
>> Charles R Harris  gmail.com> writes:
>> [clip]
>> > > https://github.com/pv/scipy-work/commits/spline-unify
>> >
>> > That class is already pretty high level ;)
>>
>> Well, I was thinking forward on how to force spleval/UnivariateSpline
>> be equivalent, by making (t, c, k) and the spline class interchangeable.
>> I also started trying to force things into FITPACK, but soon
>> became convinced that this is not the way to go...
>>
>> I think you are aiming at a similar design as in numpy.polynomial,
>> which sounds good to me.
>>
>
> Well, it's what I'm familiar with ;) I think your work on piecewise
> polynomials fits in here somewhere also, but I haven't taken a close look
> at that yet.
>
>
I've put up a working repository at https://github.com/charris/bsplines.
There are some preliminary python routines for evaluating splines and such,
sort of pseudo C'ish which makes them really slow on account of all the
indexing, but maybe easier to cythonize. Anyone who is interested can take
a look and join in. Flaming welcome :) Also constructive comments/work.
Everything is 1-D at the moment until things settle down a bit.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ralf.gommers at gmail.com  Sun Feb 24 15:41:59 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sun, 24 Feb 2013 21:41:59 +0100
Subject: [SciPy-Dev] Like to contribute to Scipy
In-Reply-To: 
References: 
Message-ID: 

On Tue, Feb 19, 2013 at 8:44 AM, anand parthasarathy wrote:

> Hi,
>
> I would like to start contribute to Scipy - signal processing module. I
> have been using MATLAB for a very long time, to the extend that i have
> implemented many signal processing algorithms targeting the applications in
> the field of Communications & wireless PHY Layer .
>
>  I am currently a Research Intern at Centre of Excellence in Wireless
> Technology (CEWiT), India. I am so much fascinated by Scipy and though i am
> new to python, i started love to code in python environment.
>
> Since this field is like a ocean , i would like to get suggestions from
> you guys on this like where to start , and after decided with a specific
> part to work on , i will start and contribute many things to Scipy to the
> extend that i can.
>

Hi Anand, welcome! The signal module certainly could use your
contributions.

The same question you're asking was asked about a month ago by someone
else, please have a look at this thread:
http://thread.gmane.org/gmane.comp.python.scientific.devel/17173 . It
contains a few ideas and pointers for getting started. If you have ideas
for new algorithms/functionality to contribute, I recommend that you first
discuss them on this mailing list to make sure the code you write will be a
good fit for scipy.

If you have more specific questions later, please don't hesitate to ask.

Cheers,
Ralf



>
>
>
>
>
>
> Regards,
> Anand Parthasarathy
>
>
>
> _______________________________________________
> 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 pablo.winant at gmail.com  Mon Feb 25 07:04:13 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Mon, 25 Feb 2013 13:04:13 +0100
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: 
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
	
	
Message-ID: <512B533D.1000105@gmail.com>

On 21/02/2013 20:25, Robert Kern wrote:
> On Thu, Feb 21, 2013 at 7:04 PM, Pauli Virtanen  wrote:
>> 21.02.2013 21:01, Robert Kern kirjoitti:
>>> On Thu, Feb 21, 2013 at 2:37 PM, Pablo Winant  wrote:
>>>
>>>> I hesitate between two options that seem be to be used somewhere in
>>>> scipy : Mako templates and code generation via a simple python module.
>>>> Do you have a preference ?
>>> Since we're already using Mako in scipy.interpolate, I would recommend
>>> giving it a try.
>> We're actually not using Mako any more. Using Tempita instead could be
>> better, as that we can bundle with Scipy.
> Sorry, I had an old checkout. Pablo, do check out Tempita, then. It is
> pretty nice:
>
>    http://pythonpaste.org/tempita/

So I made an attempt using tempita in the case of regularly spaced 
grids. For now, it is in a temporary repository in github:

https://github.com/albop/python_interpolation

There is a file multilinear_cython.pyx.in which must be interpreted to 
produce multilinear_cython.pyx . There is also a multilinear.py file 
containing an object oriented wrapper for the compiled routines.

Here is an example:

http://nbviewer.ipython.org/urls/raw.github.com/albop/python_interpolation/master/interpolation.ipynb

Before, I do the same for irregularly spaced grid, I have some questions:
- I included the templates as Python strings in the .pyx.in file . Was 
there a better way ?
- I was not sure about how to deal with single/double precision in the 
cython code.

>
> --
> Robert Kern
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev



From pav at iki.fi  Mon Feb 25 08:32:31 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 25 Feb 2013 13:32:31 +0000 (UTC)
Subject: [SciPy-Dev] Multilinear interpolation
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
	
	
	<512B533D.1000105@gmail.com>
Message-ID: 

Pablo Winant  gmail.com> writes:
[clip]
> So I made an attempt using tempita in the case of regularly spaced 
> grids. For now, it is in a temporary repository in github:
> 
> https://github.com/albop/python_interpolation
[clip]

Some comments:

- "#pragma omp parallel for" statement probably doesn't do
  anything: Cython interprets it as a comment.

- The code assumes C-contiguous arrays, but does not check for it.

- Do you actually need code generation here? The templated loops
  can be replaced by N-dim untemplated loops. The question is
  probably mostly about speed.

- The inner evaluation loop should be inside `with nogil`

[clip]
> Before, I do the same for irregularly spaced grid, I have some questions:
> - I included the templates as Python strings in the .pyx.in file . Was 
> there a better way ?

As the script is executable by Python, the file extension should be .py.
You can either put the template itself to a separate file (.pyx.in) 
--- note that you can put Python code inside tempita templates.
Alternatively, rename the script to `generate_multilinear.py`.

Note that tempita templates can contain executable blocks, so you can 
for instance put some logic there, and use the template syntax for the 
loops.

> - I was not sure about how to deal with single/double precision in the 
> cython code.

You can use fused types instead of templating; the end result is the same,
but Cython takes care of picking the correct routine.

-- 
Pauli Virtanen



From pablo.winant at gmail.com  Mon Feb 25 15:04:10 2013
From: pablo.winant at gmail.com (Pablo Winant)
Date: Mon, 25 Feb 2013 21:04:10 +0100
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: 
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
	
	
	<512B533D.1000105@gmail.com>
	
Message-ID: <512BC3BA.9030506@gmail.com>

On 25/02/2013 14:32, Pauli Virtanen wrote:
> Pablo Winant  gmail.com> writes:
> [clip]
>> So I made an attempt using tempita in the case of regularly spaced
>> grids. For now, it is in a temporary repository in github:
>>
>> https://github.com/albop/python_interpolation
> [clip]
>
> Some comments:
>
> - "#pragma omp parallel for" statement probably doesn't do
>    anything: Cython interprets it as a comment.

yes, my mistake, I intended to write "with nogil, parallel():" instead
> - The code assumes C-contiguous arrays, but does not check for it.
right
> - Do you actually need code generation here? The templated loops
>    can be replaced by N-dim untemplated loops. The question is
>    probably mostly about speed.
I wonder too. The motivation was indeed speed but there may be a better 
way.

> - The inner evaluation loop should be inside `with nogil`
>
> [clip]
>> Before, I do the same for irregularly spaced grid, I have some questions:
>> - I included the templates as Python strings in the .pyx.in file . Was
>> there a better way ?
> As the script is executable by Python, the file extension should be .py.
> You can either put the template itself to a separate file (.pyx.in)
> --- note that you can put Python code inside tempita templates.
> Alternatively, rename the script to `generate_multilinear.py`.
>
> Note that tempita templates can contain executable blocks, so you can
> for instance put some logic there, and use the template syntax for the
> loops.
OK, as the python code is minimal, I will try to include everything in 
the template.

>> - I was not sure about how to deal with single/double precision in the
>> cython code.
> You can use fused types instead of templating; the end result is the same,
> but Cython takes care of picking the correct routine.
>
I tried it but I didn't see how to do it. I would like to do define a 
function like

def function(ndarray[fused_type, ndim=2]):
     ...
     cdef fused_type internal_variable
     ...
     return something


but it doesn't work. From this thread 
[https://groups.google.com/forum/?fromgroups=#!topic/cython-users/GwvZiAdRJpM] 
I understand I should do :

ctypedef fused  myarray:
     ndarray[type1, ndim=2]
     ndarray[type2, ndim=2]

def function(myarray):
     ...
     cdef (?) internal_variable

but then how do I define scalars of the same dtype as the array arguments ?


From pav at iki.fi  Mon Feb 25 15:19:17 2013
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 25 Feb 2013 22:19:17 +0200
Subject: [SciPy-Dev] Multilinear interpolation
In-Reply-To: <512BC3BA.9030506@gmail.com>
References: <51260E4E.4010405@gmail.com>
	
	<51263127.7070306@gmail.com>
	
	
	
	<512B533D.1000105@gmail.com>
	
	<512BC3BA.9030506@gmail.com>
Message-ID: 

25.02.2013 22:04, Pablo Winant kirjoitti:
[clip]
> > - The code assumes C-contiguous arrays, but does not check for it.
>
> right

Note that you can make Cython to check for this, the syntax is
sometype[::1] or sometype[:,::1] for multidim (see below).

[clip]
>> You can use fused types instead of templating; the end result is the same,
>> but Cython takes care of picking the correct routine.
>>
> I tried it but I didn't see how to do it. I would like to do define a 
> function like
> 
> def function(ndarray[fused_type, ndim=2]):
>      ...
>      cdef fused_type internal_variable
>      ...
>      return something

The syntax for these arrays is

	cdef fused number_t:
	    double
	    double complex


	def my_function(fused_type[:,:] arg)
	    ...

I think it doesn't work with the (old) np.ndarray syntax.

-- 
Pauli Virtanen



From ralf.gommers at gmail.com  Wed Feb 27 01:05:28 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 27 Feb 2013 07:05:28 +0100
Subject: [SciPy-Dev] ScipyCentral repo moved
Message-ID: 

Hi all,

The ScipyCentral root repo has been moved from its old home (Kevin Dunn's
Github account) to https://github.com/scipy/SciPyCentral in order to
facility further development of it. Thanks to Kevin for helping with that,
and for all his work on Scipy Central so far. Surya will continue to work
on her new web design in her own repo, and merge it into ScipyCentral when
it's done.

I've created a new Github team with commit rights for that repo - if you
want to be added to that team just ask on this list. If you want to send a
new PR or review an existing one, just go for it!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From suryak at ieee.org  Wed Feb 27 01:24:49 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Wed, 27 Feb 2013 11:54:49 +0530
Subject: [SciPy-Dev] ScipyCentral repo moved
In-Reply-To: 
References: 
Message-ID: 

On Wed, Feb 27, 2013 at 11:35 AM, Ralf Gommers wrote:

> Hi all,
>
> The ScipyCentral root repo has been moved from its old home (Kevin Dunn's
> Github account) to https://github.com/scipy/SciPyCentral in order to
> facility further development of it. Thanks to Kevin for helping with that,
> and for all his work on Scipy Central so far. Surya will continue to work
> on her new web design in her own repo, and merge it into ScipyCentral when
> it's done.
>
> I've created a new Github team with commit rights for that repo - if you
> want to be added to that team just ask on this list. If you want to send a
> new PR or review an existing one, just go for it!
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> I am looking forward to join as a team member.. What do you all guys say?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ralf.gommers at gmail.com  Wed Feb 27 01:51:04 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 27 Feb 2013 07:51:04 +0100
Subject: [SciPy-Dev] ScipyCentral repo moved
In-Reply-To: 
References: 
	
Message-ID: 

On Wed, Feb 27, 2013 at 7:24 AM, Surya Kasturi  wrote:

>
>
>
> On Wed, Feb 27, 2013 at 11:35 AM, Ralf Gommers wrote:
>
>> Hi all,
>>
>> The ScipyCentral root repo has been moved from its old home (Kevin Dunn's
>> Github account) to https://github.com/scipy/SciPyCentral in order to
>> facility further development of it. Thanks to Kevin for helping with that,
>> and for all his work on Scipy Central so far. Surya will continue to work
>> on her new web design in her own repo, and merge it into ScipyCentral when
>> it's done.
>>
>> I've created a new Github team with commit rights for that repo - if you
>> want to be added to that team just ask on this list. If you want to send a
>> new PR or review an existing one, just go for it!
>>
>> Cheers,
>> Ralf
>>
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>> I am looking forward to join as a team member.. What do you all guys say?
>

Definitely. Looking forward to seeing the new design being merged.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From anandps20 at gmail.com  Wed Feb 27 03:53:47 2013
From: anandps20 at gmail.com (anand parthasarathy)
Date: Wed, 27 Feb 2013 14:23:47 +0530
Subject: [SciPy-Dev] Like to contribute to Scipy
In-Reply-To: 
References: 
	
Message-ID: 

Hi ralf,

Thank you for your reply. I am thinking of making the Scipy.signal module
to have the functions for communication, like communication toolbox in
matlab. We could join and can effectively launch packages including
features like Error correction mechanisms, channel functions etc. will this
be useful ?

Else can you point me towards any project involving productive results.






Regards,
Anand parthasarathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kgdunn at gmail.com  Wed Feb 27 09:22:18 2013
From: kgdunn at gmail.com (Kevin Dunn)
Date: Wed, 27 Feb 2013 09:22:18 -0500
Subject: [SciPy-Dev] ScipyCentral repo moved
In-Reply-To: 
References: 
Message-ID: 

On Wed, Feb 27, 2013 at 1:05 AM, Ralf Gommers wrote:

> Hi all,
>
> The ScipyCentral root repo has been moved from its old home (Kevin Dunn's
> Github account) to https://github.com/scipy/SciPyCentral in order to
> facility further development of it. Thanks to Kevin for helping with that,
> and for all his work on Scipy Central so far. Surya will continue to work
> on her new web design in her own repo, and merge it into ScipyCentral when
> it's done.
>
> I've created a new Github team with commit rights for that repo - if you
> want to be added to that team just ask on this list. If you want to send a
> new PR or review an existing one, just go for it!
>
> Cheers,
> Ralf
>

I'm just glad to see the work continued by Surya and others, and wish I had
had the time to keep the website more up to date. Thanks for everyone's
help with the domain name transfers and the Github transfer.

Kevin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From cimrman3 at ntc.zcu.cz  Wed Feb 27 13:19:45 2013
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Wed, 27 Feb 2013 19:19:45 +0100
Subject: [SciPy-Dev] ANN: SfePy 2013.1
Message-ID: <512E4E41.1040906@ntc.zcu.cz>

I am pleased to announce release 2013.1 of SfePy.

Description
-----------
SfePy (simple finite elements in Python) is a software for solving
systems of coupled partial differential equations by the finite element
method. The code is based on NumPy and SciPy packages. It is distributed
under the new BSD license.

Home page: http://sfepy.org
Downloads, mailing list, wiki: http://code.google.com/p/sfepy/
Git (source) repository, issue tracker: http://github.com/sfepy

Highlights of this release
--------------------------
- unified use of stationary and evolutionary solvers
- new implicit adaptive time stepping solver
- elements of set and nodes of set region selectors
- simplified setting of variables data

For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).

Best regards,
Robert Cimrman and Contributors (*)

(*) Contributors to this release (alphabetical order):

Vladim?r Luke?, Maty?? Nov?k


From suryak at ieee.org  Wed Feb 27 14:23:31 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Thu, 28 Feb 2013 00:53:31 +0530
Subject: [SciPy-Dev] scipycentral design done.
Message-ID: 

Hi all,

The design part of Scipy Central is done. I have used gh-pages (Jekyll) for
developing.

There might be some minor things require to be done. Might have forgot
about them or Was a bit in hurry to post my update here :)

Home Page: http://ksurya.github.com/SciPyCentral/preview/
Code page: http://ksurya.github.com/SciPyCentral/preview/snippet.html
Search page: http://ksurya.github.com/SciPyCentral/preview/search.html
Submit page: http://ksurya.github.com/SciPyCentral/preview/submit.html
Sign in page: http://ksurya.github.com/SciPyCentral/preview/signin.html
About page: http://ksurya.github.com/SciPyCentral/preview/about.html

I might have overlooked some pages but can be done while tweaking the
actual django template.

Please let me know if there are any changes needed..
Especially I am looking to hear about "font-size", "font-color",
"font-style"..

And, Till now, I didn't care much about compatibility issues. This is
working nicely on firefox, chrome with 1366 x 768 screen (my screen)..

I am looking if anyone code try on other screens you got and let me know
via screen shots if there's any bug!

(I guess I need to personally verify on MS-IE)

Looking for your suggestions, comments, critiques ...

-- Surya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lists at hilboll.de  Wed Feb 27 14:45:32 2013
From: lists at hilboll.de (Andreas Hilboll)
Date: Wed, 27 Feb 2013 20:45:32 +0100
Subject: [SciPy-Dev] scipycentral design done.
In-Reply-To: 
References: 
Message-ID: <512E625C.9030605@hilboll.de>

> The design part of Scipy Central is done. I have used gh-pages (Jekyll)
> for developing. 
> 
> There might be some minor things require to be done. Might have forgot
> about them or Was a bit in hurry to post my update here :)
> 
> Home Page: http://ksurya.github.com/SciPyCentral/preview/
> Code page: http://ksurya.github.com/SciPyCentral/preview/snippet.html
> Search page: http://ksurya.github.com/SciPyCentral/preview/search.html
> Submit page: http://ksurya.github.com/SciPyCentral/preview/submit.html
> Sign in page: http://ksurya.github.com/SciPyCentral/preview/signin.html
> About page: http://ksurya.github.com/SciPyCentral/preview/about.html
> 
> I might have overlooked some pages but can be done while tweaking the
> actual django template.
> 
> Please let me know if there are any changes needed.. 
> Especially I am looking to hear about "font-size", "font-color",
> "font-style"..
> 
> And, Till now, I didn't care much about compatibility issues. This is
> working nicely on firefox, chrome with 1366 x 768 screen (my screen)..
> 
> I am looking if anyone code try on other screens you got and let me know
> via screen shots if there's any bug!
> 
> (I guess I need to personally verify on MS-IE)
> 
> Looking for your suggestions, comments, critiques ... 

Nice :) Thank you, Surya, for doing this! I think this is really a very
clear design.

I'm in a hurry now and will comment on the font stuff later; however I'm
a bit disappointed to see that the logo is not in there. You don't like
it? Or it just didn't fit?

Cheers, Andreas.


From suryak at ieee.org  Wed Feb 27 20:37:00 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Thu, 28 Feb 2013 07:07:00 +0530
Subject: [SciPy-Dev] scipycentral design done.
In-Reply-To: <512E625C.9030605@hilboll.de>
References: 
	<512E625C.9030605@hilboll.de>
Message-ID: 

On Thu, Feb 28, 2013 at 1:15 AM, Andreas Hilboll  wrote:

> > The design part of Scipy Central is done. I have used gh-pages (Jekyll)
> > for developing.
> >
> > There might be some minor things require to be done. Might have forgot
> > about them or Was a bit in hurry to post my update here :)
> >
> > Home Page: http://ksurya.github.com/SciPyCentral/preview/
> > Code page: http://ksurya.github.com/SciPyCentral/preview/snippet.html
> > Search page: http://ksurya.github.com/SciPyCentral/preview/search.html
> > Submit page: http://ksurya.github.com/SciPyCentral/preview/submit.html
> > Sign in page: http://ksurya.github.com/SciPyCentral/preview/signin.html
> > About page: http://ksurya.github.com/SciPyCentral/preview/about.html
> >
> > I might have overlooked some pages but can be done while tweaking the
> > actual django template.
> >
> > Please let me know if there are any changes needed..
> > Especially I am looking to hear about "font-size", "font-color",
> > "font-style"..
> >
> > And, Till now, I didn't care much about compatibility issues. This is
> > working nicely on firefox, chrome with 1366 x 768 screen (my screen)..
> >
> > I am looking if anyone code try on other screens you got and let me know
> > via screen shots if there's any bug!
> >
> > (I guess I need to personally verify on MS-IE)
> >
> > Looking for your suggestions, comments, critiques ...
>
> Nice :) Thank you, Surya, for doing this! I think this is really a very
> clear design.
>
> I'm in a hurry now and will comment on the font stuff later; however I'm
> a bit disappointed to see that the logo is not in there. You don't like
> it? Or it just didn't fit?
>
> Cheers, Andreas.
>

Yeah, forgot to mention -- we even need to discuss about "logo" part of
site! The one which is on the above pages is done in "Gimp" in less than a
minute.. just to make sure that there is a logo when developing..

That scipy-globe image is very nice but didn't know where to put.. We can
put this logo along with current one but, at that small size, it looses its
beauty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From josef.pktd at gmail.com  Wed Feb 27 21:19:32 2013
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 27 Feb 2013 21:19:32 -0500
Subject: [SciPy-Dev] scipycentral design done.
In-Reply-To: 
References: 
	<512E625C.9030605@hilboll.de>
	
Message-ID: 

On Wed, Feb 27, 2013 at 8:37 PM, Surya Kasturi  wrote:
>
>
>
> On Thu, Feb 28, 2013 at 1:15 AM, Andreas Hilboll  wrote:
>>
>> > The design part of Scipy Central is done. I have used gh-pages (Jekyll)
>> > for developing.
>> >
>> > There might be some minor things require to be done. Might have forgot
>> > about them or Was a bit in hurry to post my update here :)
>> >
>> > Home Page: http://ksurya.github.com/SciPyCentral/preview/
>> > Code page: http://ksurya.github.com/SciPyCentral/preview/snippet.html
>> > Search page: http://ksurya.github.com/SciPyCentral/preview/search.html
>> > Submit page: http://ksurya.github.com/SciPyCentral/preview/submit.html
>> > Sign in page: http://ksurya.github.com/SciPyCentral/preview/signin.html
>> > About page: http://ksurya.github.com/SciPyCentral/preview/about.html
>> >
>> > I might have overlooked some pages but can be done while tweaking the
>> > actual django template.
>> >
>> > Please let me know if there are any changes needed..
>> > Especially I am looking to hear about "font-size", "font-color",
>> > "font-style"..

I still find the light blue font difficult to read.

Otherwise, I think it looks nice, no problems that I can see.

>> >
>> > And, Till now, I didn't care much about compatibility issues. This is
>> > working nicely on firefox, chrome with 1366 x 768 screen (my screen)..
>> >
>> > I am looking if anyone code try on other screens you got and let me know
>> > via screen shots if there's any bug!
>> >
>> > (I guess I need to personally verify on MS-IE)

>From a quick look at the pages, I didn't see any problems on IE9

Josef

>> >
>> > Looking for your suggestions, comments, critiques ...
>>
>> Nice :) Thank you, Surya, for doing this! I think this is really a very
>> clear design.
>>
>> I'm in a hurry now and will comment on the font stuff later; however I'm
>> a bit disappointed to see that the logo is not in there. You don't like
>> it? Or it just didn't fit?
>>
>> Cheers, Andreas.
>
>
> Yeah, forgot to mention -- we even need to discuss about "logo" part of
> site! The one which is on the above pages is done in "Gimp" in less than a
> minute.. just to make sure that there is a logo when developing..
>
> That scipy-globe image is very nice but didn't know where to put.. We can
> put this logo along with current one but, at that small size, it looses its
> beauty.
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From anandps20 at gmail.com  Thu Feb 28 01:39:48 2013
From: anandps20 at gmail.com (anand parthasarathy)
Date: Thu, 28 Feb 2013 12:09:48 +0530
Subject: [SciPy-Dev] Like to contribute to Scipy
In-Reply-To: 
References: 
	
Message-ID: 

Hi ralf,

Thank you for your reply. I am thinking of making the Scipy.signal module
to have the functions for communication, like communication toolbox in
matlab. We could join and can effectively launch packages including
features like Error correction mechanisms, channel functions etc. will this
be useful ?

Else can you point me towards any project involving productive results.






Regards,
Anand parthasarathy

On Mon, Feb 25, 2013 at 2:11 AM, Ralf Gommers wrote:

>
>
>
> On Tue, Feb 19, 2013 at 8:44 AM, anand parthasarathy wrote:
>
>> Hi,
>>
>> I would like to start contribute to Scipy - signal processing module. I
>> have been using MATLAB for a very long time, to the extend that i have
>> implemented many signal processing algorithms targeting the applications in
>> the field of Communications & wireless PHY Layer .
>>
>>  I am currently a Research Intern at Centre of Excellence in Wireless
>> Technology (CEWiT), India. I am so much fascinated by Scipy and though i am
>> new to python, i started love to code in python environment.
>>
>> Since this field is like a ocean , i would like to get suggestions from
>> you guys on this like where to start , and after decided with a specific
>> part to work on , i will start and contribute many things to Scipy to the
>> extend that i can.
>>
>
> Hi Anand, welcome! The signal module certainly could use your
> contributions.
>
> The same question you're asking was asked about a month ago by someone
> else, please have a look at this thread:
> http://thread.gmane.org/gmane.comp.python.scientific.devel/17173 . It
> contains a few ideas and pointers for getting started. If you have ideas
> for new algorithms/functionality to contribute, I recommend that you first
> discuss them on this mailing list to make sure the code you write will be a
> good fit for scipy.
>
> If you have more specific questions later, please don't hesitate to ask.
>
> Cheers,
> Ralf
>
>
>
>>
>>
>>
>>
>>
>>
>> Regards,
>> Anand Parthasarathy
>>
>>
>>
>> _______________________________________________
>> 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 suryak at ieee.org  Thu Feb 28 08:55:12 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Thu, 28 Feb 2013 19:25:12 +0530
Subject: [SciPy-Dev] running into errors in scipycentral
Message-ID: 

Hey,

I just configured scipycentral locally. When I tried to submit a test link
in it, I encountered an error.

http://dpaste.com/hold/1007760/ contains details of it.

So, can you please look into it? I don't think you guys have got this one!
It would be great if you can help me on it..

--Surya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lists at hilboll.de  Thu Feb 28 09:00:25 2013
From: lists at hilboll.de (Andreas Hilboll)
Date: Thu, 28 Feb 2013 15:00:25 +0100
Subject: [SciPy-Dev] running into errors in scipycentral
In-Reply-To: 
References: 
Message-ID: <512F62F9.7030705@hilboll.de>

> I just configured scipycentral locally. When I tried to submit a test
> link in it, I encountered an error.
> 
> http://dpaste.com/hold/1007760/ contains details of it.
> 
> So, can you please look into it? I don't think you guys have got this
> one! It would be great if you can help me on it..

Apparently, scipycentral uses Sphinx to compile the rst markup to HTML.
It seems like you didn't set up the Sphinx suite, at least, sphinx is
complaining about a missing config.

A.



From suryak at ieee.org  Thu Feb 28 09:15:54 2013
From: suryak at ieee.org (Surya Kasturi)
Date: Thu, 28 Feb 2013 19:45:54 +0530
Subject: [SciPy-Dev] running into errors in scipycentral
In-Reply-To: <512F62F9.7030705@hilboll.de>
References: 
	<512F62F9.7030705@hilboll.de>
Message-ID: 

On Thu, Feb 28, 2013 at 7:30 PM, Andreas Hilboll  wrote:

> > I just configured scipycentral locally. When I tried to submit a test
> > link in it, I encountered an error.
> >
> > http://dpaste.com/hold/1007760/ contains details of it.
> >
> > So, can you please look into it? I don't think you guys have got this
> > one! It would be great if you can help me on it..
>
> Apparently, scipycentral uses Sphinx to compile the rst markup to HTML.
> It seems like you didn't set up the Sphinx suite, at least, sphinx is
> complaining about a missing config.
>
> A.
>
> I do have Sphinx. I guess its unable to find ./deploy/compile/conf.py
right? All I think is that there must be a bug with os.path..
Note: I am on windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From kgdunn at gmail.com  Thu Feb 28 10:42:11 2013
From: kgdunn at gmail.com (Kevin Dunn)
Date: Thu, 28 Feb 2013 10:42:11 -0500
Subject: [SciPy-Dev] running into errors in scipycentral
In-Reply-To: 
References: 
	<512F62F9.7030705@hilboll.de>
	
Message-ID: 

On 2013-02-28 9:16 AM, "Surya Kasturi"  wrote:
>
>
>
>
> On Thu, Feb 28, 2013 at 7:30 PM, Andreas Hilboll  wrote:
>>
>> > I just configured scipycentral locally. When I tried to submit a test
>> > link in it, I encountered an error.
>> >
>> > http://dpaste.com/hold/1007760/ contains details of it.
>> >
>> > So, can you please look into it? I don't think you guys have got this
>> > one! It would be great if you can help me on it..
>>
>> Apparently, scipycentral uses Sphinx to compile the rst markup to HTML.
>> It seems like you didn't set up the Sphinx suite, at least, sphinx is
>> complaining about a missing config.
>>
>> A.
>>
> I do have Sphinx. I guess its unable to find ./deploy/compile/conf.py
right? All I think is that there must be a bug with os.path..
> Note: I am on windows

Maybe it will help to see a directory listing on the deployed webserver?
http://pastebin.com/ph3ReddB

I seem to remember using "os.sep" everywhere, instead of hard coding the
directory separator, but I might have missed one or two instances.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ralf.gommers at gmail.com  Thu Feb 28 15:27:37 2013
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Thu, 28 Feb 2013 21:27:37 +0100
Subject: [SciPy-Dev] Like to contribute to Scipy
In-Reply-To: 
References: 
	
	
Message-ID: 

On Thu, Feb 28, 2013 at 7:39 AM, anand parthasarathy wrote:

> Hi ralf,
>
> Thank you for your reply. I am thinking of making the Scipy.signal module
> to have the functions for communication, like communication toolbox in
> matlab. We could join and can effectively launch packages including
> features like Error correction mechanisms, channel functions etc. will this
> be useful ?
>

Hi Anand, to be honest I think those features are too specialized for
Scipy. I don't know of any Python packages with that type of functionality
(but I haven't searched and I'm not an expert). Maybe someone else has a
good suggestion. You could consider starting a new scikit if you plan on
implementing enough functionality to justify that.

Cheers,
Ralf



>
> Else can you point me towards any project involving productive results.
>
>
>
>
>
>
> Regards,
> Anand parthasarathy
>
> On Mon, Feb 25, 2013 at 2:11 AM, Ralf Gommers wrote:
>
>>
>>
>>
>> On Tue, Feb 19, 2013 at 8:44 AM, anand parthasarathy > > wrote:
>>
>>> Hi,
>>>
>>> I would like to start contribute to Scipy - signal processing module. I
>>> have been using MATLAB for a very long time, to the extend that i have
>>> implemented many signal processing algorithms targeting the applications in
>>> the field of Communications & wireless PHY Layer .
>>>
>>>  I am currently a Research Intern at Centre of Excellence in Wireless
>>> Technology (CEWiT), India. I am so much fascinated by Scipy and though i am
>>> new to python, i started love to code in python environment.
>>>
>>> Since this field is like a ocean , i would like to get suggestions from
>>> you guys on this like where to start , and after decided with a specific
>>> part to work on , i will start and contribute many things to Scipy to the
>>> extend that i can.
>>>
>>
>> Hi Anand, welcome! The signal module certainly could use your
>> contributions.
>>
>> The same question you're asking was asked about a month ago by someone
>> else, please have a look at this thread:
>> http://thread.gmane.org/gmane.comp.python.scientific.devel/17173 . It
>> contains a few ideas and pointers for getting started. If you have ideas
>> for new algorithms/functionality to contribute, I recommend that you first
>> discuss them on this mailing list to make sure the code you write will be a
>> good fit for scipy.
>>
>> If you have more specific questions later, please don't hesitate to ask.
>>
>> Cheers,
>> Ralf
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>> Anand Parthasarathy
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: