Mailman 3 May 2012 - SciPy-User

scipy test error: undefined symbol: ATL_buildinfo
by Sergio Rojas 20 May '12

20 May '12

Hello guys, After struggling for a while, I just finished the installation of scipy using the intel mkl library. Ungracefully the tests ended with an error regarding "undefined symbol: ATL_buildinfo" (see below) Can this scipy installation live with this error? or Is it prone to throw out wrong computations? Also, why the number of ran test is not a fix number (running the tests using a scipy/Atlas installation finished succesfully indicating: Ran 5832 tests in 422.155s OK (KNOWNFAIL=14, SKIP=42), but the scipy/mkl tests ended with Ran 5833 tests in 448.386s FAILED (KNOWNFAIL=14, SKIP=34, errors=1))? what is the meaning of KNOWNFAIL=14? Sergio >$ python_mkl Python 2.7.2 (default, May 16 2012, 13:06:17) [GCC 4.6.1] on linux3 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> scipy.show_config() umfpack_info: NOT AVAILABLE lapack_opt_info: libraries = ['mkl_lapack95_ilp64', 'mkl_lapack95_lp64', 'mkl_rt', 'mkl_intel _lp64', 'mkl_intel_thread', 'mkl_core', 'pthread'] library_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/l ib/intel64'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/i nclude'] blas_opt_info: libraries = ['mkl_rt', 'mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'pt hread'] library_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/l ib/intel64'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/i nclude'] lapack_mkl_info: libraries = ['mkl_lapack95_ilp64', 'mkl_lapack95_lp64', 'mkl_rt', 'mkl_intel _lp64', 'mkl_intel_thread', 'mkl_core', 'pthread'] library_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/l ib/intel64'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/i nclude'] blas_mkl_info: libraries = ['mkl_rt', 'mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'pt hread'] library_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/l ib/intel64'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/i nclude'] mkl_info: libraries = ['mkl_rt', 'mkl_intel_lp64', 'mkl_intel_thread', 'mkl_core', 'pt hread'] library_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/l ib/intel64'] define_macros = [('SCIPY_MKL_H', None)] include_dirs = ['/home/srojas/myPROG/IntelC/composer_xe_2011_sp1.7.256/mkl/i nclude'] >>> scipy.test('full', verbose=2) Running unit tests for scipy NumPy version 1.6.1 NumPy is installed in /home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-pac kages/numpy SciPy version 0.10.1 SciPy is installed in /home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-pac kages/scipy Python version 2.7.2 (default, May 16 2012, 13:06:17) [GCC 4.6.1] nose version 1.1.2 ... ... (DELETED OUTPUT) ... ====================================================================== ERROR: Failure: ImportError (/home/srojas/myPROG/Python272GnuMKL/lib/python2.7/s ite-packages/scipy/linalg/atlas_version.so: undefined symbol: ATL_buildinfo) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-packages/nose/loa der.py", line 390, in loadTestsFromName addr.filename, addr.module) File "/home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-packages/nose/imp orter.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-packages/nose/imp orter.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-packages/scipy/li nalg/tests/test_atlas_version.py", line 6, in <module> import scipy.linalg.atlas_version ImportError: /home/srojas/myPROG/Python272GnuMKL/lib/python2.7/site-packages/sci py/linalg/atlas_version.so: undefined symbol: ATL_buildinfo ---------------------------------------------------------------------- Ran 5833 tests in 448.386s FAILED (KNOWNFAIL=14, SKIP=34, errors=1) <nose.result.TextTestResult run=5833 errors=1 failures=0>

2 1

ANN: NumPy 1.6.2 released
by Ralf Gommers 20 May '12

20 May '12

