Mailman 3 April 2007 - SciPy-Dev

Question about Kaiser Implementation in firwin
by Buehler, Eric (AGRE) 04 Oct '08

04 Oct '08

Hello, I have been using the signal.firwin FIR design tool and I have a question about the implementation. Scipy-0.4.8 Numpy-0.9.6 I am generating a kaiser window with the following parameters: N = 128 Cutoff = ~4e7 width = .3 All of the special kaiser generation parameters in the function follow Oppenheim and Schafer well. Even the sinc function for linear phase is follows exactly. However, the last line of the firwin function is causing me some heartburn. filter_design.py 1538 win = get_window(window,N,fftbins=1) 1539 alpha = N//2 1540 m = numpy.arange(0,N) 1541 h = win*special.sinc(cutoff*(m-alpha)) 1542 return h / sum(h) Line 1542 of filter_design.py, "return h / sum(h)", normalizes the function where it doesn't seem necessary, at least in the kaiser window case. Without the normalization, the kaiser window already returns a value of 1 at the zero frequency point. This normalization scales all of the data, making the window difficult to use in the frequency domain. Can someone point me to the rationale for this line? Looking at the code, this seems to be a pretty recent change (within the last year/year and a half). Thanks, Eric Buehler eric <dot> buehler <at> smiths-aerospace <dot> com ****************************************** The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email. ******************************************

3 2

ZVODE, a Double Precision Complex ODE Solver
by Nils Wagner 20 Feb '08

20 Feb '08

This might be of interest. Nils From: Alan Hindmarsh <alanh(a)llnl.gov> Date: Wed, 6 Dec 2006 18:20:32 -0500 Subject: ZVODE, a Double Precision Complex ODE Solver Of the many solvers freely available for ODE initial value problems, there seem to be very few, if any, for the case of double precision complex dependent variables, even though there have been occasional user calls for this functionality. (Of course a complex system can be treated as a real system of twice the size, but direct treatment as a complex system is preferable.) I have provided such a solver: ZVODE. ZVODE is a straightforward modification of the Fortran ODE solver DVODE, for double precision real systems, making it part of a trio, SVODE/DVODE/ZVODE. ZVODE is available in two locations: (1) Netlib, in /ode (see file zvode.f), and (2) the LLNL CASC software site, www.llnl.gov/CASC/software.html (see VODE). The latter site also includes a demonstration program, zvdemo. Alan Hindmarsh Center for Applied Scientific Computing Lawrence Livermore National Laboratory

4 5

scikits developement conventions ?
by David Cournapeau 23 May '07

23 May '07

Hi, Now that scikits is finally in place, I would like to know what the "conventions" are for development. The only webpage I found for info is the following: https://projects.scipy.org/scipy/scikits/. Is that right ? My questions are: - who has write access to the repository ? - how does one create a new project (people with write access can create a project ?) cheers, David

8 38

Re: [SciPy-dev] Callback feature for iterative solvers
by Nils Wagner 04 May '07

04 May '07

Ed Schofield wrote: > > On 1/24/07, *Nils Wagner* <nwagner(a)iam.uni-stuttgart.de > <mailto:nwagner@iam.uni-stuttgart.de>> wrote: > > Hi Ed, > > Great ! > Thank you very much ! > It seems to work well with the exception of GMRES. > Please find attached a short test. > Am I missing something ? > > > No, I agree. It seems that there's something wrong with GMRES -- the > iter_ return parameter from gmresrevcom() is never incremented for > this example. I'm not familiar with the algorithm -- perhaps it really > does converge in one iteration? If not, it's just a bug. Could you > file a bug against gmres() in Tracker? > > -- Ed > Hi Ed, Done. Maybe you can add some comments. Again thank you very much for the new functionality !! http://projects.scipy.org/scipy/scipy/ticket/360 Cheers, Nils

4 3

Cleaning and fixing fft in scipy ?
by David Cournapeau 02 May '07

02 May '07

