From Peter.VanWieren at avl.com Tue Nov 4 12:23:06 2014 From: Peter.VanWieren at avl.com (VanWieren, Peter AVL/US) Date: Tue, 4 Nov 2014 17:23:06 +0000 Subject: [SciPy-User] scipy.interpolate.interp2d Message-ID: A simple interpolation with a 6 data points is successful. Python 2.6.6 (r266:84292, May 27 2013, 05:35:12) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy.interpolate >>> x = [0,1,2] >>> y = [0,3] >>> z = [[1,2,3],[4,5,6]] >>> s = scipy.interpolate.interp2d( x , y , z ) Increasing to 8 points with simple values creates a warning, even if kind='linear' is given. >>> x = [0,1,2,3] >>> y = [0,3] >>> z = [[1,2,3,4],[5,6,7,8]] >>> s = scipy.interpolate.interp2d( x , y , z ) Warning: No more knots can be added because the number of B-spline coefficients already exceeds the number of data points m. Probably causes: either s or m too small. (fp>s) kx,ky=1,1 nx,ny=5,5 m=8 fp=0.000000 s=0.000000 >>> These are simple and valid inputs which should not, as far as I can see, cause any problems. Why does this warning occur, and how can it be avoided? Thanks PVW -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Wed Nov 5 10:32:11 2014 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 05 Nov 2014 21:02:11 +0530 Subject: [SciPy-User] [ANN] CFP: SciPy India 2014: Dec 5 - 7, IIT Bombay Message-ID: <545A42FB.9070307@aero.iitb.ac.in> Hello, [Apologies for the cross-posting] The CFP and registration for SciPy India 2014 (http://scipy.in) is open. SciPy India 2014 will be held in IIT Bombay between December 5th to December 7th, 2014. Please spread the word! SciPy India is an annual conference on using Python for science and engineering research and education. The conference is currently in its sixth year and provides an opportunity to learn and implement Python in education and research. Call for Papers ================ We look forward to your submissions on the use of Python for scientific computing and education. This includes pedagogy, exploration, modeling and analysis from both applied and developmental perspectives. We welcome contributions from academia as well as industry. For details on the paper submission please see here: http://scipy.in/2014/call-for-proposals/ Important Dates ================ - Call for proposals end: 9th November 2014 We look forward to seeing you at SciPy India. Regards, Prabhu Ramachandran and Jarrod Millman From vbubbly21 at gmail.com Wed Nov 5 10:58:29 2014 From: vbubbly21 at gmail.com (Artur Bercik) Date: Thu, 6 Nov 2014 00:58:29 +0900 Subject: [SciPy-User] Problem with creating a raster image like regular grid using SciPy Message-ID: Dear SciPy users: I have the numpy arrays of longitudes, latitudes, and the data. As you see the array of longitudes and latitudes, they are not in a regular grid. I want to make a regular grid (like a raster image) from such scatterred data. I have made it using interp2d function available in scipy. However, when I read the docs of interp2d carefully, the docs says that the x and y represent a regular grid. But my x(lons) and y (lats) are not regular grid. So in this case, how can I make a raster image like regular grid? longitudes = np.array([[139.79391479492188, 140.51760864257812, 141.19119262695312, 141.82083129882812, 142.41165161132812], [139.79225158691406, 140.51416015625, 141.18606567382812, 141.8140869140625, 142.40338134765625], [139.78591918945312, 140.50637817382812, 141.17694091796875, 141.80377197265625, 142.3919677734375], [139.78387451171875, 140.50253295898438, 141.17147827148438, 141.79678344726562, 142.38360595703125], [139.77781677246094, 140.4949951171875, 141.16250610351562, 141.78646850585938, 142.37196350097656]],dtype=float) latitudes = np.array([[55.61929702758789, 55.621070861816406, 55.61888122558594, 55.613487243652344, 55.60547637939453], [55.53120040893555, 55.532840728759766, 55.53053665161133, 55.525047302246094, 55.5169677734375], [55.44305419921875, 55.444580078125, 55.44219207763672, 55.43663024902344, 55.42848587036133], [55.35470199584961, 55.356109619140625, 55.353614807128906, 55.34796905517578, 55.33975601196289], [55.26683807373047, 55.268131256103516, 55.26553726196289, 55.25981140136719, 55.25152587890625]],dtype=float) data = np.array([[10, 10, 10, 10, 10], [20, 20, 20, 20, 20], [30, 30, 30, 30, 30], [40, 40, 40, 40, 40], [50, 50, 50, 50, 50]],dtype=float) I hope someone can help me. Thanks in the advance. Artur -------------- next part -------------- An HTML attachment was scrubbed... URL: From mansingtakale at gmail.com Wed Nov 5 11:26:25 2014 From: mansingtakale at gmail.com (mansing takale) Date: Wed, 5 Nov 2014 21:56:25 +0530 Subject: [SciPy-User] [ANN] CFP: SciPy India 2014: Dec 5 - 7, IIT Bombay In-Reply-To: <545A42FB.9070307@aero.iitb.ac.in> References: <545A42FB.9070307@aero.iitb.ac.in> Message-ID: Hello Sir, Thank you for the mail and the subsequent successful registration as well. Mansing On Wed, Nov 5, 2014 at 9:02 PM, Prabhu Ramachandran wrote: > Hello, > > [Apologies for the cross-posting] > > The CFP and registration for SciPy India 2014 (http://scipy.in) is open. > SciPy > India 2014 will be held in IIT Bombay between December 5th to December > 7th, 2014. > > Please spread the word! > > SciPy India is an annual conference on using Python for science and > engineering > research and education. The conference is currently in its sixth year and > provides an opportunity to learn and implement Python in education and > research. > > > Call for Papers > ================ > > We look forward to your submissions on the use of Python for scientific > computing and education. This includes pedagogy, exploration, modeling and > analysis from both applied and developmental perspectives. We welcome > contributions from academia as well as industry. > > For details on the paper submission please see here: > > http://scipy.in/2014/call-for-proposals/ > > Important Dates > ================ > > - Call for proposals end: 9th November 2014 > > > We look forward to seeing you at SciPy India. > > Regards, > Prabhu Ramachandran and Jarrod Millman > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsseabold at gmail.com Wed Nov 5 12:28:15 2014 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 5 Nov 2014 12:28:15 -0500 Subject: [SciPy-User] [ANN] statsmodels version 0.6.0 released Message-ID: Hi All, The statsmodels development team is happy to announce the release of statsmodels 0.6.0. This the culmination of another year's worth of work -- over 1500 commits from 37 different developers. It is a combination of bug fixes and feature enhancements. All users are encouraged to upgrade to this version. Highlights ======== * Generalized Estimating Equation models * Linear Mixed Effects Models * Wrapper code for using X-12-ARIMA/X13-ARIMA-SEATS * Substantial optimization in the ARIMA estimation code * Some seasonal time-series features for plotting and decomposition * Many other feature enhancments and bug fixes Full Release Notes: http://statsmodels.sourceforge.net/stable/release/version0.6.html Issues Closed: http://statsmodels.sourceforge.net/stable/release/github-stats-0.6.html#issues-list-06 Installers: https://pypi.python.org/pypi/statsmodels Thanks To ========= git log v0.5.0..v0.6.0 --format='* %aN' | sort -u * Alex Griffing * Alex Parij * Ana Martinez Pardo * Andrew Clegg * Ben Duffield * Chad Fulton * Chris Kerr * Eric Chiang * Evgeni Burovski * gliptak * Hans-Martin von Gaudecker * Jan Schulz * jfoo * Joe Hand * Josef Perktold * jsphon * Justin Grana * Kerby Shedden * Kevin Sheppard * Kyle Beauchamp * Lars Buitinck * m * Max Linke * Miroslav Batchkarov * Padarn Wilson * Paul Hobson * Pietro Battiston * Radim ?eh??ek * Ralf Gommers * Richard T. Guy * Roy Hyunjin Han * Skipper Seabold * Tom Augspurger * Trent Hauck * Valentin Haenel * Vincent Arel-Bundock * Yaroslav Halchenko What is it ======== Statsmodels is a Python module that allows users to explore data, estimate statistical models, and perform statistical tests. An extensive list of descriptive statistics, statistical tests, plotting functions, and result statistics are available for different types of data and each estimator. Researchers across fields may find that statsmodels fully meets their needs for statistical computing and data analysis in Python. Dependencies =========== Required dependencies: python >= 2.6 numpy >= 1.5.1 scipy >= 0.9.0 pandas >= 0.7.1 patsy >= 0.3.0 Build dependencies: Cython >= 0.20.1 (If building from github repo) C compiler Optional dependencies: matplotlib >= 1.1 : needed for plotting sphinx >= 1.0.0 : needed to build the docs ipython >= 1.0 : needed to build the notebook examples nose >= 1.0.0 : needed to run the tests X-12-ARIMA or X-13ARIMA-SEATS : for time-series analysis. See INSTALL. Links ====== Documentation: http://statsmodels.sourceforge.net/ Mailing List: https://groups.google.com/forum/#!forum/pystatsmodels PyPi: https://pypi.python.org/pypi/statsmodels Github: https://github.com/statsmodels/statsmodels/ Bug Tracker: https://github.com/statsmodels/statsmodels/issues Cheers, Skipper From fabien.maussion at gmail.com Thu Nov 6 03:58:23 2014 From: fabien.maussion at gmail.com (Fabien) Date: Thu, 06 Nov 2014 09:58:23 +0100 Subject: [SciPy-User] scipy.interpolate.interp2d In-Reply-To: References: Message-ID: On 04.11.2014 18:23, VanWieren, Peter AVL/US wrote: > Why does this warning occur, and how can it be avoided? I don't know about the warning but I know that I've been more successful with griddata than interp2d in the past... Cheers, Fabien From andyfaff at gmail.com Tue Nov 11 02:29:01 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Tue, 11 Nov 2014 18:29:01 +1100 Subject: [SciPy-User] problems building scipy on Yosemite. Message-ID: Dear list, I've updated to Yosemite (clean install) and am having problems building scipy from source (python setup.py build) The complete build log is at: https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 $gfortran --version GNU Fortran (GCC) 4.2.3 $gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix $echo FFLAGS -ff2c gfortran was from http://cran.r-project.org/bin/macosx/tools/. Is anyone able to give me any tips as to what I'm doing wrong? cheers, Andrew -- _____________________________________ Dr. Andrew Nelson _____________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Wed Nov 12 22:51:22 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 12 Nov 2014 19:51:22 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: Message-ID: Hi, On Mon, Nov 10, 2014 at 11:29 PM, Andrew Nelson wrote: > Dear list, > I've updated to Yosemite (clean install) and am having problems building > scipy from source (python setup.py build) > > The complete build log is at: > https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 > > $gfortran --version > GNU Fortran (GCC) 4.2.3 > $gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > Target: x86_64-apple-darwin14.0.0 > Thread model: posix > $echo FFLAGS > -ff2c > > gfortran was from http://cran.r-project.org/bin/macosx/tools/. > > Is anyone able to give me any tips as to what I'm doing wrong? I think you may have to use clang - see : http://www.scipy.org/scipylib/building/macosx.html#os-x-10-7-lion-and-10-8-mountain-lion $ export CC=clang $ export CXX=clang++ $ export FFLAGS=-ff2c Does that work? Cheers, Matthew From andyfaff at gmail.com Wed Nov 12 22:55:59 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Thu, 13 Nov 2014 14:55:59 +1100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: Message-ID: It may not have been clear in my original post, I was using clang and clang++. On 13 November 2014 14:51, Matthew Brett wrote: > Hi, > > On Mon, Nov 10, 2014 at 11:29 PM, Andrew Nelson > wrote: > > Dear list, > > I've updated to Yosemite (clean install) and am having problems building > > scipy from source (python setup.py build) > > > > The complete build log is at: > > https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 > > > > $gfortran --version > > GNU Fortran (GCC) 4.2.3 > > $gcc --version > > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > > --with-gxx-include-dir=/usr/include/c++/4.2.1 > > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > > Target: x86_64-apple-darwin14.0.0 > > Thread model: posix > > $echo FFLAGS > > -ff2c > > > > gfortran was from http://cran.r-project.org/bin/macosx/tools/. > > > > Is anyone able to give me any tips as to what I'm doing wrong? > > I think you may have to use clang - see : > > http://www.scipy.org/scipylib/building/macosx.html#os-x-10-7-lion-and-10-8-mountain-lion > > $ export CC=clang > $ export CXX=clang++ > $ export FFLAGS=-ff2c > > Does that work? > > Cheers, > > Matthew > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > -- _____________________________________ Dr. Andrew Nelson _____________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Thu Nov 13 00:40:28 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 13 Nov 2014 05:40:28 +0000 (UTC) Subject: [SciPy-User] problems building scipy on Yosemite. References: Message-ID: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Have you tried the latest official "unofficial" gfortran binaries? https://gcc.gnu.org/wiki/GFortranBinaries#MacOS Sturla Andrew Nelson wrote: > Dear list, > I've updated to Yosemite (clean install) and am having problems building > scipy from source (python setup.py build) > > The complete build log is at: > href="https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2">https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 > > $gfortran --version > GNU Fortran (GCC) 4.2.3 > $gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > Target: x86_64-apple-darwin14.0.0 > Thread model: posix > $echo FFLAGS > -ff2c > > gfortran was from href="http://cran.r-project.org/bin/macosx/tools/.">http://cran.r-project.org/bin/macosx/tools/. > > Is anyone able to give me any tips as to what I'm doing wrong? > > cheers, > Andrew > > -- > _____________________________________ > Dr. Andrew Nelson > > _____________________________________ > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > href="http://mail.scipy.org/mailman/listinfo/scipy-user">http://mail.scipy.org/mailman/listinfo/scipy-user From matthew.brett at gmail.com Thu Nov 13 01:14:51 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 12 Nov 2014 22:14:51 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: On Wed, Nov 12, 2014 at 9:40 PM, Sturla Molden wrote: > Have you tried the latest official "unofficial" gfortran binaries? > > https://gcc.gnu.org/wiki/GFortranBinaries#MacOS > > > Sturla > > > Andrew Nelson wrote: >> Dear list, >> I've updated to Yosemite (clean install) and am having problems building >> scipy from source (python setup.py build) >> >> The complete build log is at: >> > href="https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2">https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 >> >> $gfortran --version >> GNU Fortran (GCC) 4.2.3 >> $gcc --version >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) >> Target: x86_64-apple-darwin14.0.0 >> Thread model: posix >> $echo FFLAGS >> -ff2c >> >> gfortran was from > href="http://cran.r-project.org/bin/macosx/tools/.">http://cran.r-project.org/bin/macosx/tools/. >> >> Is anyone able to give me any tips as to what I'm doing wrong? >> >> cheers, >> Andrew Scipy builds OK for me with the cran gfortran, current trunk, numpy 1.9.1 via pip install, and $ export CC=clang $ export CXX=clang++ $ export FFLAGS=-ff2c Can you give more detail about your system? Numpy, scipy version? Cheers, Matthew From sturla.molden at gmail.com Thu Nov 13 02:10:06 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 13 Nov 2014 07:10:06 +0000 (UTC) Subject: [SciPy-User] problems building scipy on Yosemite. References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: <1547956861437555038.141625sturla.molden-gmail.com@news.gmane.org> Matthew Brett wrote: > Scipy builds OK for me with the cran gfortran, current trunk, numpy > 1.9.1 via pip install, and > > $ export CC=clang > $ export CXX=clang++ > $ export FFLAGS=-ff2c The last flag is interesting. It instructs gfortran to use g77 ABI. But SciPy is supposed to have ABI wrappers for g77 ABI in Accelerate. If it is still needed it means that the ABI wrappers don't do what they are supposed to do. The ABI wrapper code in SciPy is so convoluted (and confused?) that it would not surprise me. If so, we should create ABI wrappers in the same way as libVecFort. Sturla From andyfaff at gmail.com Thu Nov 13 03:08:54 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Thu, 13 Nov 2014 19:08:54 +1100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: > > > Scipy builds OK for me with the cran gfortran, current trunk, numpy > 1.9.1 via pip install, and > > $ export CC=clang > $ export CXX=clang++ > $ export FFLAGS=-ff2c > > Can you give more detail about your system? Numpy, scipy version? > > Cheers, > > Matthew > > I'm trying to build scipy trunk. numpy was installed into a virtualenv with 'pip install numpy'. Python is : Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin >>> np.version.full_version '1.9.1' >>> np.version.git_revision 'd44b9c61499f8bc5a9fc94286cd52f05e15e003f' OSX 10.10. (development)$ clang --version Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix (development)$ clang++ --version Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Nov 13 03:24:36 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 13 Nov 2014 00:24:36 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: On Thu, Nov 13, 2014 at 12:08 AM, Andrew Nelson wrote: >> >> Scipy builds OK for me with the cran gfortran, current trunk, numpy >> 1.9.1 via pip install, and >> >> $ export CC=clang >> $ export CXX=clang++ >> $ export FFLAGS=-ff2c >> >> Can you give more detail about your system? Numpy, scipy version? >> >> Cheers, >> >> Matthew >> > > I'm trying to build scipy trunk. numpy was installed into a virtualenv with > 'pip install numpy'. Python is : > > Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > >>>> np.version.full_version > > '1.9.1' > >>>> np.version.git_revision > > 'd44b9c61499f8bc5a9fc94286cd52f05e15e003f' > > OSX 10.10. > > (development)$ clang --version > > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > > Target: x86_64-apple-darwin14.0.0 > > Thread model: posix > > (development)$ clang++ --version > > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > > Target: x86_64-apple-darwin14.0.0 > > Thread model: posix That's strange, I have the exact same configuration. You used the same build environment variables too? Matthew From almar.klein at gmail.com Thu Nov 13 15:54:02 2014 From: almar.klein at gmail.com (Almar Klein) Date: Thu, 13 Nov 2014 21:54:02 +0100 Subject: [SciPy-User] ANN: imageio Message-ID: <54651A6A.1020006@gmail.com> Hi, I'm pleased to announce version 1.0 of imageio - a library for reading and writing images. Imageio provides an easy interface to read and write a wide range of image data, including animated images, volumetric data, and scientific formats. It is cross-platform, runs on Python 2.x and 3.x, and is easy to install. install: pip install imageio website: http://imageio.github.io release notes: http://imageio.readthedocs.org/en/latest/releasenotes.html Regards, Almar From andyfaff at gmail.com Thu Nov 13 17:41:34 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Fri, 14 Nov 2014 09:41:34 +1100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: On 13 November 2014 16:40, Sturla Molden wrote: > Have you tried the latest official "unofficial" gfortran binaries? > > https://gcc.gnu.org/wiki/GFortranBinaries#MacOS > > This finally worked for me. I downloaded the gfortran 4.9.0 from a link on that page that Sturla provided. I had the CC=clang, CXX=clang++ environment variables (no FFLAGS set), and the build worked. Thanks Sturla for that suggestion. I can't help feeling that the build process is a little fragile if one has to find the exact gfortran compiler that works for given C compiler/OS combination. cheers, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Thu Nov 13 17:45:15 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 13 Nov 2014 14:45:15 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: Hi, On Thu, Nov 13, 2014 at 2:41 PM, Andrew Nelson wrote: > On 13 November 2014 16:40, Sturla Molden wrote: >> >> Have you tried the latest official "unofficial" gfortran binaries? >> >> https://gcc.gnu.org/wiki/GFortranBinaries#MacOS >> > > This finally worked for me. I downloaded the gfortran 4.9.0 from a link on > that page that Sturla provided. I had the CC=clang, CXX=clang++ environment > variables (no FFLAGS set), and the build worked. > > Thanks Sturla for that suggestion. I can't help feeling that the build > process is a little fragile if one has to find the exact gfortran compiler > that works for given C compiler/OS combination. Did you use the FFLAGS variable set with the cran Fortran compiler? Cheers, Matthew From andyfaff at gmail.com Thu Nov 13 17:47:01 2014 From: andyfaff at gmail.com (Andrew Nelson) Date: Fri, 14 Nov 2014 09:47:01 +1100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: Yes. On 14/11/2014 9:45 AM, "Matthew Brett" wrote: > Hi, > > On Thu, Nov 13, 2014 at 2:41 PM, Andrew Nelson wrote: > > On 13 November 2014 16:40, Sturla Molden > wrote: > >> > >> Have you tried the latest official "unofficial" gfortran binaries? > >> > >> https://gcc.gnu.org/wiki/GFortranBinaries#MacOS > >> > > > > This finally worked for me. I downloaded the gfortran 4.9.0 from a link > on > > that page that Sturla provided. I had the CC=clang, CXX=clang++ > environment > > variables (no FFLAGS set), and the build worked. > > > > Thanks Sturla for that suggestion. I can't help feeling that the build > > process is a little fragile if one has to find the exact gfortran > compiler > > that works for given C compiler/OS combination. > > Did you use the FFLAGS variable set with the cran Fortran compiler? > > Cheers, > > Matthew > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Thu Nov 13 23:01:33 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 14 Nov 2014 04:01:33 +0000 (UTC) Subject: [SciPy-User] problems building scipy on Yosemite. References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> Message-ID: <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Andrew Nelson wrote: > This finally worked for me. I downloaded the gfortran 4.9.0 from a link on > that page that Sturla provided. I had the CC=clang, CXX=clang++ environment > variables (no FFLAGS set), and the build worked. Run the test suite a s well. Personally I use gfortran 4.8.2 from the same source. It seems to work reliably and I trust the gfortran team to build a binary with the right configurations. The purpose of of the ABI wrappers in scipy/_build_utils is to avoid building with FFLAGS=-ff2c with gfortran on OS X, so Matthew Brett's suggestion to keep this flag made me worried. > Thanks Sturla for that suggestion. I can't help feeling that the build > process is a little fragile if one has to find the exact gfortran compiler > that works for given C compiler/OS combination. Building SciPy on OS X has always been a bit fragile, at least without Intel's Fortran compiler and MKL. But downloading an official/unoffcial gfortran binary installer from the gfortran wiki does not seem to be that fragile. Using an old gfortran build from the R project seems more on the fragile side, though. Sturla From matthew.brett at gmail.com Fri Nov 14 02:55:13 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 13 Nov 2014 23:55:13 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: Hi, On Thu, Nov 13, 2014 at 8:01 PM, Sturla Molden wrote: > Andrew Nelson wrote: > >> This finally worked for me. I downloaded the gfortran 4.9.0 from a link on >> that page that Sturla provided. I had the CC=clang, CXX=clang++ environment >> variables (no FFLAGS set), and the build worked. > > Run the test suite a s well. > > Personally I use gfortran 4.8.2 from the same source. It seems to work > reliably and I trust the gfortran team to build a binary with the right > configurations. > > The purpose of of the ABI wrappers in scipy/_build_utils is to avoid > building with FFLAGS=-ff2c with gfortran on OS X, so Matthew Brett's > suggestion to keep this flag made me worried. It certainly used to be necessary building on 10.9, but for a different error : https://github.com/scipy/scipy/issues/3194 Actually, now I try and build on 10.9 with cran gfortran, I also get this error, I believe same as OP: /usr/local/bin/gfortran -Wall -g -arch i686 -arch x86_64 -Wall -g -undefined dynamic_lookup -bundle build/temp.macosx-10.6-intel-2.7/scipy/integrate/_odepackmodule.o -Lbuild/temp.macosx-10.6-intel-2.7 -lodepack -lmach -lgfortran -o build/lib.macosx-10.6-intel-2.7/scipy/integrate/_odepack.so -Wl,-framework -Wl,Accelerate ld: warning: can't find atom for N_GSYM stabs ls0001:G(0,24)=s1900rowns:(0,25)=ar(0,6);0;208;(0,9),0,13376;ccmax:(0,9),13376,64;el0:(0,9),13440,64;h:(0,9),13504,64;hmin:(0,9),13568,64;hmxi:(0,9),13632,64;hu:(0,9),13696,64;rc:(0,9),13760,64;tn:(0,9),13824,64;uround:(0,9),13888,64;illin:(0,6),13952,32;init:(0,6),13984,32;lyh:(0,6),14016,32;lewt:(0,6),14048,32;lacor:(0,6),14080,32;lsavf:(0,6),14112,32;lwm:(0,6),14144,32;liwm:(0,6),14176,32;mxstep:(0,6),14208,32;mxhnil:(0,6),14240,32;nhnil:(0,6),14272,32;ntrep:(0,6),14304,32;nslast:(0,6),14336,32;nyh:(0,6),14368,32;iowns:(0,26)=ar(0,6);0;5;(0,6),14400,192;icf:(0,6),14592,32;ierpj:(0,6),14624,32;iersl:(0,6),14656,32;jcur:(0,6),14688,32;jstart:(0,6),14720,32;kflag:(0,6),14752,32;l:(0,6),14784,32;meth:(0,6),14816,32;miter:(0,6),14848,32;maxord:(0,6),14880,32;maxcor:(0,6),14912,32;msbp:(0,6),14944,32;mxncf:(0,6),14976,32;n:(0,6),15008,32;nq:(0,6),15040,32;nst:(0,6),15072,32;nfe:(0,6),15104,32;nje:(0,6),15136,32;nqu:(0,6),15168,32;; in build/temp.macosx-10.6-intel-2.7/libodepack.a(lsoda.o) I get this whether I use `export FFLAGS=-ff2c` or not, so maybe it is an incompatibility of the old gfortran with recent clang. >> Thanks Sturla for that suggestion. I can't help feeling that the build >> process is a little fragile if one has to find the exact gfortran compiler >> that works for given C compiler/OS combination. > > Building SciPy on OS X has always been a bit fragile, at least without > Intel's Fortran compiler and MKL. > > But downloading an official/unoffcial gfortran binary installer from the > gfortran wiki does not seem to be that fragile. Using an old gfortran build > from the R project seems more on the fragile side, though. The cran fortran is the standard recommendation because it compiles both 32 and 64 bit binaries, if given the correct -arch flags; I don't think that's true with the official gfortran binary (it just builds 64-bit or 32-bit but not both). Not many of us are using 32-bit on Macs these days though: https://www.adium.im/sparkle/#cpu64bit Cheers, Matthew From sturla.molden at gmail.com Fri Nov 14 08:42:44 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Fri, 14 Nov 2014 13:42:44 +0000 (UTC) Subject: [SciPy-User] problems building scipy on Yosemite. References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: <1574996448437664288.587158sturla.molden-gmail.com@news.gmane.org> Matthew Brett wrote: > It certainly used to be necessary building on 10.9, but for a > different error : https://github.com/scipy/scipy/issues/3194 Obviously not, as the error is reported when compiling with this flag. The error here is a missing mmintrin.h when compiling with Apple's llvm-gcc-4.2. Sturla From johnl at crumpington.com Mon Nov 17 23:46:55 2014 From: johnl at crumpington.com (John David Lee) Date: Mon, 17 Nov 2014 22:46:55 -0600 Subject: [SciPy-User] Characteristic pulse-shape fitting scikit Message-ID: <546ACF3F.7070002@crumpington.com> Hi, I've been working on packaging some pulse-fitting code I wrote a few years ago into a scikit. Yesterday I finally completed what I'd consider an alpha version of the code. It's available here: https://github.com/johnnylee/scikits.pulsefit There's documentation and an example of usage on the github site. As a quick overview, the code is designed to identify pulses having a characteristic shape and varying amplitude within an array. This is the type of data that generally comes out of a shaping amplifier. I used a variation of this code to analyze x-ray data from pulse-mode x-ray detectors. I'd be interested to hear any comments, suggestions or criticisms before I finalize the interface and move toward version 1. I'd also be interested in looking at examples of measured pulse shapes anyone has. If you'd like to use the code, please get in touch. I'd be glad to help out. Thanks, J. David Lee From cournape at gmail.com Tue Nov 18 06:44:24 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 18 Nov 2014 11:44:24 +0000 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: Message-ID: On Tue, Nov 11, 2014 at 7:29 AM, Andrew Nelson wrote: > Dear list, > I've updated to Yosemite (clean install) and am having problems building > scipy from source (python setup.py build) > > The complete build log is at: > https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 > > $gfortran --version > GNU Fortran (GCC) 4.2.3 > $gcc --version > Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) > Target: x86_64-apple-darwin14.0.0 > Thread model: posix > $echo FFLAGS > -ff2c > > I can reproduce the issue on 10.6, where I used to be able to build numpy/scipy before with the exact same configuration (10.6, gfortran from ATT, official gcc-4.2 compilers from Apple). I reduced the issue to be related to 32 bits only, and when built against numpy 1.9.1. I don't have the issue when building scipy against 1.8.1. This suggests some incompatibilities in compilation options that have changed in numpy between 1.8.1 and 1.9.1. David P.S: one should not use -ff2c flags. > gfortran was from http://cran.r-project.org/bin/macosx/tools/. > > Is anyone able to give me any tips as to what I'm doing wrong? > > cheers, > Andrew > -- > _____________________________________ > Dr. Andrew Nelson > > > _____________________________________ > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Tue Nov 18 08:38:04 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 18 Nov 2014 13:38:04 +0000 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: Message-ID: On Tue, Nov 18, 2014 at 11:44 AM, David Cournapeau wrote: > > > On Tue, Nov 11, 2014 at 7:29 AM, Andrew Nelson wrote: > >> Dear list, >> I've updated to Yosemite (clean install) and am having problems building >> scipy from source (python setup.py build) >> >> The complete build log is at: >> https://gist.github.com/andyfaff/5a433d0585e8dae1dfc2 >> >> $gfortran --version >> GNU Fortran (GCC) 4.2.3 >> $gcc --version >> Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) >> Target: x86_64-apple-darwin14.0.0 >> Thread model: posix >> $echo FFLAGS >> -ff2c >> >> > I can reproduce the issue on 10.6, where I used to be able to build > numpy/scipy before with the exact same configuration (10.6, gfortran from > ATT, official gcc-4.2 compilers from Apple). > > I reduced the issue to be related to 32 bits only, and when built against > numpy 1.9.1. I don't have the issue when building scipy against 1.8.1. > > This suggests some incompatibilities in compilation options that have > changed in numpy between 1.8.1 and 1.9.1. > Indeed, the problem is the added '-g' flag between 1.8.1 and 1.9.1. That flag is invalid for gcc 4.2.x on darwin, we should instead use -gdwarf-2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34719 David -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio_r at mail.com Wed Nov 19 04:41:47 2014 From: sergio_r at mail.com (Sergio Rojas) Date: Wed, 19 Nov 2014 10:41:47 +0100 Subject: [SciPy-User] SPSOLVE wrong behaviour under scipy '0.14.0' In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From sergio_r at mail.com Wed Nov 19 13:54:48 2014 From: sergio_r at mail.com (Sergio Rojas) Date: Wed, 19 Nov 2014 19:54:48 +0100 Subject: [SciPy-User] SPSOLVE wrong behaviour under scipy '0.14.0' In-Reply-To: References: Message-ID: ?""" Hello, The code below works on scipy '0.13.3'. Trying the code on scipy '0.14.0', I have to replace the statement xtemp[a3,a3] = b33 # NOT RECOGNIZE by scipy '0.14.0' by a for loop: # xtemp[a3,a3] = b33 # NOT RECOGNIZE by scipy '0.14.0' for i in range(len(a3)): for j in range(len(a3)): xtemp[a3[i],a3[j]] = b33[i,j] But then, spsolve returns a bunch of 'nan' values as the solution of the system. What was changed on scipy '0.14.0' for it not to run a code that works on a not so far previoes version? Sergio """ import numpy as np from scipy.sparse import dok_matrix from scipy.sparse.linalg import spsolve xp = 40 xtemp = dok_matrix((xp,xp)) a3 = np.array([14, 10, 24], dtype='int32') b33 = np.array([[ 0.00192607, -0.00052385, -0.00140223], [-0.00052385, 0.00760145, -0.00707761], [-0.00140223, -0.00707761, 0.00847983]]) # xtemp[a3,a3] = b33 # NOT RECOGNIZE by scipy '0.14.0' IT WORKS under scipy '0.13.3' # next lines works under both scipy versions for i in range(len(a3)): for j in range(len(a3)): xtemp[a3[i],a3[j]] = b33[i,j] rhs = np.zeros((xp,1)) a2 = np.array([10, 24], dtype='int32') rhs[a2] += np.array([[ 49.185], [ 11.499]]) a2 = np.array([5, 35], dtype='int32') rhs[a2] += np.array([[ 411.152], [ 141.49990185]]) xsol = spsolve(xtemp,rhs) # NOT working well under scipy '0.14.0' print(xsol) From sturla.molden at gmail.com Wed Nov 19 21:37:03 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 20 Nov 2014 03:37:03 +0100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: Message-ID: On 18/11/14 12:44, David Cournapeau wrote: > P.S: one should not use -ff2c flags. If it is needed your ABI wrappers are to blame ;-) Sturla From sturla.molden at gmail.com Wed Nov 19 22:11:32 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 20 Nov 2014 04:11:32 +0100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: On 14/11/14 08:55, Matthew Brett wrote: > The cran fortran is the standard recommendation because it compiles > both 32 and 64 bit binaries, if given the correct -arch flags; I don't > think that's true with the official gfortran binary I just checked this, it actually builds both. If I pass -m32 or -arch i386 it creates a 32-bit binary. If I pass -m64 or -arch x86_64 it creates a 64-bit binary. The default is 64 bit. I really think we should start to recommend the gfortran wiki binaries: - It is easy to download and install (.dmg installer) - It is a recent gfortran (currently 4.9.0 and 4.8.2). - It is configured and built by the gfortran team. - It can build SciPy and the test suite passes. - It is configured to be compatible with Apple's Xcode command line utils (including clang and clang++). - It builds 32-bit and 64-bit binaries. https://gcc.gnu.org/wiki/GFortranBinaries Sturla From matthew.brett at gmail.com Thu Nov 20 01:39:47 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Wed, 19 Nov 2014 22:39:47 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: Hi, On Wed, Nov 19, 2014 at 7:11 PM, Sturla Molden wrote: > On 14/11/14 08:55, Matthew Brett wrote: > >> The cran fortran is the standard recommendation because it compiles >> both 32 and 64 bit binaries, if given the correct -arch flags; I don't >> think that's true with the official gfortran binary > > I just checked this, it actually builds both. > > If I pass -m32 or -arch i386 it creates a 32-bit binary. > > If I pass -m64 or -arch x86_64 it creates a 64-bit binary. > > The default is 64 bit. > > > I really think we should start to recommend the gfortran wiki binaries: > > - It is easy to download and install (.dmg installer) > > - It is a recent gfortran (currently 4.9.0 and 4.8.2). > > - It is configured and built by the gfortran team. > > - It can build SciPy and the test suite passes. > > - It is configured to be compatible with Apple's Xcode command line > utils (including clang and clang++). > > - It builds 32-bit and 64-bit binaries. > > https://gcc.gnu.org/wiki/GFortranBinaries Sorry, the point I was trying to make is that the CRAN gfortran builds fat binaries (containing both i386 and x86_64), matching the (dual arch) Python.org and system Python architectures. Of course you can do that with the gcc gfortran, but only by doing a complicated two pass compile (that was how I was building the ATLAS binaries), Cheers, Matthew From sturla.molden at gmail.com Thu Nov 20 02:24:27 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 20 Nov 2014 08:24:27 +0100 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: On 20/11/14 07:39, Matthew Brett wrote: > Sorry, the point I was trying to make is that the CRAN gfortran builds > fat binaries (containing both i386 and x86_64), matching the (dual > arch) Python.org and system Python architectures. I see. But it is still a very old gfortran. Modern Fortran code will e.g. use ISO C bindings (Fortran 2003) for interfacing with C and the IEEE environment (Fortran 2008) for consistent floating point arithmetics. It would be sad if an old CRAN gfortran prevents future additions to SciPy from using these rather essential Fortran tools. Sturla From matthew.brett at gmail.com Thu Nov 20 03:14:42 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Thu, 20 Nov 2014 00:14:42 -0800 Subject: [SciPy-User] problems building scipy on Yosemite. In-Reply-To: References: <926214362437549941.501142sturla.molden-gmail.com@news.gmane.org> <237153927437629456.613229sturla.molden-gmail.com@news.gmane.org> Message-ID: On Wed, Nov 19, 2014 at 11:24 PM, Sturla Molden wrote: > On 20/11/14 07:39, Matthew Brett wrote: > >> Sorry, the point I was trying to make is that the CRAN gfortran builds >> fat binaries (containing both i386 and x86_64), matching the (dual >> arch) Python.org and system Python architectures. > > I see. But it is still a very old gfortran. > > Modern Fortran code will e.g. use ISO C bindings (Fortran 2003) for > interfacing with C and the IEEE environment (Fortran 2008) for > consistent floating point arithmetics. It would be sad if an old CRAN > gfortran prevents future additions to SciPy from using these rather > essential Fortran tools. Sure. And the dual arch issue mostly comes up for building redistributable binaries - not many people need to build a dual arch numpy or scipy binary. Cheers, Matthew From ram at rachum.com Sat Nov 22 14:39:21 2014 From: ram at rachum.com (Ram Rachum) Date: Sat, 22 Nov 2014 21:39:21 +0200 Subject: [SciPy-User] ANN: First release of combi, a combinatorics package for Python Message-ID: Hi everyone, Just a quick announcement: Last week I made the first release of an open-source package called Combi. It's a package for doing combinatorics in Python. The pitch: Combi lets you explore spaces of permutations and combinations as if they were Python sequences, but without generating all the permutations/combinations in advance. It lets you specify a lot of special conditions on these spaces. It also provides a few more classes that might be useful in combinatorics programming. Information about it: https://pypi.python.org/pypi/combi I hope this package will be useful to people here. Thanks, Ram. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guziy.sasha at gmail.com Sat Nov 22 14:47:55 2014 From: guziy.sasha at gmail.com (Oleksandr Huziy) Date: Sat, 22 Nov 2014 14:47:55 -0500 Subject: [SciPy-User] ANN: First release of combi, a combinatorics package for Python In-Reply-To: References: Message-ID: Hi Ram: Just looked at the tutorial. Great job and thanks for sharing it! Cheers 2014-11-22 14:39 GMT-05:00 Ram Rachum : > Hi everyone, > > Just a quick announcement: Last week I made the first release of an > open-source package called Combi. It's a package for doing combinatorics in > Python. > > The pitch: > > > Combi lets you explore spaces of permutations and combinations as if they > were Python sequences, but without generating all the > permutations/combinations in advance. It lets you specify a lot of special > conditions on these spaces. It also provides a few more classes that might > be useful in combinatorics programming. > > > Information about it: > > https://pypi.python.org/pypi/combi > > I hope this package will be useful to people here. > > > Thanks, > Ram. > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > > -- Sasha -------------- next part -------------- An HTML attachment was scrubbed... URL: From ram at rachum.com Mon Nov 24 05:03:40 2014 From: ram at rachum.com (Ram Rachum) Date: Mon, 24 Nov 2014 12:03:40 +0200 Subject: [SciPy-User] ANN: First release of combi, a combinatorics package for Python In-Reply-To: References: Message-ID: Thanks Oleksandr! On Sat, Nov 22, 2014 at 9:47 PM, Oleksandr Huziy wrote: > Hi Ram: > > Just looked at the tutorial. Great job and thanks for sharing it! > > Cheers > > 2014-11-22 14:39 GMT-05:00 Ram Rachum : > >> Hi everyone, >> >> Just a quick announcement: Last week I made the first release of an >> open-source package called Combi. It's a package for doing combinatorics in >> Python. >> >> The pitch: >> >> >> Combi lets you explore spaces of permutations and combinations as if they >> were Python sequences, but without generating all the >> permutations/combinations in advance. It lets you specify a lot of special >> conditions on these spaces. It also provides a few more classes that might >> be useful in combinatorics programming. >> >> >> Information about it: >> >> https://pypi.python.org/pypi/combi >> >> I hope this package will be useful to people here. >> >> >> Thanks, >> Ram. >> >> _______________________________________________ >> SciPy-User mailing list >> SciPy-User at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-user >> >> > > > -- > Sasha > > _______________________________________________ > SciPy-User mailing list > SciPy-User at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Mon Nov 24 21:26:16 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 24 Nov 2014 18:26:16 -0800 Subject: [SciPy-User] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <547269FF.7010905@iki.fi> References: <547269FF.7010905@iki.fi> Message-ID: Hi, On Sun, Nov 23, 2014 at 3:13 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finally finished preparing the Scipy 0.15.0 beta 1 release. > Please try it and report any issues on the scipy-dev mailing list, > and/or on Github. > > If no surprises turn up, the final release is planned on Dec 20 in > three weeks. > > Source tarballs and full release notes are available at > https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ > Binary installers should also be up soon. > > Best regards, > Pauli Virtanen > > > - -------------------------------------------- > > SciPy 0.15.0 is the culmination of 6 months of hard work. It contains > several 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.16.x branch, and on adding > new features on the master branch. > > This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or > greater. > > > New features > ============ > > Linear Programming Interface > - - ---------------------------- > > The new function ``scipy.optimize.linprog`` provides a generic > linear programming similar to the way ``scipy.optimize.minimize`` > provides a generic interface to nonlinear programming optimizers. > Currently the only method supported is *simplex* which provides > a two-phase, dense-matrix-based simplex algorithm. Callbacks > functions are supported,allowing the user to monitor the progress > of the algorithm. > > Differential_evolution, a global optimizer > - - ------------------------------------------ > > A new ``differential_evolution`` function is available in the > ``scipy.optimize`` > module. Differential Evolution is an algorithm used for finding the > global > minimum of multivariate functions. It is stochastic in nature (does > not use > gradient methods), and can search large areas of candidate space, but > often > requires larger numbers of function evaluations than conventional gradient > based techniques. > > ``scipy.signal`` improvements > - - ----------------------------- > > The function ``max_len_seq`` was added, which computes a Maximum > Length Sequence (MLS) signal. > > ``scipy.integrate`` improvements > - - -------------------------------- > > It is now possible to use ``scipy.integrate`` routines to integrate > multivariate ctypes functions, thus avoiding callbacks to Python and > providing better performance. > > ``scipy.linalg`` improvements > - - ----------------------------- > > Add function ``orthogonal_procrustes`` for solving the procrustes > linear algebra problem. > > ``scipy.sparse`` improvements > - - ----------------------------- > > ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its > main input. > > ``scipy.special`` improvements > - - ------------------------------ > > Values of ellipsoidal harmonic (i.e. Lame) functions and associated > normalization constants can be now computed using ``ellip_harm``, > ``ellip_harm_2``, and ``ellip_normal``. > > New convenience functions ``entr``, ``rel_entr`` ``kl_div``, > ``huber``, and ``pseudo_huber`` were added. > > ``scipy.sparse.csgraph`` improvements > - - ------------------------------------- > > Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` > for computing reorderings of sparse graphs were added. > > ``scipy.stats`` improvements > - - ---------------------------- > > Added a Dirichlet distribution as multivariate distribution. > > The new function ``scipy.stats.median_test`` computes Mood's median test. > > The new function ``scipy.stats.combine_pvalues`` implements Fisher's > and Stouffer's methods for combining p-values. > > ``scipy.stats.describe`` returns a namedtuple rather than a tuple, > allowing > users to access results by index or by name. > > Deprecated features > =================== > > The ``scipy.weave`` module is deprecated. It was the only module > never ported > to Python 3.x, and is not recommended to be used for new code - use Cython > instead. In order to support existing code, ``scipy.weave`` has been > packaged > separately: `https://github.com/scipy/weave`_. It is a pure Python > package, and > can easily be installed with ``pip install weave``. > > ``scipy.special.bessel_diff_formula`` is deprecated. It is a private > function, > and therefore will be removed from the public API in a following release. > > > Backwards incompatible changes > ============================== > > scipy.ndimage > - - ------------- > > The functions ``scipy.ndimage.minimum_positions``, > ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return > positions as ints instead of floats. > > scipy.integrate > - - --------------- > > The format of banded Jacobians in ``scipy.integrate.ode`` solvers is > changed. Note that the previous documentation of this feature was > erroneous. I ran against current scipy stack packages, and get these errors: https://travis-ci.org/MacPython/scipy-stack-osx-testing/jobs/42022929#L324 ====================================================================== ERROR: test_netcdf.test_byte_gatts ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/test_netcdf.py", line 268, in test_byte_gatts f = netcdf_file(filename, 'w') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/netcdf.py", line 226, in __init__ self.fp = open(self.filename, '%sb' % omode) IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/data/g_byte_atts.nc' ====================================================================== ERROR: test_netcdf.test_open_append ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/test_netcdf.py", line 284, in test_open_append f = netcdf_file(filename, 'w') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/netcdf.py", line 226, in __init__ self.fp = open(self.filename, '%sb' % omode) IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/data/append_dat.nc' This turns out to be because the netcdf tests are trying to write into the scipy/io/tests/data directory: https://github.com/scipy/scipy/pull/4198 Otherwise, it looks clean. I uploaded the OSX wheels to sourceforge. Cheers, Matthew From cournape at gmail.com Tue Nov 25 07:53:03 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 25 Nov 2014 12:53:03 +0000 Subject: [SciPy-User] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <547269FF.7010905@iki.fi> References: <547269FF.7010905@iki.fi> Message-ID: Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker (the issue arises on scipy master as well as 0.14.1) ? On Sun, Nov 23, 2014 at 11:13 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finally finished preparing the Scipy 0.15.0 beta 1 release. > Please try it and report any issues on the scipy-dev mailing list, > and/or on Github. > > If no surprises turn up, the final release is planned on Dec 20 in > three weeks. > > Source tarballs and full release notes are available at > https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ > Binary installers should also be up soon. > > Best regards, > Pauli Virtanen > > > - -------------------------------------------- > > SciPy 0.15.0 is the culmination of 6 months of hard work. It contains > several 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.16.x branch, and on adding > new features on the master branch. > > This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or > greater. > > > New features > ============ > > Linear Programming Interface > - - ---------------------------- > > The new function ``scipy.optimize.linprog`` provides a generic > linear programming similar to the way ``scipy.optimize.minimize`` > provides a generic interface to nonlinear programming optimizers. > Currently the only method supported is *simplex* which provides > a two-phase, dense-matrix-based simplex algorithm. Callbacks > functions are supported,allowing the user to monitor the progress > of the algorithm. > > Differential_evolution, a global optimizer > - - ------------------------------------------ > > A new ``differential_evolution`` function is available in the > ``scipy.optimize`` > module. Differential Evolution is an algorithm used for finding the > global > minimum of multivariate functions. It is stochastic in nature (does > not use > gradient methods), and can search large areas of candidate space, but > often > requires larger numbers of function evaluations than conventional gradient > based techniques. > > ``scipy.signal`` improvements > - - ----------------------------- > > The function ``max_len_seq`` was added, which computes a Maximum > Length Sequence (MLS) signal. > > ``scipy.integrate`` improvements > - - -------------------------------- > > It is now possible to use ``scipy.integrate`` routines to integrate > multivariate ctypes functions, thus avoiding callbacks to Python and > providing better performance. > > ``scipy.linalg`` improvements > - - ----------------------------- > > Add function ``orthogonal_procrustes`` for solving the procrustes > linear algebra problem. > > ``scipy.sparse`` improvements > - - ----------------------------- > > ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its > main input. > > ``scipy.special`` improvements > - - ------------------------------ > > Values of ellipsoidal harmonic (i.e. Lame) functions and associated > normalization constants can be now computed using ``ellip_harm``, > ``ellip_harm_2``, and ``ellip_normal``. > > New convenience functions ``entr``, ``rel_entr`` ``kl_div``, > ``huber``, and ``pseudo_huber`` were added. > > ``scipy.sparse.csgraph`` improvements > - - ------------------------------------- > > Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` > for computing reorderings of sparse graphs were added. > > ``scipy.stats`` improvements > - - ---------------------------- > > Added a Dirichlet distribution as multivariate distribution. > > The new function ``scipy.stats.median_test`` computes Mood's median test. > > The new function ``scipy.stats.combine_pvalues`` implements Fisher's > and Stouffer's methods for combining p-values. > > ``scipy.stats.describe`` returns a namedtuple rather than a tuple, > allowing > users to access results by index or by name. > > Deprecated features > =================== > > The ``scipy.weave`` module is deprecated. It was the only module > never ported > to Python 3.x, and is not recommended to be used for new code - use Cython > instead. In order to support existing code, ``scipy.weave`` has been > packaged > separately: `https://github.com/scipy/weave`_. It is a pure Python > package, and > can easily be installed with ``pip install weave``. > > ``scipy.special.bessel_diff_formula`` is deprecated. It is a private > function, > and therefore will be removed from the public API in a following release. > > > Backwards incompatible changes > ============================== > > scipy.ndimage > - - ------------- > > The functions ``scipy.ndimage.minimum_positions``, > ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return > positions as ints instead of floats. > > scipy.integrate > - - --------------- > > The format of banded Jacobians in ``scipy.integrate.ode`` solvers is > changed. Note that the previous documentation of this feature was > erroneous. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlRyaf8ACgkQ6BQxb7O0pWC7XQCeNtdJD4ZNDXvFeNFs7N3KjQn6 > 8QkAoK3pFmhMrTwCrgkusl+fRNMboN2r > =WSpM > -----END PGP SIGNATURE----- > _______________________________________________ > 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 cournape at gmail.com Tue Nov 25 13:33:25 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 25 Nov 2014 18:33:25 +0000 Subject: [SciPy-User] [Numpy-discussion] Scipy 0.15.0 beta 1 release In-Reply-To: <135351674438631559.674600sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <135351674438631559.674600sturla.molden-gmail.com@news.gmane.org> Message-ID: On Tue, Nov 25, 2014 at 6:10 PM, Sturla Molden wrote: > David Cournapeau wrote: > > Shall we consider > href="https://github.com/scipy/scipy/issues/4168"> > https://github.com/scipy/scipy/issues/4168 > > to be a > > blocker (the issue arises on scipy master as well as 0.14.1) ? > > > > It is really bad, but does anyone know what is really going on? > Yes, it is in the bug report. David > > Which changes to NumPy set this off? > > Sturla > > _______________________________________________ > 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 njs at pobox.com Tue Nov 25 13:39:28 2014 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Nov 2014 18:39:28 +0000 Subject: [SciPy-User] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: References: <547269FF.7010905@iki.fi> Message-ID: On Tue, Nov 25, 2014 at 12:53 PM, David Cournapeau wrote: > Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker > (the issue arises on scipy master as well as 0.14.1) ? Do you think there's anything scipy can do about it? It looks like a pure numpy bug to me. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org From njs at pobox.com Tue Nov 25 14:14:46 2014 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Nov 2014 19:14:46 +0000 Subject: [SciPy-User] [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: On Tue, Nov 25, 2014 at 7:07 PM, Sturla Molden wrote: > Nathaniel Smith wrote: >> On Tue, Nov 25, 2014 at 12:53 PM, David Cournapeau wrote: >>> Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker >>> (the issue arises on scipy master as well as 0.14.1) ? >> >> Do you think there's anything scipy can do about it? It looks like a >> pure numpy bug to me. > > I think we should assume it is not a bug in NumPy. There is nothing that > dictates that an ndarray's buffer must be aligned. It can just as well be > an unaligned view or wrap an external buffer. An ndarray is valud with any > alignment, but it does not mean it can be used with intent(inout) in f2py. > > Then by deduction if it is not a NumPy bug it must be a SciPy bug, which > means the bug must be the unprotected use of intent(inout) in the f2py > wrapper. I would think it is the responsibility of SciPy to ensure that > whatever is passed with intent(inout) in SciPy is properly aligned. In general you have a point, but in this case the reason the array is "unaligned" is that numpy is being overly strict about its definition of "aligned". In fact, it's so strict that numpy itself doesn't provide any standard and reliable way to *create* an aligned array by this definition. (I guess scipy could create an overallocated copy and then take a slice at the right offset, but asking scipy to use such hacks to work around our bugs is clearly wrong.) -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org From sturla.molden at gmail.com Tue Nov 25 17:44:30 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 22:44:30 +0000 (UTC) Subject: [SciPy-User] [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: <612736082438647533.041207sturla.molden-gmail.com@news.gmane.org> Nathaniel Smith wrote: > (I guess scipy could create an overallocated copy and then take a > slice at the right offset, but asking scipy to use such hacks to work > around our bugs is clearly wrong.) Theoretically this would work, but it wouldn't be nice. Another solution is to replace malloc() with an aligned malloc. There is a widely known one which can be used on top of malloc (just a few lines of extra code). On later Visual Studio versions there us also _aligned_malloc in the CRT, but I prefer not to use it to support older compilers. On Linux and OS X there is of course posix_memalign. Couldn't we just ask npy_malloc to use an aligned allocator? It would just be a tiny PR. Sturla From sturla.molden at gmail.com Tue Nov 25 18:07:43 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 23:07:43 +0000 (UTC) Subject: [SciPy-User] [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <612736082438647533.041207sturla.molden-gmail.com@news.gmane.org> Message-ID: <1982716139438649349.839485sturla.molden-gmail.com@news.gmane.org> Sturla Molden wrote: > Couldn't we just ask npy_malloc to use an aligned allocator? It would just > be a tiny PR. Sorry I meant PyArray_malloc. If we use an aligned malloc on top of PyMem_Malloc it would just be a change of the PyArray_malloc definition in ndarraytypes.h to a slightly more complicated macro. Sturla From sturla.molden at gmail.com Wed Nov 26 03:45:51 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 26 Nov 2014 09:45:51 +0100 Subject: [SciPy-User] [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <1982716139438649349.839485sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <612736082438647533.041207sturla.molden-gmail.com@news.gmane.org> <1982716139438649349.839485sturla.molden-gmail.com@news.gmane.org> Message-ID: On 26/11/14 00:07, Sturla Molden wrote: > If we use an aligned malloc on top of PyMem_Malloc it would just be a > change of the PyArray_malloc definition in ndarraytypes.h to a slightly > more complicated macro. Here is a suggestion for an aligned allocator: https://github.com/numpy/numpy/issues/5312 Sturla From cimrman3 at ntc.zcu.cz Fri Nov 28 09:54:08 2014 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Fri, 28 Nov 2014 15:54:08 +0100 Subject: [SciPy-User] ANN: SfePy 2014.4 Message-ID: <54788C90.1080405@ntc.zcu.cz> I am pleased to announce release 2014.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - preliminary support for 1D problems - data probes using pyVTK library 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): Lubos Kejzlar, Vladimir Lukes