Mailman 3 September 2012 - SciPy-User

Python position in Golden, CO
by Kurt Bendl Sept. 27, 2012

Sept. 27, 2012

Hi folks, I just found out that NREL, in Golden, Colorado, is looking for a "Scientific Python Applications Programmer". It's a contract position (that's how most of us start here.) Here is a link to the job description: http://www.redcanyonsoftware.com/jobs/index.php?id=33 If anyone is interested, please send a resume. I used to contract through these guys, and they were pretty reasonable. Best, Kurt Kurt Bendl Computational Sciences National Renewable Energy Laboratory 15013 Denver West Parkway Golden, CO 80401-3305 desk: 303-275-4617

1 0

Re: [SciPy-User] Flaws in fmin_cobyla
by Robaula Sept. 27, 2012

Sept. 27, 2012

On Sep 26, 2012, at 12:57 AM, scipy-user-request(a)scipy.org Denis Laxalde wrote: > Robaula a ?crit : >> 1. The routine returns only the optimal argument value. No description of the status at the end of the run, such as would be provided by the "Results" class are included. Consequently the user receives no information on the trustworthiness of the returned value. > > You mean `fmin_cobyla`, I guess. See answer to point 4. > >> 2. Although "disp" and "iprint" are among the options in cobyla's calling signature, assigning different values to them has absolutely no effect on the output. > > This is documented. `disp` overrides `iprint`, which is deprecated. Sorry, the documentation is flat wrong. Both disp and iprint are completely, utterly, and totally ignored. See fmin_cobyla line 165. >> 3. The docstring's Examples section mentions several values that would be included in the "Results", but with no indication of where they come from or how the users could get at them. > > Which docstring? > Most of the information comes from the internal solver. > As mentioned in its docstring, `Result` is a subclass of `dict` with > attribute accessors. You may then access attributes with a dot notation > or as a regular dict. I guess we're reading the same documentation, specifically the SciPy Reference Guide of 05 June 2012, pages 401-403, and the fmin_cobyla docstrings. >> 4. The cobyla routine calls the _minimize_cobyla routine, which prepares and returns the "Results" class information. This includes: the optimal value of the argument, the status at end, the success flag value, a message expressing the success flag in English, the optimal value of the function, and the maximum constraint violation. Then the cobyla routine "throws away" all but the first of these values. That occurs because after the cobyla routine receives the "Results" dictionary of values from _minimize_cobyla, it returns, in effect, "Results['x']", i.e., just the "Results" dictionary entry for key 'x'. This is done in line 165 of the cobyla routine. > > The `Result` object was introduced recently, for the `minimize` > interface. It is not returned by `fmin_cobyla` for backwards > compatibility. If you want the full results, use `minimize(..., > method='cobyla', ...)`. > > The old `fmin_` functions and the new `minimize` interface are present > in the 0.11 release, which is good for transition purpose but is also > confusing. We could deprecated the former in the next release I guess. Then I guess we'd have to deprecate nearly all of the optimize and root-finding stuff mentioned in the SciPy Reference Guide on pages 388-442?? I note that Ralf Gomers thinks we should find a better way. Cleaning up the fmin_cobyla documentation can certainly be a start on that, and I'll take that on. However, I think there other, and more important issues here, namely, "How should the new 'minimize' interfaces be documented? How should existing documentation for the "old" interfaces be changed in light of the new 'minimize' approach? How to bring the two of them more nearly into alignment? Are changes to the documentation standards advisable to facilitate this?" Sure, "minimize's" docstring is an excellent start, tho I do see a couple areas where a little more explanation and/or some examples would be helpful. Among other things, I think it would be a lot better to just come out and tell folks what options are available for each of the various "methods", rather than telling them the code sequence to use to view them. Certainly the cobyla options for 'minimize' differ noticeably from those for the fmin_cobyla approach. For example, using fmin_cobyla ignores disp and iprint and never returns 'Results', while using 'minimize' has no iprint option, ignores the disp option, and always returns 'Results'. I'd welcome good ideas on how best to document the new 'minimize' interface, and how best to coordinate that with the "old style" method documentation. I'm not looking for ideas that are merely the programmer's personal reminders--the current documentation is just fine for that! Instead, I'm looking for documentation suitable for use by folks who might be described as: first year grad students just slightly familiar with Python who have a one week deadline to solve their problem and desperately need _very_ clear, unambiguous, and detailed instructions on exactly how to proceed. Try to remember _your_ first year grad experiences!!