Hi, When fixing the fft problem with prime number in numpy, I came again across the fft implementation in scipy, and related problems (suboptimal solution for fftw, see eg scipy ticket #1). I would like to improve the situation: - First, I think the module needs serious cleaning, as for now, it is a bunch of C files with many #define all accross the code, making it difficult to track things. I propose to split the sources by implementation (fft_fftw3.c, fft_fft2, fft_mkl, etc...); this can be done without any consequence on the implementation. - Then, improving fft where it is needed. Does this sound ok with scipy developers ? I should come up with a patch for zfft within today; even if I try to keep changes minimal, I would need people willing to test (I can easily test on linux with fftw2 and 3, and if necessary with mkl on the same platform. I would prefer avoiding testing on windows myself, as I have only a Japanese windows, making things extremely painful for me on this already painful platform). cheers, David

6 13

Re: [SciPy-dev] mlabwrap high-level user interface
by Alexander Schmolck 30 Apr '07

30 Apr '07

[moving this to scipy-dev] "Brian Hawthorne" <brian.lee.hawthorne(a)gmail.com> writes: > Ah, forgot one critical use case, the function call! > >>>> res = engine.svd(X, nout=1) >>>> res = engine["svd"](X, nout=1) As I mentioned in the other poist, I don't like that. There ought to be one way to do things, and the first type of call is clearly what we'd like function calls to typically look like. I suspect that ``engine["svd"]`` ought to be equivalent to ``engine.svd()``. The reason why I'd at least strongly consider this funny looking behavior that is that nullary-function call vs. variable lookup is below the interface level in matlab (i.e. syntactically undistinguishable and hence something that one is often at liberty to change for a variable that isn't intended for mutation; a bit like property access can be transparently replaced by a function call in python (using e.g __getattr__) but not in lesser languages like java or C++). > This would fall under the exact same code as the raw get below (here > returning a function proxy). Oh, and one more suggestion, if we're going to > treat the engine as a dict (which it is), it might also be nice to have a > keys method to return all the names in the matlab namespace: > >>>> mlab_vars = engine.keys() # or "vars" or "names", whatever I'm against conflating matlab and MLabWrap-instance method namespaces, especially since I don't see a very compelling use-case for a ``.keys`` method. > Though i guess if matlab already has a command for that, you could just use > that ;) Indeed and if there isn't you might have a hard time implementing it anyway ;) > One nice thing about this design is that the engine object has no > statically defined public methods, so you don't have to worry so much about > a method name conflicting with a matlab name. Yes, I think we really want to avoid that. > I think it's fine to define a private RawEngine class under the hood which > implements open, close, get, set, and eval. Then the main user-facing engine > will just have a reference to it and delegate to it. Hmm, sorry I'm not 100% sure what you're proposing here -- would RawEngine essentially be like mlabraw, but ctypes based with a class interface? If so, yes that would indeed be the approach I'd advocate for the ctypes mlabraw replacement (the only reason that the C++ code doesn't work like this is that in the case of mlabraw.cpp the effort involved would IMO not have justified the reward). IIRC, David's ctypes code already looks like this. alex

1 0

Re: [SciPy-dev] mlabwrap high-level user interface
by Alexander Schmolck 30 Apr '07

30 Apr '07

