Mailman 3 May 2013 - SciPy-Dev

doc string of brentq
by nicky van foreest 12 May '13

12 May '13

Hi, Perhaps I am just checking an old documentation site... Anyway, on this page: http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.brentq.h… the argument rtol is mentioned as an valid argument to brenqt, but it is not explained on the page. Is this a bug? Nicky

2 2

issue comments out of order
by josef.pktd＠gmail.com 11 May '13

11 May '13

Just an observation (too late to do anything about it) Some comments to trac tickets are in a different sequence in github issues https://github.com/scipy/scipy/issues/2108 http://projects.scipy.org/scipy/ticket/1583 But maybe that's a special case, because the trac ticket comments might have been simultaneously edited during a time when trac was very slow. Josef

1 0

scipy github slow?
by Warren Weckesser 10 May '13

10 May '13

Has anyone else noticed github being very slow this afternoon? Maybe it's the fault of Starbucks' wifi, but other sites don't seem particularly slow. Warren

2 2

Multilinear interpolation
by Pablo Winant 10 May '13

10 May '13

Hi, Continuing a series of thread about interpolation, I have an almost ready implementation of multilinear implementation, that is linear interpolation in each dimension. I have been toying with several implementations - in pure numpy (quite memory hungry) - in cython - using pycuda Obviously, if there is some interest for it in scipy, it would be a good motivation to finish it. There are two main differences with respect to the existing interp routine : - it is independent of fitpack - it extrapolates linearly while the existing routine returns a constant (or NaN) Now I have some questions about it: - in this case I several implementations, in the same library that can potentially be enabled on different systems (with a compiler, with a gpu). I made a python file that tries to import one version after all shadowing slower ones by faster ones. It is meant to replicate the .m/.mex file behavior of Matlab. Is there a better approach ? - the cython code is meant to operate on double* inputs, and is limited to 4 dimensions. It is however very easy to generate single or higher order code. What would you use for that purpose ? Best, Pablo

4 13

GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy
by Blake Griffith 08 May '13

08 May '13

Seeking feedback, comments, and criticism Link: https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown

3 4

PEP8 conformance
by Tim Leslie 07 May '13

07 May '13

Hi All, We've just merged a couple of pull requests which greatly improve the conformance of the scipy code to the pep8 style guidelines: http://www.python.org/dev/peps/pep-0008/ In order to maintain consistency of code, I would like to recommend that before developers commit (or before they submit a PR) they run the "pep8" script over the code to make sure no errors are flagged. The pep8 script can be found here: https://github.com/jcrocholl/pep8 The file tox.ini has been updated to contain a [pep8] section, which contains the current configuration for scipy. In particular, it lists certain error codes which we currently ignore, and automatically generated python files, which we also ignore. NOTE: The latest stable release of pep8 (1.4.5) has a bug which breaks the ignore-file functionality. If you use this version you can expect to see a bunch of errors from the files in sparsetools. The current master branch of pep8 on github has this issue fixed, so it is recommended to use this version. If everything is correctly installed and there are no pep8 errors you should see the following behaviour: ~/src/scipy$ pep8 scipy ~/src/scipy$ Cheers, Tim

2 1

FAIL: test_binom_2 (test_basic.TestCephes)
by Nils Wagner 06 May '13

06 May '13