Hi, I'm pleased to announce the availability of NumPy 1.6.2. This is a maintenance release. Due to the delay of the NumPy 1.7.0, this release contains far more fixes than a regular NumPy bugfix release. It also includes a number of documentation and build improvements. Sources and binary installers can be found at <https://sourceforge.net/projects/numpy/files/NumPy/1.6.2rc1/> http://sourceforge.net/projects/numpy/files/NumPy/1.6.2/, release notes are copied below. Thanks to everyone who contributed to this release. Enjoy, The NumPy developers ========================= NumPy 1.6.2 Release Notes ========================= This is a bugfix release in the 1.6.x series. Due to the delay of the NumPy 1.7.0 release, this release contains far more fixes than a regular NumPy bugfix release. It also includes a number of documentation and build improvements. ``numpy.core`` issues fixed --------------------------- #2063 make unique() return consistent index #1138 allow creating arrays from empty buffers or empty slices #1446 correct note about correspondence vstack and concatenate #1149 make argmin() work for datetime #1672 fix allclose() to work for scalar inf #1747 make np.median() work for 0-D arrays #1776 make complex division by zero to yield inf properly #1675 add scalar support for the format() function #1905 explicitly check for NaNs in allclose() #1952 allow floating ddof in std() and var() #1948 fix regression for indexing chararrays with empty list #2017 fix type hashing #2046 deleting array attributes causes segfault #2033 a**2.0 has incorrect type #2045 make attribute/iterator_element deletions not segfault #2021 fix segfault in searchsorted() #2073 fix float16 __array_interface__ bug ``numpy.lib`` issues fixed -------------------------- #2048 break reference cycle in NpzFile #1573 savetxt() now handles complex arrays #1387 allow bincount() to accept empty arrays #1899 fixed histogramdd() bug with empty inputs #1793 fix failing npyio test under py3k #1936 fix extra nesting for subarray dtypes #1848 make tril/triu return the same dtype as the original array #1918 use Py_TYPE to access ob_type, so it works also on Py3 ``numpy.f2py`` changes ---------------------- ENH: Introduce new options extra_f77_compiler_args and extra_f90_compiler_args BLD: Improve reporting of fcompiler value BUG: Fix f2py test_kind.py test ``numpy.poly`` changes ---------------------- ENH: Add some tests for polynomial printing ENH: Add companion matrix functions DOC: Rearrange the polynomial documents BUG: Fix up links to classes DOC: Add version added to some of the polynomial package modules DOC: Document xxxfit functions in the polynomial package modules BUG: The polynomial convenience classes let different types interact DOC: Document the use of the polynomial convenience classes DOC: Improve numpy reference documentation of polynomial classes ENH: Improve the computation of polynomials from roots STY: Code cleanup in polynomial [*]fromroots functions DOC: Remove references to cast and NA, which were added in 1.7 ``numpy.distutils`` issues fixed ------------------------------- #1261 change compile flag on AIX from -O5 to -O3 #1377 update HP compiler flags #1383 provide better support for C++ code on HPUX #1857 fix build for py3k + pip BLD: raise a clearer warning in case of building without cleaning up first BLD: follow build_ext coding convention in build_clib BLD: fix up detection of Intel CPU on OS X in system_info.py BLD: add support for the new X11 directory structure on Ubuntu & co. BLD: add ufsparse to the libraries search path. BLD: add 'pgfortran' as a valid compiler in the Portland Group BLD: update version match regexp for IBM AIX Fortran compilers. ``numpy.random`` issues fixed ----------------------------- BUG: Use npy_intp instead of long in mtrand

1 0

SciPy installation troubles on CentOS 6.2
by Magician 20 May '12

20 May '12