[Moving this to scipy-dev] "Brian Hawthorne" <brian.lee.hawthorne(a)gmail.com> writes: > Hello, > I'm hoping to get feedback from you all on some suggestions for what a > cleaner mlabwrap API might look like. > >>>> from scikits.mlab import engine # engine is an instance of MlabEngine > (or simply Engine) This is simply about renaming scikits.mlabwrap to scikits.mlab, MlabWrap to MlabEngine and mlab to engine, right? I agree that mlabwrap is not necessarily the most elegant name (pymat is better, but was already taken), but I'm not sure I'd prefer engine to mlab -- it's more generic and more to type; it's also slightly the wrong emphasis for my taste (I don't want people to focus on the fact that they're doing something that involves using the matlab engine; the abstraction level offered by mlabwrap is above that of matlab's engine protocol). Anyway, my suggestion is that we first deal with the meat (sorting out hybrid proxying, scikits and testing infrastructure etc.) and worry about cosmetic issues like renamings afterwards -- I don't think naming issues are unimportant but they can be dealt with once the functionality we want is there; conversely changes in the core design can render cosmetic decisions obsolete. >>>> engine.X = [[1,2,3],[4,5,6],[7,8,9]] # raw put, implement __setattr__ >>>> engine["X"] = [[1,2,3],[4,5,6],[7,8,9]] # raw put, implement __setitem__ >>>> X = engine.X # raw get, implement __getattr__ >>>> X = engine["X"] # raw get, implement __getitem__ Do I understand you correctly that you want 1&2 and 3&4 to be equivalent (javscript-style)? If so I'm against it -- in python there's ideally one and only one obvious way. I propose using ``.X`` for function calls and ``.["X"]`` for variable access (yup, there *is* a reason why I think one wants to seperate these, see my reply to your other post). >>>> Y = engine("matlab code") # raw eval, implement __call__ Using ``engine["x"]`` viz. ``mlab["x"]`` for variable access and ``mlab("do something")`` for raw evaluation looks pretty attractive to me. The only reason I can see why one might want to reserve ``__call__`` is that it could also mkae for a convenient customization syntax, e.g:: mlab(flatten_row_vecs=True).sin([1,2,3]) which might be more important than having a shorter way to spell ``mlab._do("do something")``. With python2.5 one could also use the with syntax for that, but the syntax above could still be slightly more convenient for single calls with non-default options. >>>> a = engine.some_matlab_object_with_nested_attributes # return an > ObjectProxy >>>> a.b.c # in matlab, call (a.subsref("b")).subsref("c") >>>> a["b.c"] # bypas "normal" indexing to call a.subsref("b.c") > > Regarding packaging, the code currently in _mlabwrap.py could move into the > __init__.py file (since it's imported into there anyway), then we could > delete > _mlabwrap.py. _mlabwrap.py is there for a purpose, albeit a fairly egotistical one: it makes switching buffers in emacs easier (i.e. generic names like __init__.py are inconvenient if you got a UI that lets you switch to the desired buffer (viz opened file for non-emacs users) by entering some unique substring). I'd be happy to get rid of _mlabwrap.py if there are any downsides associated with having it, but I'm currently not aware of any. > Also, the ctypes version Taylor is working on won't require any non-python > extension code (I believe), so mlabrawmodule.so will disappear too, Yup. > and the package directory will be left with nothing but awmsmeta.py and > awmstools.py. Taylor also mentioned that the ctypes version currently relies > on some small C utilities, but that they can probably be done away with > (please correct me if I'm wrong here). No, I'd indeed like to get rid of all C(++) code. > I also suggest moving the tests dir under the scikits.mlab package so it can > be found by numpytest. IIRC the current directory structure (and the position of ``tests/``) corresponds to what Robert Kern suggested -- I'm not really familiar with numpytest yet, but I suppose if it expects tests to be in the location you say that's presumably an oversight. I'm about to write a scikits related email to the list anyway, so I'll ask in there. > As far as changing mlabwrap to mlab, it's not super important, but it would > be a bit easier to type, and I think in general python wrappers don't > use the word "wrap" in their names. I don't think the typing argument matters much, since unlike e.g. ``os`` ``mlabwrap`` is not meant to be to be used as a qualifying prefix -- the standard idiom is ``from mlabwrap import mlab``, so mlabwrap only needs to get type once per file/session. > If we did that, it would also make sense for the project itself to be called > mlab (the fewer names the better). It's common in python, but IMO stuff like ``StringIO.StringIO`` is piss-poor design in a language where both the use of unqualified names and qualified names is common (and importing module handles later on is often required for reloading and other interactive shell use). I've been frequently annoyed and even once or twice been bitten by this so I'd really rather not have ``mlab.mlab`` even if it would mean fewer names. OTOH now we've got the additional leading ``scikits.`` anyway, the respective ``mlab``s are presumably sufficiently disambiguated... so I guess I'm open to this renaming, but I suggest we deal with other things first, as mentioned above. cheers, alex

1 0

Re: [SciPy-dev] mlabwrap high-level user interface
by Alexander Schmolck 30 Apr '07

30 Apr '07

"Matthew Brett" <matthew.brett(a)gmail.com> writes: > Hi guys, > > I like the interface. We might have to think of a different module > name though, because matplotlib has a 'mlab' submodule of the same > name, for matlab compatibility functions, I don't think we need to worry too much about this -- IMO using a plotting package like matplotlib to obtain matlab-like functions (rather than numpy, scipy or whatever) is pretty yucky anyway and people can easily use either an ``import as`` or a a fully qualified name (``matplotlib.mlab`` or ``mlabwrap.mlab``). alex

2 2

Re: [SciPy-dev] mlab namespace thought
by Alexander Schmolck 30 Apr '07