2 1

(no subject)
by Robaula Sept. 26, 2012

Sept. 26, 2012

Bob & Paula H

1 0

Flaws in the cobyla routine
by Robaula Sept. 26, 2012

Sept. 26, 2012

I consider the following to be flaws (not bugs) in the cobyla, or "constrained optimization by (successive) linear approximation" routine. 1. The routine returns only the optimal argument value. No description of the status at the end of the run, such as would be provided by the "Results" class are included. Consequently the user receives no information on the trustworthiness of the returned value. 2. Although "disp" and "iprint" are among the options in cobyla's calling signature, assigning different values to them has absolutely no effect on the output. 3. The docstring's Examples section mentions several values that would be included in the "Results", but with no indication of where they come from or how the users could get at them. 4. The cobyla routine calls the _minimize_cobyla routine, which prepares and returns the "Results" class information. This includes: the optimal value of the argument, the status at end, the success flag value, a message expressing the success flag in English, the optimal value of the function, and the maximum constraint violation. Then the cobyla routine "throws away" all but the first of these values. That occurs because after the cobyla routine receives the "Results" dictionary of values from _minimize_cobyla, it returns, in effect, "Results['x']", i.e., just the "Results" dictionary entry for key 'x'. This is done in line 165 of the cobyla routine. Recommend revision to correct these flaws. While doing that, consider the following remarks. In addition to reporting the maximum constraint violation, it would be helpful to also report which constraint(s) caused the maximum constraint violation. It would also be useful to report which constraints were "tight" and which were "loose." Bob & Paula H

3 2

hyp1f1(0.5, 1.5, -2000) fails
by Ondrej Certik Sept. 24, 2012

Sept. 24, 2012

Hi, I noticed, that hyp1f1(0.5, 1.5, -2000) fails: In [5]: scipy.special.hyp1f1(0.5, 1.5, 0) Out[5]: 1.0 In [6]: scipy.special.hyp1f1(0.5, 1.5, -20) Out[6]: 0.19816636482997368 In [7]: scipy.special.hyp1f1(0.5, 1.5, -200) Out[7]: 0.062665706865775023 In [8]: scipy.special.hyp1f1(0.5, 1.5, -2000) Warning: invalid value encountered in hyp1f1 Out[8]: nan The values [5], [6] and [7] are correct. The value [8] should be: 0.019816636488030055... Ondrej

4 3

Re: [SciPy-User] Pylab - standard packages
by Joe Harrington Sept. 24, 2012

Sept. 24, 2012