Hi All, I'm trying to build SciPy from source code, but I have some troubles. My environment is below: > CentOS 6.2 on VMware Fusion 4.1.2 (CentOS was installed as Software Development WS) > Python 2.7.3 (already built from sources, installed at /usr/local/python-2.7.3) > NumPy 1.6.1, SciPy 0.10.1, ATLAS 3.8.4, Lapack 3.4.1 (now trying to build) I and my colleagues (other users) want to use recent Python, so I installed Python from sources, and I can't install SciPy by using yum command. Now I'm facing ATLAS compiling errors. Configuration options are "--prefix=/usr/local/atlas-3.8.4 -Fa alg -fPIC". I tried to build it for several times, and always I got errors as below: > res/dgemvN_6_75 : VARIATION EXCEEDS TOLERENCE, RERUN WITH HIGHER REPS. > > ATL_gemvN_mm.c : 1257.99 > ATL_gemvN_1x1_1.c : 581.74 > ATL_gemvN_1x1_1a.c : 1589.45 > ATL_gemvN_4x2_0.c : 813.13 > ATL_gemvN_4x4_1.c : 755.54 > make[3]: *** [res/dMVRES] Error 255 > make[3]: Leaving directory `/home/magician/Desktop/ATLAS/build/tune/blas/gemv' > make[2]: *** [/home/magician/Desktop/ATLAS/build/tune/blas/gemv/res/dMVRES] Error 2 > make[2]: Leaving directory `/home/magician/Desktop/ATLAS/build/bin' > ERROR 734 DURING MVTUNE!!. CHECK INSTALL_LOG/dMVTUNE.LOG FOR DETAILS. > make[2]: Entering directory `/home/magician/Desktop/ATLAS/build/bin' > cd /home/magician/Desktop/ATLAS/build ; make error_report > make[3]: Entering directory `/home/magician/Desktop/ATLAS/build' > make -f Make.top error_report > make[4]: Entering directory `/home/magician/Desktop/ATLAS/build' > uname -a 2>&1 >> bin/INSTALL_LOG/ERROR.LOG > gcc -v 2>&1 >> bin/INSTALL_LOG/ERROR.LOG > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) > gcc -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG > gcc: '-V' option must have argument > make[4]: [error_report] Error 1 (ignored) > gcc --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG > tar cf error_Corei264SSE3.tar Make.inc bin/INSTALL_LOG/* > gzip --best error_Corei264SSE3.tar > mv error_Corei264SSE3.tar.gz error_Corei264SSE3.tgz > make[4]: Leaving directory `/home/magician/Desktop/ATLAS/build' > make[3]: Leaving directory `/home/magician/Desktop/ATLAS/build' > make[2]: Leaving directory `/home/magician/Desktop/ATLAS/build/bin' > Error report error_<ARCH>.tgz has been created in your top-level ATLAS > directory. Be sure to include this file in any help request. > cat: ../../CONFIG/error.txt: No such file or directory > cat: ../../CONFIG/error.txt: No such file or directory > make[1]: *** [build] Error 255 > make[1]: Leaving directory `/home/magician/Desktop/ATLAS/build' > make: *** [build] Error 2 It's very troublesome for me to build ATLAS by myself. My purpose is just using SciPy on my Python. Even if it's optimized not so good for my environment, it's OK. Is there an easy or a sure way to build and install SciPy? Magician

2 1

Re: [SciPy-User] about scipy performance
by David Baddeley 18 May '12

18 May '12

Is this reproducible, or could it just be timing noise? In general though, I'm not sure you can expect performance to be strictly monotonic in k - there are all sorts of issues (e.g. cache coherency) which can make some sizes more efficient than others. The departures from monotonicity that you see are really rather small compared to those which are present in e.g. fftw. Cheers, David ------------------------------ On Sat, May 19, 2012 8:13 AM NZST Sergio Rojas wrote: >Running the performance test of scipy presented at > [ http://software.intel.com/en-us/articles/numpy-scipy-with-mkl/ ] I found it strange a > decrease in the time that takes the computation for a large K value (see for instance the value of > tm corresponding to k=192 and k=200). Does this behaviour makes sense? Is there any test suite available > to better check the performance of a scipy installation? > > Sergio > PD. the output of np.show_config() is shown below the data. > > K TM GFLOPS > 64, 0.2182408, 34.91556 > 80, 0.2414728, 39.50755 > 96, 0.2986258, 38.37579 > 104, 0.3231602, 38.43295 > 112, 0.3429056, 39.01948 > 120, 0.3645972, 39.33108 > 128, 0.4074092, 37.55438 > 144, 0.445568, 38.6473 > 160, 0.4914636, 38.9449 > 176, 0.5274322, 39.92931 > 192, 0.6281674, 36.5826 > 200, 0.6149654, 38.92902 > 208, 0.6355928, 39.17603 > 224, 0.673929, 39.79648 > 240, 0.7244088, 39.67373 > 256, 0.8612222, 35.60057 > 384, 1.185954, 38.80421 > > > > atlas_threads_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] > define_macros = [('ATLAS_INFO', '"\\"3.9.72\\"')] > language = f77 > include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] > blas_opt_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] > define_macros = [('ATLAS_INFO', '"\\"3.9.72\\"')] > language = c > include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] > atlas_blas_threads_info: > libraries = ['ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] > define_macros = [('ATLAS_INFO', '"\\"3.9.72\\"')] > language = c > include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] > lapack_opt_info: > libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] > library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] > define_macros = [('ATLAS_INFO', '"\\"3.9.72\\"')] > language = f77 > include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE

1 0

about scipy performance
by Sergio Rojas 18 May '12

18 May '12

