Mailman 3 September 2013 - SciPy-User

Failed Scipy Install
by bfrenay Sept. 10, 2013

Sept. 10, 2013

Dear All, I am trying to install Scipy on a CentOS machine. After installing Python 2.7.1 and Numpy 1.5.1, I tried to install Scipy 0.8.0 and got this message creating build/temp.linux-x86_64-2.7/scipy/sparse/sparsetools compile options: '-I/linux/frenay/centos_lib/lib/numpy-1.5.1/lib/python2.7/site-packages/numpy/core/include -I/linux/frenay/centos_lib/lib/Python-2.7.1/include/python2.7 -c' g++: scipy/sparse/sparsetools/csr_wrap.cxx scipy/sparse/sparsetools/csr_wrap.cxx: In function ‘int require_size(PyArrayObject*, npy_intp*, int)’: scipy/sparse/sparsetools/csr_wrap.cxx:2910: error: expected ‘)’ before ‘PRIdPTR’ scipy/sparse/sparsetools/csr_wrap.cxx:2910: warning: spurious trailing ‘%’ in format scipy/sparse/sparsetools/csr_wrap.cxx:2910: warning: too many arguments for format scipy/sparse/sparsetools/csr_wrap.cxx:2917: error: expected ‘)’ before ‘PRIdPTR’ scipy/sparse/sparsetools/csr_wrap.cxx:2917: warning: spurious trailing ‘%’ in format scipy/sparse/sparsetools/csr_wrap.cxx:2917: warning: too many arguments for format scipy/sparse/sparsetools/csr_wrap.cxx: In function ‘int require_size(PyArrayObject*, npy_intp*, int)’: scipy/sparse/sparsetools/csr_wrap.cxx:2910: error: expected ‘)’ before ‘PRIdPTR’ scipy/sparse/sparsetools/csr_wrap.cxx:2910: warning: spurious trailing ‘%’ in format scipy/sparse/sparsetools/csr_wrap.cxx:2910: warning: too many arguments for format scipy/sparse/sparsetools/csr_wrap.cxx:2917: error: expected ‘)’ before ‘PRIdPTR’ scipy/sparse/sparsetools/csr_wrap.cxx:2917: warning: spurious trailing ‘%’ in format scipy/sparse/sparsetools/csr_wrap.cxx:2917: warning: too many arguments for format error: Command "g++ -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/linux/frenay/centos_lib/lib/numpy-1.5.1/lib/python2.7/site-packages/numpy/core/include -I/linux/frenay/centos_lib/lib/Python-2.7.1/include/python2.7 -c scipy/sparse/sparsetools/csr_wrap.cxx -o build/temp.linux-x86_64-2.7/scipy/sparse/sparsetools/csr_wrap.o" failed with exit status 1 Any idea of the problem ? Thank you for your help ! -- View this message in context: http://scipy-user.10969.n7.nabble.com/Failed-Scipy-Install-tp18638.html Sent from the Scipy-User mailing list archive at Nabble.com.

2 1

scipy.optimize.slsqp.fmin_slsqp - Inequality constraints incompatible
by fj Sept. 10, 2013

Sept. 10, 2013

I am using SciPy 0.10.1 and the following code stops at Inequality constraints incompatible (Exit mode 4) error. Can I avoid it? I suspect that the error is connected with bounds, because it works without them. Thank you. import scipy.optimize upper_bounds = [91680237, 87141351, 19183473, 84453111] x0 = [1461516, 1230049, 0, 0] ieqcons = [ lambda x: 3139153 - (x[0] + x[1] + x[2] + x[3]), lambda x: 1461516 - (x[0] + x[2] + x[3]), lambda x: 1230049 - (x[1] + x[2]), ] scipy.optimize.slsqp.fmin_slsqp( func=lambda x: sum((x[i] - upper_bounds[i])**2 for i in xrange(4)), fprime=lambda x: [2 * (x[i] - upper_bounds[i]) for i in xrange(4)], x0=x0, bounds=[(0, b) for b in upper_bounds], ieqcons=ieqcons, iprint=2, ) -- View this message in context: http://scipy-user.10969.n7.nabble.com/scipy-optimize-slsqp-fmin-slsqp-Inequ… Sent from the Scipy-User mailing list archive at Nabble.com.

1 0

ANN: 1.8.0b2 release.
by Charles R Harris Sept. 8, 2013

Sept. 8, 2013

Hi all, I'm happy to announce the second beta release of Numpy 1.8.0. This release should solve the Windows problems encountered in the first beta. Many thanks to Christolph Gohlke and Julian Taylor for their hard work in getting those issues settled. It would be good if folks running OS X could try out this release and report any issues on the numpy-dev mailing list. Unfortunately the files still need to be installed from source as dmg files are not avalable at this time. Source tarballs and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.8.0b2/. The Windows and OS X installers will follow when the infrastructure issues are dealt with. Chuck