At first the idea of a "Pylab" standard appealed to me (it still does, but with caveats, which see below). Like everyone, my lab has a standard Python stack on all our machines, and it's a pretty long list. It would be nice to cut it in half, and let someone else worry about the integration issues. So I tried to make my list of what to include that wasn't specific to my discipline. ...And I discovered that this idea is a wickedly slippery slope. While I have my own reasons for choosing certain packages over others, the community has organized to encourage lots of topical subpackages, from broad-use packages like matplotlib to specialist things like astropy. Even within an area, such as plotting, there are options, and competition is critical to get great packages. BUT if your package is in PylabTM and your competition isn't, you have a *big* advantage. You'll get installed by every Linux distro, and the computational Python distros will want to be in compliance as well, so you'll show up there. Regardless of intent, if the community makes this a standard and a distro does not follow it, it will look strange: tutorials written to the Pylab standard will not work with that distro, commonly shared code will not run in it without add-ons, etc. So, distro maintainers will want to be in compliance if they can be. By choosing among packages, Pylab will stifle competition, regardless of our pure intent. I still want there to be a Pylab, for selfish reasons cited above. I can see a couple ways out, gotten to by asking, WHOSE NEEDS ARE WE TRYING TO SERVE? 1. Make the set only include packages for which there is essentially no competition. numpy+scipy+ipython+binary file formats? I think there is consensus that Matplotlib is standard, but are we really ready to formalize the "next-best" status of all other plotting packages? I think we actually might be, but I don't think that's true for any other package with serious competiton. So numpy+matplotlib+scipy+ipython+binary file formats. I am edgy about ipython, but let's face it, almost everyone uses it. The fact that it contains some new material for which the competition hasn't been decided (i.e., notebook and related features) is a complicating factor. We will want to jam other packages in here, like cython and sympy. If we're preserving competition, it will have serious holes. It will be unwieldy for beginners (too big) and will require lots of add-ons for experienced people and production use. DOES IT SERVE ANYONE? I don't think anyone will like it. 2. Include *everything*, and don't make choices among competing packages. DOES IT SERVE ANYONE? Maybe big labs with lots of disk space. 3. Define several levels of Pylab: Level 1: Stuff needed for beginner tutorials, Numerics 101 classes, etc. I think just numpy+matplotlib+scipy+ipython+binary file formats. Declare that beginner tutorials stick to this set to be Pylab-approved tutorials and get a link from the Pylab-level-1 page. The tutorials would also have to comply with coding standards like "import numpy as np", etc. We may also declare that compliant tutorials will not use certain features of Ipython. I see things like common scientific binary file formats as very important, as anyone switching from another language will have data. DOES IT SERVE ANYONE? Yes, beginners (and their teachers). Level 2: The above plus things like cython, symbolic math, serious financial functions, unit conversions, serious stats, C, C++, FORTRAN, etc., but not selecting any package where there is still competition. Yes, this will leave holes, but people operating at this level are capable of making choices, and distros are welcome to fill in. DOES IT SERVE ANYONE? It's a good, smallish base for technical users to build upon. Level 3: The above plus ALL stable, general-purpose packages that meet a certain standard, including different competitive variants for the same task. DOES IT SERVE ANYONE? Big installations with one specialty. Level 4: The above plus specialist packages like astropy. DOES IT SERVE ANYONE? Big installations with many specialties. I like option 3. In all my thinking on this problem, I could not find a minimal set that was useful to advanced users and didn't stifle competition. So, instead we have a minimal set that isn't geared toward advanced users, and that encourages consistency across tutorials. Then we have levels of increasing inclusiveness, size, and utility to advanced users, none of which stifles competition. Most importantly, the "in" list for any level certifies that all included packages are stable, actively maintained, well documented, and do not fight with the rest of the packages. I think that requiring functionality rather than specific packages is not very useful. What utility is there in saying you have an IDE, a syntax-highlighting editor, etc. without specifying which one? I can see saying "a C compiler", though. Perhaps saying "one or more of ..." and listing specific IDEs/editors/etc. would be ok. That at least provides the service of certifying that those listed actually work well with the stack. Finally, I think that there should be installers. Certifying the work of others is nice, but the real benefit will be in actually having something to install. But if there are two entities, one that certifies and one that makes an installer for each defined Pylab level, I'm fine with that. I'd just hate to see a defined Pylab level for which no pure installer (i.e., no installer for just those packages) is available. Thanks, and sorry for the length. --jh-- Prof. Joseph Harrington Planetary Sciences Group Department of Physics PS 441 4000 Central Florida Blvd. University of Central Florida Orlando, FL 32816-2385 USA ... On sabbatical at: ... Max-Planck-Institut für Astronomie Königstuhl 17 D-69117 Heidelberg Germany jh(a)physics.ucf.edu planets.ucf.edu

13 79

Re: [SciPy-User] SciPy-User Digest, Vol 109, Issue 58
by Robaula Sept. 24, 2012

Sept. 24, 2012