Running the performance test of scipy presented at [ http://software.intel.com/en-us/articles/numpy-scipy-with-mkl/ ] I found it strange a decrease in the time that takes the computation for a large K value (see for instance the value of tm corresponding to k=192 and k=200). Does this behaviour makes sense? Is there any test suite available to better check the performance of a scipy installation? Sergio PD. the output of np.show_config() is shown below the data. K TM GFLOPS 64, 0.2182408, 34.91556 80, 0.2414728, 39.50755 96, 0.2986258, 38.37579 104, 0.3231602, 38.43295 112, 0.3429056, 39.01948 120, 0.3645972, 39.33108 128, 0.4074092, 37.55438 144, 0.445568, 38.6473 160, 0.4914636, 38.9449 176, 0.5274322, 39.92931 192, 0.6281674, 36.5826 200, 0.6149654, 38.92902 208, 0.6355928, 39.17603 224, 0.673929, 39.79648 240, 0.7244088, 39.67373 256, 0.8612222, 35.60057 384, 1.185954, 38.80421 atlas_threads_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] define_macros = [('ATLAS_INFO', '"\\"3.9.72\\""')] language = f77 include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] blas_opt_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] define_macros = [('ATLAS_INFO', '"\\"3.9.72\\""')] language = c include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] atlas_blas_threads_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] define_macros = [('ATLAS_INFO', '"\\"3.9.72\\""')] language = c include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] lapack_opt_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/lib'] define_macros = [('ATLAS_INFO', '"\\"3.9.72\\""')] language = f77 include_dirs = ['/home/srojas/myPROG/LapackLib_gfortran/Atlas64b/include'] lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE mkl_info: NOT AVAILABLE

1 0

Re: [SciPy-User] is it possible to constrain the scipy.optimize.curve_fit function?
by federico vaggi 17 May '12

17 May '12

Afaik, there was a big discussion about this a while ago, and the short answer is, currently there is no 'automatic' way to do it. However, in your case, it's pretty easy. Simply define: def func (x, a,b, r): a = abs(a) b = abs(b) r = abs(r) return r + a*np.power(x,-b) And that will do the trick. If you need to more complex boundaries, you can simply use a combination of period functions with a given amplitude or what have you. Alternatively, there are *a lot* of optimization libraries available for Python that are not a part of scipy that offer the possibility to specify boundaries. For example: http://newville.github.com/lmfit-py/ http://ab-initio.mit.edu/wiki/index.php/NLopt_Python_Reference Federico Date: Wed, 16 May 2012 18:20:27 +0200 > From: servant mathieu <servant.mathieu(a)gmail.com> > Subject: [SciPy-User] is it possible to constrain the > scipy.optimize.curve_fit function? > To: scipy-user(a)scipy.org > Message-ID: > <CALnu5bM+c9L7taG_CBHdJhw7xpe5amHSVBRUEX7pa7gnRN+-7Q(a)mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Dear scipy users, > > I'm trying to fit to data a power law of the form : > > > > > def func (x, a,b, r): > > return r + a*np.power(x,-b) > > > > > I would like to constrain the curve_fit routine to only allow > positive parameter values. How is it possible to do so? > > > > Kind regards, > > Mathieu >

2 1

Re: [SciPy-User] is it possible to constrain the scipy.optimize.curve_fit function?
by David Baddeley 17 May '12

17 May '12

I'd caution against using abs, as abs(x) is not differentiable around 0 and could cause a gradient descent solver to get stuck/confused. x**2 on the other hand is fully differentiable, but requires you to take the sqrt of the parameters after fitting. ------------------------------ On Thu, May 17, 2012 9:51 PM NZST federico vaggi wrote: >Afaik, > >there was a big discussion about this a while ago, and the short answer is, >currently there is no 'automatic' way to do it. However, in your case, >it's pretty easy. > >Simply define: > >def func (x, a,b, r): > a = abs(a) > b = abs(b) > r = abs(r) > return r + a*np.power(x,-b) > >And that will do the trick. If you need to more complex boundaries, you >can simply use a combination of period functions with a given amplitude or >what have you. Alternatively, there are *a lot* of optimization libraries >available for Python that are not a part of scipy that offer the >possibility to specify boundaries. > >For example: > >http://newville.github.com/lmfit-py/ >http://ab-initio.mit.edu/wiki/index.php/NLopt_Python_Reference > >Federico > > > >Date: Wed, 16 May 2012 18:20:27 +0200 >> From: servant mathieu <servant.mathieu(a)gmail.com> >> Subject: [SciPy-User] is it possible to constrain the >> scipy.optimize.curve_fit function? >> To: scipy-user(a)scipy.org >> Message-ID: >> <CALnu5bM+c9L7taG_CBHdJhw7xpe5amHSVBRUEX7pa7gnRN+-7Q(a)mail.gmail.com >> > >> Content-Type: text/plain; charset="iso-8859-1" >> >> Dear scipy users, >> >> I'm trying to fit to data a power law of the form : >> >> >> >> >> def func (x, a,b, r): >> >> return r + a*np.power(x,-b) >> >> >> >> >> I would like to constrain the curve_fit routine to only allow >> positive parameter values. How is it possible to do so? >> >> >> >> Kind regards, >> >> Mathieu >>

1 0

is it possible to constrain the scipy.optimize.curve_fit function?
by servant mathieu 17 May '12

17 May '12

Dear scipy users, I'm trying to fit to data a power law of the form : def func (x, a,b, r): return r + a*np.power(x,-b) I would like to constrain the curve_fit routine to only allow positive parameter values. How is it possible to do so? Kind regards, Mathieu

2 2

scipy.odr - Goodness of fit and parameter estimation for explicit orthogonal distance regression
by Markus Baden 16 May '12

16 May '12

Hi list, Currently, I am trying to fit a quadratic curve to a data set which has much larger errors in the x than in the y direction. My errors are assumed to be normally distributed and I want to estimate the confidence interval of the fitted parameters. I have fitted the data two different ways. 1) I neglect the x errors and fit the quadratic by minimizing the weighted residuals (y -f) / sig_y via scipy.optimize.leastsq and 2) I use scipy.odr to fit the parameters. Both result similar fitted parameters. Now I am stuck with estimating the confidence intervals on these errors and I have a couple of questions. For method 1) the reduced chi squared is bad (much larger then 1), because when neglecting the x errors, none of the points actually lie within a couple of standard deviations on the line. However when including the x-errors they all fall nicely onto the line. Is there a way for me to include the x errors into my minimization and goodness of fit estimation via the reduced chi-squared? I came across a remark in the CERN minuit documentation [1], that seemed to approximate the function by a line over the point and then use this to convert x to y errors. I also read something like this in numerical recipes [2], but not for general least squares (only for the case of linear data). Does anyone have any pointers into that direction? My second question is related to method 2). Is there a way of accessing the goodness of fit for ODR, similar to calculating the reduced chi-squared for a fit that only has errors in the y? Another question along this line concerns the scipy.odr.ODR.Output.sd_beta attribute. In the docstring it says it is the standard error of the parameter, does that mean a 1 standard deviation confidence interval? And how exactly are they calculated. Tried to look at the source and in the odrpack guide, but unfortunately couldn't figure that out. I somehow have the feeling, that my problem should be quite standard (goodness of fit with both x and y errors), but so far I could not find a good explanation. Any pointers to textbooks or resources on the web would be greatly appreciated. Best regards, Markus [1] http://wwwasd.web.cern.ch/wwwasd/cgi-bin/listpawfaqs.pl/27 [2] Numerical Recipes in C, Second Edition, Chapter 15.3 "Straight-Line Data with Errors in Both Coordinate"