1 0

test… please ignore
by Joseph Anderson Sept. 7, 2013

Sept. 7, 2013

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joseph Anderson j.anderson(a)ambisonictoolkit.net http://www.ambisonictoolkit.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

Scaling up root-finding
by Chris Weisiger Sept. 7, 2013

Sept. 7, 2013

We have a somewhat elderly microscopy camera whose response curve is best-characterized as a degree-2 polynomial (starts out steep, then flattens out; we hit the camera's maximum bit depth before the function stops being monotonic though). That is: reported photons = a + b * (incident photons) + c * (incident photons)^2 Of course, each pixel is slightly different, giving 512*512 different polynomials. I want to linearize the camera's response in post-production, by inverting the (monotonic) function so that it maps reported photons to incident photons. The obvious method would be to use something from scipy.optimize's root-finding functions. I'm not remotely a numerical analysis expert, so I have no feel for which function would be best for this problem. Performance-wise, a quick test indicates that it would take about 3.5s on my laptop to process a single frame by manually iterating over every pixel in the frame and calling scipy.optimize.newton(that pixel's response function, that pixel's starting value). This isn't great, but it's well within the realm of feasibility. Is there some more efficient method to do this? In the ideal world we'd be able to handle arbitrary-degree polynomials, but I'd be willing to accept being restricted to degree-2. Of course, degree-1 is trivial to implement. Thanks for any advice you care to share. -Chris

5 10

eig_banded usage
by Wagner Sebastian Sept. 5, 2013

Sept. 5, 2013

Hello, After I got solve_banded running for me (I have in mind to do some improvements on doc/code) I have the next problem with scipy.linalg.eig_banded wich does not work like scipy.linalg.solve_banded, as one might expect. The doc says the parameters are (beside others): a_band and lower >From the descriptions of these two I guess a_banded is an array of the diagonals. Unlike with solve_banded it is not necessary to give the lower and upper bounds, as the second argument, lower, let's me assume it is only possible to have only lower diagonals or only upper ones. Is this correct? If it is, how can I compute the Eigenvalues with data containing both lower and upper diagonals? Regards, Sebastian

1 0

Re: [SciPy-User] SciPy-User Digest, Vol 121, Issue 3
by Gabriel Gaster Sept. 4, 2013

Sept. 4, 2013

Thanks David, I hadn't thought about it that way, but that makes sense. Cheers, Gabe > Date: Tue, 3 Sep 2013 12:37:23 -0700 (PDT) > From: David Baddeley <david_baddeley(a)yahoo.com.au (mailto:david_baddeley@yahoo.com.au)> > Subject: Re: [SciPy-User] __sizeof__ seems wrong > To: SciPy Users List <scipy-user(a)scipy.org (mailto:scipy-user@scipy.org)> > Message-ID: <1378237043.576.YahooMailNeo(a)web163905.mail.gq1.yahoo.com (mailto:1378237043.576.YahooMailNeo@web163905.mail.gq1.yahoo.com)> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Gabriel, > > I believe that sizeof returns the size of the 'ndarray' object (ie a pointer to the data, information about dimensions, strides, and data type etc ..), not the actual data. The full size in memory would be array.nbytes + array.__sizeof__(). The situation is, however, complicated in that the ndarray object doesn't necessarily own it's memory, and with the possibility of having multiple ndarrays pointing at the same data (ie after slicing), and it makes more sense to think of an ndarray object as being a kind of smart pointer rather than actually encompassing it's data, making the current implementation of __sizeof__ correct. One could potentially make sizeof return the full size if the array owned it's data, the 'pointer' size otherwise, but this is likely to be hard (if not impossible) to implement consistently over all possible use cases. > > cheers, > David > > > ________________________________ > From: Gabriel Gaster <gabe(a)gabegaster.com (mailto:gabe@gabegaster.com)> > To: scipy-user(a)scipy.org (mailto:scipy-user@scipy.org) > Sent: Tuesday, 3 September 2013 1:18 PM > Subject: [SciPy-User] __sizeof__ seems wrong > > > > This might be a bug/fix that is more appropriate for the numpy list -- but it also relates to scipy sparse... > > Run the following code: > > from scipy import sparse > x = sparse.rand(100,10,.2) > print x.__sizeof__() > ## 32 or 16, depending > print x.data.__sizeof__() > ## 80 or 40, depending > print x.data.nbytes > ## 1600 > > import numpy > print numpy.arange(200).__sizeof__() > ## 80 or 40, depending > print numpy.arange(200).nbytes > > ## 1600 > > 1. Why is nbytes different than __sizeof__ ? ?I believe nbytes and do not believe __sizeof__. __sizeof__ should just be rewritten to default to nbytes. > 2. It seems that the __sizeof__ methods need to be updated for numpy.array AND for scipy.sparse. > > I would be happy to do this -- but before I do, I wanted to sanity check with the list. > Thanks. > > Gabe > _______________________________________________ > SciPy-User mailing list > SciPy-User(a)scipy.org (mailto:SciPy-User@scipy.org) > http://mail.scipy.org/mailman/listinfo/scipy-user >

1 0

argrelextrema returns tuple of 2 empty arrays when no peaks found in 1D vector
by David McMinn Sept. 4, 2013

Sept. 4, 2013

Hello, I'm using the scipy.signal.argrelextrema function to find the peaks in a 1D numpy vector. While this is working for the most part I found that when no peaks were present in the data I get an tuple with two empty arrays as a result. I can handle this, but it got me wondering whether I have misunderstood the return value? The docs say it returns "Indices of the maxima, as an array of integers". I would expect with no peaks it would be an empty array (or a tuple with one empty array) since my input data is a 1D array, but I get two arrays. Any reason for this? Checking the source for scipy it does return "(np.array([]),) * 2" when there are no peaks, but that doesn't explain why it does that. For example: import numpy as np import scipy.signal as sig y = np.concatenate([np.arange(1, 0, -0.01), np.arange(0, 1, 0.01)]) peaks = sig.argrelextrema(0.5-np.abs(y - 0.5), np.greater) print peaks # Prints '(array([ 50, 150]),)' peaks = sig.argrelextrema(y, np.greater) # No peaks print peaks This prints '((array([]), dtype=float64),(array([]), dtype=float64),)' for the second print statement whereas I would have expected '((array([]), dtype=float64),)', which would have been more along the lines of the first print statement. So is this by design, and if so why? Have I misunderstood the return value? Thanks.

3 5

Color Lists in Dendrograms / Hierarchical Clustering
by Daniel Miner Sept. 4, 2013

Sept. 4, 2013

Hi everyone, I'd written over a month ago but never got any replies, so I'm trying again. Any help would be sincerely appreciated. I'm trying to use hierarchical clustering to tease out some structure in data that I already know exists as a sort of test case to (hopefully) show that it can be reliably done for the type of data I'm concerned with. To this end, knowing that the full call for dendrogram generation is: scipy.cluster.hioerarchy.dendrogram(Z, p=30, truncate_mode=None, color_threshold=None, get_leaves=True, orientation='top',labels=None, count_sort=False, distance_sort=False, show_leaf_counts=True, no_plot=False, no_labels=False, color_list=None,leaf_font_size=None, leaf_rotation=None, leaf_label_func=None, no_leaves=False, show_contracted=False,link_color_func=None) I use one of the linkage algorithms to generate the linkage, manually create a list of colors "c_list" as a list with a color corresponding to each known category of original data for each data point - i.e. if I have data [1,2,3] and know that 1 and 2 come from the same category but 3 is different, I make a list ['r','r','g'] - and try to use it as follows: import matplotlib.pyplot as pt import scipy.cluster.hierarchy as sc [import other stuff] [load data DAT, generate color list] lw = sc.ward(DAT) dw = sc.dendrogram(lw,color_list='c_list') pt.show() However, the colors seem to do nothing. I've tried listing them both numerically (i.e. [1,2,3]) and as characters (i.e. ['r','g','b']), and have tried making the call with c_list in single quotes as shown and with no quotes at all. There is no documentation at http://docs.scipy.org/doc/scipy/reference/generated/scipy.cluster.hierarchy… regarding an expected format for the color list, and without this color labeling, I can't check to see if the clustering is doing what I hope it does, as there are many data points and it would be prohibitively difficult to read though each of the tiny index labels at the bottom of the default dendrogram plot. I really have no idea how to proceed in order to make this work and am hoping that someone here can provide some advice. Thanks. Best regards, Daniel

2 1

__sizeof__ seems wrong
by Gabriel Gaster Sept. 3, 2013

Sept. 3, 2013

This might be a bug/fix that is more appropriate for the numpy list -- but it also relates to scipy sparse... Run the following code: from scipy import sparse x = sparse.rand(100,10,.2) print x.__sizeof__() ## 32 or 16, depending print x.data.__sizeof__() ## 80 or 40, depending print x.data.nbytes ## 1600 import numpy print numpy.arange(200).__sizeof__() ## 80 or 40, depending print numpy.arange(200).nbytes ## 1600 1. Why is nbytes different than __sizeof__ ? I believe nbytes and do not believe __sizeof__. __sizeof__ should just be rewritten to default to nbytes. 2. It seems that the __sizeof__ methods need to be updated for numpy.array AND for scipy.sparse. I would be happy to do this -- but before I do, I wanted to sanity check with the list. Thanks. Gabe

2 1