>>> scipy.__version__ '0.13.0.dev-024abe7' ====================================================================== FAIL: test_binom_2 (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/tests/test_basic.py", line 85, in test_binom_2 atol=1e-10, rtol=1e-10) File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/_testutils.py", line 87, in assert_func_equal fdata.check() File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check assert_(False, "\n".join(msg)) File "/home/nils/local/lib64/python2.7/site-packages/numpy/testing/utils.py", line 41, in assert_ raise AssertionError(msg) AssertionError: Max |adiff|: 2.14065e+273 Max |rdiff|: 1 Bad results (19 out of 2040) for the following points (in output 0): 5.4555947811685144e+16 19.0 => 8.220635246624177e+300 != inf (rdiff 0.0) 2.9763514416313132e+32 9.0 => 5.051203457981723e+286 != inf (rdiff 0.0) 1.6237767391887178e+48 6.0 => 2.5458065428227896e+286 != inf (rdiff 0.0) 8.858667904100795e+63 4.0 => 2.5660342127750743e+254 != inf (rdiff 0.0) 4.832930238571653e+79 3.0 => 1.8813964861410318e+238 != inf (rdiff 0.0) 2.6366508987303447e+95 3.0 => 3.054967851387346e+285 != inf (rdiff 0.0) 1.4384498882876777e+111 2.0 => 1.0345690405574163e+222 != inf (rdiff 0.0) 7.847599703514559e+126 2.0 => 3.07924105533009e+253 != inf (rdiff 0.0) 4.2813323987192907e+142 2.0 => 9.164903554161738e+284 != inf (rdiff 0.0) 2.3357214690900255e+158 1.0 => 2.3357214690900255e+158 != inf (rdiff 0.0) 1.2742749857031426e+174 1.0 => 1.2742749857031426e+174 != inf (rdiff 0.0) 6.951927961775534e+189 1.0 => 6.951927961775534e+189 != inf (rdiff 0.0) 3.792690190732145e+205 1.0 => 3.792690190732145e+205 != inf (rdiff 0.0) 2.0691380811148325e+221 1.0 => 2.0691380811148325e+221 != inf (rdiff 0.0) 1.128837891684693e+237 1.0 => 1.128837891684693e+237 != inf (rdiff 0.0) 6.158482110660179e+252 1.0 => 6.158482110660179e+252 != inf (rdiff 0.0) 3.359818286283898e+268 1.0 => 3.359818286283898e+268 != inf (rdiff 0.0) 1.8329807108323476e+284 1.0 => 1.8329807108323476e+284 != inf (rdiff 0.0) 1e+300 1.0 => 1e+300 != inf (rdiff 0.0) ---------------------------------------------------------------------- Ran 6446 tests in 203.406s FAILED (KNOWNFAIL=27, SKIP=158, failures=2)

2 1

scipy.integrate optimisation for pandas.TimeSeries
by Dražen Lučanin 06 May '13

06 May '13

Hi all, I wrote a GSoC project proposal. Unfortunately I didn't manage to get through a feedback loop to improve it based on your comments - had some trouble registering for the mailing list before. It is up on Melange as "SciPy: Improving Numerical Integration of Time Series" - probably under this link: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/ker… My main motivation is that the current way to integrate a time series in Python (due to Pandas using miliseconds as its underlying structure [1]): integrate.simps(ts, ts.index.astype(np.int64) / 10**9) executes with a big overhead (of first having to divide every element to get a 1 integer unit = 1 second representation) and feels somewhat unpythonic. This gist illustrates the performance overhead that's troubling me: http://nbviewer.ipython.org/5512857 I would like to explore ways to rely on the basic timestamp arithmetic in scipy (dynamically, without introducing any dependencies), instead of forcing the user to transform the whole data domain. If there is any time left after this, the usability of scipy.integrate for time series integration could be further improved by adding some new features to Pandas too [2]. Is there perhaps anyone willing to mentor such work? Regards, Dražen Lučanin [1]: http://stackoverflow.com/questions/15203623/convert-pandas-datetimeindex-to… [2]: https://github.com/pydata/pandas/issues/2704

3 6

Request for extension to scipy.integrate
by Nathan Woods 05 May '13

05 May '13

SciPy's multidimensional integration capabilities are somewhat limited, as mentioned previously: https://github.com/scipy/scipy/issues/2098. Although dblquad and tplquad attempt to address this problem, they do not allow any detailed control over the underlying quad algorithm and there is no option for 4-dimensional integration at all. One obvious instance where this functionality would be desired is in the evaluation of volume integrals in 4-dimensional space-time. Another instance is the integration of discontinuous functions, where access to the "points" option of quad is critical. As it stands, SciPy does not provide any good functionality for either of these situations. I've written a recursive wrapper function for quad that resolves both of these problems, allowing n-dimensional integration with complete specification of options for quad. I've included a test problem that demonstrates the resolution of both of the above problems (just execute the script). I've done my best to document everything, and I've verified the result of the test problem against Mathematica. I would like this code (or equivalent functionality) to be included in the integrate package. I'm open to any feedback or suggestions, particularly with the interface. Nathan Woods """ Recursive integration using SciPy's quad function. Contains the following: class Error - module wrapper for Exception. For future expansion only. function mul_quad - Evaluate multiple integrals using recursive calls to quad. """ from scipy.integrate import quad import numpy class Error(Exception): pass def mul_quad(func,ranges,args=(),opts=(),_depth=0,_int_vars=()): """ Evaluate multiple integrals through recursive calls to scipy.integrate.quad. mul_quad takes care of the programming required to perform nested integration using the 1-dimensional integration routines provided by SciPy's adaptive quadrature function. It extends the capabilities of dblquad and tplquad by allowing for more levels of integration, and allowing the user to specify nearly the full range of options allowed by quad, for each level of integration. Users are cautioned that nested Gaussian integration of this kind is computationally intensive, and may be unsuitable for many nested integrals. Usage: mul_quad(func,ranges,args=(),opts=(),_depth=0,_int_vars=()) Inputs: func - callable, acceptable to SciPy's quad, returning a number. Should accept a float, followed by the contents of _int_vars and args, e.g. if x is a float, args=(1.4,string), and _int_vars = (1,1,3), then func should be of the form func(x,1,1,3,1.4,string). ranges - sequence describing the ranges of integration. Integrals are performed in order, so ranges[0] corresponds to the first argument of func, ranges[1] to the second, and so on. Each element of ranges may be either a constant sequence of length 2 or else a function that returns such a sequence. If a function, then it will be called with all of the integration arguments available to that point. e.g. for func = f(x0,x1,x2,x3), the range of integration for x0 may be defined as either a constant such as (0,1) or as a function range0(x1,x2,x3). The functional range of integration for x1 will be range1(x2,x3), x2 will be range2(x3), and so on. args - optional sequence of arguments. Contains only arguments of func beyond those over which the integration is being performed. opts - optional sequence of options for SciPy's quad. Each element of opts may be specified as either a dictionary or as a function that returns a dictionary similarly to ranges. opts must either be left empty (), or it must be the same length as ranges. Options are passed in the same order as ranges, so opts[0] corresponds to integration over the first argument of func, and so on. The full_output option from quad is not available, due to the difficulty of consolidating the large number of additional outputs. For reference, the default options from quad are: - epsabs = 1.49e-08 - epsrel = 1.49e-08 - limit = 50 - points = None - weight = None - wvar = None - wopts = None (As of Apr 2013) _depth - used to determine level of integration. Should be omitted by the user, except for debugging purposes. _int_vars - contains values of integration variables in inner integration loops. Should not be used manually except for debugging. Returns: out - value of multiple integral in the specified range. abserr - estimate of the absolute error in the result. The maximum value of abserr among all the SciPy quad evaluations. """ global abserr if _depth == 0: abserr = None if not (len(opts) in [0,len(ranges)]): raise Error('opts must be given for all integration levels or none!') total_args = _int_vars+args # Select the range and opts for the given depth of integration. ind = -_depth-1 if callable(ranges[ind]): current_range = ranges[ind](*total_args) else: current_range = ranges[ind] if len(opts) != 0: if callable(opts[ind]): current_opts = opts[ind](*total_args) else: current_opts = opts[ind] else: current_opts = {} try: if current_opts["full_output"] != 0: raise Error('full_output option is disabled!') except(KeyError): pass # Check to make sure that all points lie within the specified range. try: for point in current_opts["points"]: if point < current_range[0] or point > current_range[1]: current_opts["points"].remove(point) except(KeyError): pass if current_range is ranges[0]:# Check to see if down to 1-D integral. func_new = func else: # Define a new integrand. def func_new(*_int_vars): return mul_quad(func,ranges,args=args,opts=opts, _depth=_depth+1,_int_vars=_int_vars) out = quad(func_new,*current_range,args=_int_vars+args,**current_opts) # Track the maximum value of abserr from quad if abserr is None: abserr = out[1] if out[1] > abserr: abserr = out[1] if _depth == 0: return out[0],abserr else: return out[0] if __name__=='__main__': func = lambda x0,x1,x2,x3 : x0**2+x1*x2-x3**3+numpy.sin(x0)+( 1 if (x0-.2*x3-.5-.25*x1>0) else 0) points=[[lambda (x1,x2,x3) : .2*x3+.5+.25*x1],[],[],[]] def opts0(*args,**kwargs): return {'points':[.2*args[2]+.5+.25*args[0]]} print mul_quad(func,[[0,1],[-1,1],[.13,.8],[-.15,1]], opts=[opts0,{},{},{}])

2 3

build systems - removing numscons support
by Ralf Gommers 05 May '13

05 May '13

Hi all, I spent some time fixing building with Bento: https://github.com/scipy/scipy/pull/2447. Try it out if you regularly build scipy - for me it's 5x faster than a distutils build, and the difference is even larger when disregarding the Cythonizing step. We still have support for Numscons, although it has been broken for several months. Supporting three build systems is at least one too many, so I propose to remove the numscons support. Any objections? Ralf

3 3