Mailman 3 May 2012 - SciPy-Dev

scipy.test() runs 0 tests
by Junkshops May 22, 2012

May 22, 2012

Hi all, Hopefully I'm not doing something too stupid here, but I've googled around quite a bit and can't seem to find any tips. Perhaps my google-fu is not strong enough. Anyway, I built scipy 0.11.0 in place, seemingly successfully, in ~/git/scipy. Ubuntu version is 12.04. I haven't added scipy 0.11 to the pypath yet so I'm running in the parent dir. js@ubuntuVB12:~/git/scipy$ sudo aptitude install python-nose <snip> Setting up python-nose (1.1.2-3) ... js@ubuntuVB12:~/git/scipy$ python Python 2.7.3 (default, Apr 20 2012, 22:39:59) [GCC 4.6.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import scipy >>> scipy.test() Running unit tests for scipy NumPy version 1.6.1 NumPy is installed in /usr/lib/python2.7/dist-packages/numpy SciPy version 0.11.0.dev-3852ce2 SciPy is installed in scipy Python version 2.7.3 (default, Apr 20 2012, 22:39:59) [GCC 4.6.3] nose version 1.1.2 ---------------------------------------------------------------------- Ran 0 tests in 0.161s OK <nose.result.TextTestResult run=0 errors=0 failures=0> >>> scipy.test("full") <snip> ---------------------------------------------------------------------- Ran 0 tests in 0.139s OK <nose.result.TextTestResult run=0 errors=0 failures=0> Anyone have any idea what I'm doing wrong? Thanks very much, Gavin

2 2

Code question about signal.ltisys.py
by Warren Weckesser May 22, 2012

May 22, 2012

While taking a look at https://github.com/scipy/scipy/pull/225, which makes a small changes to signal/ltisys.py,I noticed the surrounding code, which has lines like this: self.__dict__['num'], self.__dict__['den'] = normalize(*args) My inclination is to rewrite that as self.num, self.den = normalize(*args) But am I missing something? Warren

2 2

warnings in scipy.stats.entropy
by Skipper Seabold May 22, 2012

May 22, 2012

Currently in scipy.stats.entropy if you are not ignoring them you will see warnings when the function is given a probability of zero even though the case of zero is specifically handled in the function. Rightly or wrongly this makes me cringe. What do people think about fixing this by using seterr explicitly in the function or masking the zeros. Eg., import numpy as np from scipy.stats import entropy prob = np.random.uniform(0,20, size=10) prob[5] = 0 prob = prob/prob.sum() np.seterr(all = 'warn') entropy(prob) # too loud Instead we could do (within entropy) oldstate = np.geterr() np.seterr(divide='ignore', invalid='ignore') entropy(prob) np.seterr(**oldstate) or just mask the zeros in the first place if this is too much idx = prob > 0 -np.sum(prob[idx] * np.log(prob[idx])) Thoughts? Skipper

4 7

Faster Hough/Radon transform (was sum_angle() sum_polar() functions)
by Charles R Harris May 21, 2012

May 21, 2012

Thought I'd advertize this under a different subject heading. The sum_angle function is really the inner loop but the timings are about 10x faster than the Radon transform in skimage, so some here might be interested. Chuck

1 0

minimize(): being strict on options
by Pauli Virtanen May 20, 2012

May 20, 2012

Hi, Currently, the minimize() solvers silently accept unknown (= mistyped or inapplicable) options. It might be useful to change this so that it raises an error if unknown options are passed to a solver. Alternatively, it could raise a warning instead --- when trying out different solvers an error could be a PITA. Code changes: tol = options.get('ftol', 1.48e-8) maxiter = options.get('maxiter', 500) change to tol = options.pop('ftol', 1.48e-8) maxiter = options.pop('maxiter', 500) if options: warnings.warn("Unknown solver options: %r" % sorted(options.keys()), scipy.optimize.OptimizationWarning) and class OptimizationWarning(UserWarning): pass -- Pauli Virtanen

2 1

Re: [SciPy-Dev] minimize(): tolerance unification
by Matt Newville May 20, 2012