3 4

Using scipy.io.loadmat to read Matlab containers.Map object?
by Gerrit Holl 15 May '12

15 May '12

Hi, is it possible to use scipy.io.loadmat to read a Matlab containers.Map object? >> cm = containers.Map(); >> cm('abc') = 42; >> save('/tmp/test.mat', 'cm'); In [15]: M = scipy.io.loadmat('/tmp/test.mat') In [16]: M.keys() Out[16]: ['__function_workspace__', 'None', '__version__', '__header__', '__globals__'] In [17]: M["None"] Out[17]: MatlabOpaque([ ('cm', 'MCOS', 'containers.Map', [[3707764736L], [2L], [1L], [1L], [1L], [1L]])], dtype=[('s0', '|O8'), ('s1', '|O8'), ('s2', '|O8'), ('arr', '|O8')]) In [15]: M = scipy.io.loadmat('/tmp/test.mat') In [16]: M.keys() Out[16]: ['__function_workspace__', 'None', '__version__', '__header__', '__globals__'] In [17]: M["None"] Out[17]: MatlabOpaque([ ('cm', 'MCOS', 'containers.Map', [[3707764736L], [2L], [1L], [1L], [1L], [1L]])], dtype=[('s0', '|O8'), ('s1', '|O8'), ('s2', '|O8'), ('arr', '|O8')]) regards, Gerrit. -- Gerrit Holl PhD student at Division of Space Technology, Luleå University of Technology, Kiruna, Sweden http://www.sat.ltu.se/members/gerrit/

2 3