As a Windows-only user, and interested mainly in quickly getting my application running and generating results, I want something that installs everything I need and lets me get on with it. And I don't want to learn or use Linux along the way. I'll be seriously discouraged if to start getting results after installing SciPy orPyLab, I next have to install A. But to install A, I first have to install B. Then I next have to install C, and then D, etc. I also get seriously irritated when after all that I discover that to use SciPy or PyLab functions FFF and GGG, I have to make sure I've first imported modules MM1 and MM2 -- and many times scratch around until I find what modules contain FFF and the other function(s) I need. Why should _I_ do that? Why doesn't SciPy or PyLab know where it's functions are and just automatically import the right module(s)? Seems like all it would take is to add a line to each function importing the appropriate module(s). Sent from Robaula's iPad helmrp(a)yahoo.com 2645 E Southern, A241 Tempe, AZ 85282 VOX: 480-831-3611 CELL: 602-568-6948 (but not often turned on) On Sep 24, 2012, at 5:11 AM, scipy-user-request(a)scipy.org wrote: > Send SciPy-User mailing list submissions to > scipy-user(a)scipy.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.scipy.org/mailman/listinfo/scipy-user > or, via email, send a message with subject or body 'help' to > scipy-user-request(a)scipy.org > > You can reach the person managing the list at > scipy-user-owner(a)scipy.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SciPy-User digest..." > > > Today's Topics: > > 1. Re: Pylab - standard packages (Almar Klein) > 2. Re: Pylab - standard packages (Francesc Alted) > 3. Re: Pylab - standard packages (Thomas Kluyver) > 4. Re: Pylab - standard packages (Almar Klein) > 5. Re: hyp1f1(0.5, 1.5, -2000) fails (Moore, Eric (NIH/NIDDK) [F]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 24 Sep 2012 10:17:41 +0200 > From: Almar Klein <a.klein(a)science-applied.nl> > Subject: Re: [SciPy-User] Pylab - standard packages > To: SciPy Users List <scipy-user(a)scipy.org> > Message-ID: > <CAB_T6=mwrt0ac1SmXYXmm5Q1oku=WAJBK+_mbvND5u+2TVcPfQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > >> >> We discussed it recently with Carlos Cordoba (a Spyder dev), but I'm >> not sure what the issue is, nor whether IPython, Spyder or both need >> to fix things. I've just opened an (IPython) issue to work this out: >> https://github.com/ipython/ipython/issues/2425 > > > I realize my previous comment on this was rather vague. What I was trying > to say is that I do not think specifying the latest IPython version in > pylab will cause serious problems for Python(x,y). It should easily be able > to include the IPython executable in the way that other people use it, i.e. > independent from its IDE (Spyder). > > The integration of the newer IPython (or a notebook interface) in Spyder is > much more difficult. It would be great if in time this would be available > too, but I don't think it's a prerequisite for Python(x,y) to be > pylab compliant. > > But as you pointed out, it would be nice to hear what Pierre et al think > about this. > > > Almar: thanks for the mention of imageio. By the sounds of it, that >> makes two votes (yours and Ralf's) in favour of FreeImage over PIL? > > > Well, FreeImage is only a C++ library. sk-image uses it as one of its ways > to load images. So my take on this would be to let sk-image do the image > loading for now, and include imagio in the standard if it is more mature. > sk-image can then use imageio as a plugin. > > (note that there are one or two other wrappers around the imageio library, > but Zach started fresh because their codebases weren't very nice.) > > It would be great if we can avoid including PIL in the standard, but I > think that many people depend on it. So others might argue differently ... > > Almar >

4 3

回复： [Numpy-discussion] errors of scipy build
by 心如烛光 Sept. 24, 2012

Sept. 24, 2012