May 20, 2012

Hi Pauli, If you're working on unifying the signatures of the various minimizer functions in scipy.optimize (Thanks!! Great!!), I have a small request to try to make the behavior of the user-supplied objective functions more uniform as well. Currently, most solvers expect the objective function to return a scalar, and raise a ValueError if the objective function returns an array. OTOH, scipy.optimize.leastsq() requires the objective function to return an array. As far as I can tell, the docs are actually silent on what the value returned from the objective function should be. Is it worth considering the following change?: For all solvers expecting a scalar result, if the objective function returns an array, convert to (array**2).sum(). Obviously, this implies a 'least squares' approach as the default, which is debatable but also probably defensible. I believe this change would not break existing code (since the user can always return a scalar value), but it would allow more consistent objective functions, making it easier for users to try out different algorithms with the same objective function. Thanks, --Matt

2 1

scikit for virtual instruments?
by alex arsenovic May 20, 2012

May 20, 2012

i was considering creating a scikit to provide a library of virtual instruments. scikit-vi? import skvi? my needs are solely for VISA/GPIB vi's using pyvisa, but the project could support other interfaces as well. perhaps it would provide instances of VI's for specific applications (Voltmeter, Ohmeter, etc) as well as general instruments (Keithely2000). although i dont have a large library of VI's, or plan to write them, i have seen the writing of VI's is being re-done constantly. i think a centralized effort would save a lot of wasted time, as well as provide more robust code. the only existing solution to this that i am aware of is pythics, which i have used and i think its great, but it has a larger-than-necessary scope. a simple project, just for python VI's on Github would be the easiest for people to contribute to (in my opinion) and ease of contribution is necessary for a project such as this. any thoughts? alex

1 0

github: disappearing comments - clarification?
by josef.pktd＠gmail.com May 19, 2012

May 19, 2012

A question for the github experts: Under what scenarios do comments on github pull requests disappear? I've never seen a clear answer just my speculation. (based on: Did it disappear or is my search fu insufficient?) For example, some comments disappear after a rebased force push. all comments or just inline code comments? If a pull request never gets merged and the originating branch is deleted, do the comments also disappear? any other cases of disappearing comments? Thanks, Josef

2 2

minimize(): tolerance unification
by Pauli Virtanen May 19, 2012

May 19, 2012

Hi, One thing which would be useful to bring to conclusion in 0.11.0 in the new minimize() interface: tolerance specification. First, it would be useful if there was a common `tol` keyword in `minimize()` which would just set whatever appropriate tolerance parameters, so that the user wouldn't need to bother about looking into the specific solver documentation. Second, the main bulk of the work is actually mostly finished, but some of the remaining different optimizers still take the termination parameters in a non-standard way: - fmin_cobyla: rhoend The `rhoend` parameter seems essentially equivalent to absolute x-tolerance, and could be renamed to `xtol` in minimize(). - fmin_l_bfgs_b: factr, pgtol The `factr` parameter specifies the absolute and relative f-tolerances as follows: rftol = eps * factr, aftol = eps * factr. In my opinion, the minimize() interface should expose this as the `ftol` parameter, and compute `factr = ftol/np.finfo(float).eps`. The `pgtol` parameter is a criterion for the projected gradient. Could we rename `pgtol` -> `gtol`, as some other routines use `gtol` to specify conditions for the gradient. The documentation could still describe that it's actually for the projected gradient, but I expect most users just don't care. - brent: ftol The `ftol` is actually the relative x-tolerance, and is currently erroneously named in the minimize() interface! - golden: ftol The `ftol` is actually the relative x-tolerance, and is currently erroneously named in the minimize() interface! - fmin_tnc: pgtol Ditto, pgtol -> gtol? -- Pauli Virtanen

1 1

SciPy Docs Edit Privileges
by Josh Lawrence May 16, 2012

May 16, 2012

Hello, I found a typo in one of the doc strings in scipy and figured I should probably start contributing where I can. Could you please give me edit permissions? My username is wa03. Thanks, Josh

2 1