30 Apr '07

Hi Matthew, [I think this is likely to be of interest to other mlabwrap developers as well, so I hope it's OK if I move this to scipy-dev, and re-arrange to bottom-posting style. Sorry it took me some time to get back on this -- I've taken longer than expected to readjust to my European day-cycle] >> "Matthew Brett" <matthew.brett(a)gmail.com> writes: >> > Hi, >> > >> > I was just thinking about the problem of the kludginess of >> > >> >>>> from mlabwrap import mlab >> >>>> import mlabraw >> >>>> A, B, C = mlab.svd([[1,2],[1,3]], 0, nout=3) >> >>>> pymat.put(mlab._session, "X", [[1,2], [1,3]]) >> > >> > It seems to me the problem is the fact that the mlab namespace has to >> > be kept free of anything that could be a matlab function. >> > >> > So how about: >> > >> > import mlab >> > from mlab import exec as mle >> > >> > A, B, C = mle.svd([[1,2],[1,3]], 0, nout=3) >> > mlab.put(X, [[1,2], [1,3]]) > On 4/23/07, Alexander Schmolck <a.schmolck(a)gmx.net> wrote: >> >> Hi Matthew, >> >> why not just use >> >> mlab._set('X', [[1,2], [1,3]]) >> >> :) >> >> alex >> > >> > Best, "Matthew Brett" <matthew.brett(a)gmail.com> writes: > Yer - sorry - I forgot that your're right. :) > > But, in general, you've got the problem that any new method of > attribute in the mlab module has to be preprended with an underscore, > which is a bit awkward - as you know, the underscore is in general a > semi-formal clue to the programmer that the feature is private and > should not be used outside the module itself. I speak only for myself, > but I have the instinct to think hard before I use an underscore > function or attribute. And it makes it difficult for you to indicate > which functions etc are really private and which are not. Agreed -- there's still double-underscore, but that has name-mangling implications; OTOH > I realize this would mean an API change in mlabwrap... I can definitely see where you're coming from -- It is true that underscore method names carry a strong connotation with "messing with internals", but there are two considerations why I prefer the current scheme to having several objects: 1. There's a good technical reason why there's a single ``mlab`` that mediates access to a matlab session, rather than several handles for different purposes (``mle`` etc.): mlabwrap supports multiple matlab sessions and each such session is encapsulated in a MlabWrap class instance -- ``mlab`` is just the 'default' session that gets created as one imports mlabwrap. If one uses different objects to interface to a single session, synchronization issues can arise (e.g. one's ``mle`` might in fact accidentally refer to a different session than one's ``mlab``). 2. Finally, getting and setting variables, *is*, to my mind "messing with internals" -- the interface metaphor of mlabwrap is that matlab is a python library -- you call functions in the mlab "module" just like in any other module and the things you pass in and get out are python objects (possibly proxying matlab objects). Setting named variables in matlab-space is lower-level than that The main use case I see for it is querying and setting global variables that control the behavior of a matlab package (or matlab itself). Whilst I'd be happy to give greater prominence to ``mlab._set`` and ``mlab._get`` in the documentation (and I think de-emphasizing mlabraw might also be a good idea) or reserve the dictionary access notation for this use as Brian suggested, my feeling is that it is not that often needed. If you have some other, non-marginal use case it would really be good if you could send me some examples. I think that it'd be feasible to think up a more "natural" way to handle such variable setting (e.g. one could possibly make ``mlab.some_global_var = 3`` work; but there are some difficulties associated with doing that; e.g. the syntactic equivalence between nullary function call and variable access in matlab; see my other post or scipy.org/MlabWrap) if there is a demonstrated need. More on this in my replies to Brian. cheers, alex

1 0

patch implementing broyden schemes in SciPy
by Ondrej Certik 30 Apr '07

30 Apr '07

Hi, I submitted a patch for Broyden schemes together with tests: http://projects.scipy.org/scipy/scipy/ticket/402 My email describing it (together with a question) is here: http://projects.scipy.org/pipermail/scipy-dev/2007-April/006979.html I won't have time for it this week and also the patch is for the svn version from a week ago, but if some of you would like to look at that, just let me know and I'll update it to the top svn. I will be glad to help the code meet SciPy's standards - just let me know if I should change anything. Thanks very much, Ondrej Certik

1 0