Hi,David. thanks for your help. But I don't think that the build for numpy and scipy are successful.Course the test of numpy and scipy are fail. Here's the situation: >>> import numpy as np >>> np.test('full') Running unit tests for numpy Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 340, in test self._show_system_info() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 193, in _show_system_info nose = import_nose() File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/testing/nosetester.py", line 71, in import_nose raise ImportError(msg) ImportError: Need nose >= 0.10.0 for tests - see http://somethingaboutorange.com/mrl/projects/nose ------------------ 原始邮件 ------------------ 发件人: "David Cournapeau"<cournape(a)gmail.com>; 发送时间: 2012年9月24日(星期一) 凌晨1:11 收件人: "Discussion of Numerical Python"<numpy-discussion(a)scipy.org>; 抄送: "scipy-user"<scipy-user(a)scipy.org>; "paparazzi-devel"<paparazzi-devel(a)nongnu.org>; 主题: Re: [SciPy-User] [Numpy-discussion] errors of scipy build On Sun, Sep 23, 2012 at 5:23 PM, 心如烛光 <275438859(a)qq.com> wrote: > Hi,all. > I have installed numpy and scipy step by step carefully as the > instructions from website:http://www.scipy.org/Installing_SciPy/Mac_OS_X > But still get many errors and warnings while it's building. > (OSX lion 10.7.4 /Xcode 4.5 /clang /gfortran4.2.3) Those error are parts of the configuration. As long as the build runs until the end, the build is successful. You should not build scipy with gcc on mac os x 10.7, as it is known to cause issues. David _______________________________________________ SciPy-User mailing list SciPy-User(a)scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user

2 1

errors of scipy build
by 心如烛光 Sept. 23, 2012

Sept. 23, 2012

Hi,all. I have installed numpy and scipy step by step carefully as the instructions from website:http://www.scipy.org/Installing_SciPy/Mac_OS_X But still get many errors and warnings while it's building. (OSX lion 10.7.4 /Xcode 4.5 /clang /gfortran4.2.3) Do scipy and numpy must be built by gcc?? Such as: 1 error generated. _configtest.c:5:28: error: 'test_array' declared as an array with a negative size static int test_array [1 - 2 * !(((long) (sizeof (npy_check_sizeof_type))) == 4)]; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. C compiler: clang -fno-strict-aliasing -fno-common -dynamic -pipe -O2 -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes /////////////////////////////////////////////////////////// Constructing wrapper function "drotm"... getarrdims:warning: assumed shape array, using 0 instead of '*' getarrdims:warning: assumed shape array, using 0 instead of '*' x,y = drotm(x,y,param,[n,offx,incx,offy,incy,overwrite_x,overwrite_y])

2 1

Pylab - standard packages
by Thomas Kluyver Sept. 22, 2012

Sept. 22, 2012

Hi again, It now looks like we're going to use Pylab as the name for the 'scipy stack'. Now I want to turn to the question of what it should include. The idea is that Python distributions can call themselves Pylab compliant if they provide at least a defined set of packages. Also, I hope that it will become a metapackage in Linux distributions, so that users can 'apt-get install pylab' or similar As a minimum, I assume we should require Python, Numpy, Scipy and Matplotlib. Does anyone disagree? I also think we should specify minimum versions. The standard itself will be versioned, so we can raise these over time. For Python, I intend the requirement to be 2.x >= 2.6 or 3.x >= 3.2. What are sensible minimum versions of Numpy, Scipy and Matplotlib? Should the standard include an interface? IPython, a more traditional IDE, or both? On the one hand, specifying a standard interface means users can share experience better, and exchange richer files, like IPython notebooks or IDE project structures. Matlab, for instance, wins praise for including a powerful IDE by default. On the other hand, we've got several interesting UI efforts still taking shape - IPython notebooks, Spyder, IEP - and declaring one standard would make the alternatives less visible. I'm honestly torn on this - I can see good arguments for and against. Other scientific packages we might consider include pandas (which provides functionality similar to core parts of R), Sympy, Cython, various scikits projects, h5py, and doubtless many others I haven't thought of. We could also specify general purpose Python packages such as requests, or a GUI toolkit. On the NumFOCUS list, Chris Kees raised the idea that there could be two or more levels of packages, e.g. 'core' and 'recommended'. I don't think we should add that kind of complexity in the first version, but keep in mind that we could differentiate it later. Finally, I mean the standard to specify that the distribution must offer a way of installing arbitrary extra Python packages into it, so the standard shouldn't try to include everything you might need for scientific computing. The aim is to offer a key set of tools so you can get started without having to add things. "Get started with what?" is the key question we have to answer. In my field, for example, statistical tests are fundamental, while symbolic maths is hardly used. All your opinions are welcome, Thomas

15 53