From david.strozzi at gmail.com Sat Nov 1 10:56:11 2014 From: david.strozzi at gmail.com (David Strozzi) Date: Sat, 1 Nov 2014 07:56:11 -0700 Subject: [SciPy-Dev] definition in scipy.signal.hilbert Message-ID: Hi, It would be nice to add an exact formula for the Hilbert transform in the document comment for scipy.signal.hilbert. In particular, different authors use a different overall sign convention. Not a big deal but having a formula would save some time. Thanks, Dave From evgeny.burovskiy at gmail.com Sun Nov 2 07:25:57 2014 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Sun, 2 Nov 2014 12:25:57 +0000 Subject: [SciPy-Dev] definition in scipy.signal.hilbert In-Reply-To: References: Message-ID: Pull requests with improvements to the docs are most welcome. Cheers, Evgeni 01.11.2014 14:56 ???????????? "David Strozzi" ???????: > Hi, > > It would be nice to add an exact formula for the Hilbert transform in > the document comment for scipy.signal.hilbert. In particular, > different authors use a different overall sign convention. Not a big > deal but having a formula would save some time. > > Thanks, > Dave > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtaylor.debian at googlemail.com Sun Nov 2 08:33:50 2014 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Sun, 02 Nov 2014 14:33:50 +0100 Subject: [SciPy-Dev] ANN: NumPy 1.9.1 bugfix release Message-ID: <545632BE.5080100@googlemail.com> Hello, We am pleased to announce the release of NumPy 1.9.1, a bugfix only release for the 1.9.x series. https://sourceforge.net/projects/numpy/files/NumPy/1.9.1/ The upgrade is recommended for all users of the 1.9.x series. Following issues have been fixed: * gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9. The second order behaviour is available via the `edge_order` keyword * gh-4007: workaround Accelerate sgemv crash on OSX 10.9 * gh-5100: restore object dtype inference from iterable objects without `len()` * gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash * gh-5138: fix nanmedian on arrays containing inf * gh-5240: fix not returning out array from ufuncs with subok=False set * gh-5203: copy inherited masks in MaskedArray.__array_finalize__ * gh-2317: genfromtxt did not handle filling_values=0 correctly * gh-5067: restore api of npy_PyFile_DupClose in python2 * gh-5063: cannot convert invalid sequence index to tuple * gh-5082: Segmentation fault with argmin() on unicode arrays * gh-5095: don't propagate subtypes from np.where * gh-5104: np.inner segfaults with SciPy's sparse matrices * gh-5251: Issue with fromarrays not using correct format for unicode arrays * gh-5136: Import dummy_threading if importing threading fails * gh-5148: Make numpy import when run with Python flag '-OO' * gh-5147: Einsum double contraction in particular order causes ValueError * gh-479: Make f2py work with intent(in out) * gh-5170: Make python2 .npy files readable in python3 * gh-5027: Use 'll' as the default length specifier for long long * gh-4896: fix build error with MSVC 2013 caused by C99 complex support * gh-4465: Make PyArray_PutTo respect writeable flag * gh-5225: fix crash when using arange on datetime without dtype set * gh-5231: fix build in c99 mode The source distributions have been uploaded to PyPI. The Windows installers, documentation and release notes can be found at: https://sourceforge.net/projects/numpy/files/NumPy/1.9.1/ Cheers, Julian Taylor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From matthew.brett at gmail.com Mon Nov 3 13:31:56 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 3 Nov 2014 10:31:56 -0800 Subject: [SciPy-Dev] ndimage reflect mode In-Reply-To: References: Message-ID: On Fri, Oct 31, 2014 at 12:16 AM, Matthew Brett wrote: > Hi, > > Sorry if this is a dumb question, but I just noticed some behavior of > scipy.ndimage that surprised me: > > In [63]: oned = np.arange(1, 10, dtype=float) > In [64]: scipy.ndimage.affine_transform(oned, [1], [-2], mode='reflect') > Out[64]: array([ 2., 1., 1., 2., 3., 4., 5., 6., 7.]) > > OK so far. But this I was surprised by: > > In [68]: scipy.ndimage.affine_transform(oned, [1], [-2 - 1e-15], mode='reflect') > Out[68]: array([ 2., 1., 2., 2., 3., 4., 5., 6., 7.]) > > Why did the third value turn from a 1 into a 2? I am missing something obvious? I assume for lack of answers that this is a bug? Any objections to opening this as an issue? Matthew From warren.weckesser at gmail.com Mon Nov 3 13:36:39 2014 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 3 Nov 2014 13:36:39 -0500 Subject: [SciPy-Dev] ndimage reflect mode In-Reply-To: References: Message-ID: On Mon, Nov 3, 2014 at 1:31 PM, Matthew Brett wrote: > On Fri, Oct 31, 2014 at 12:16 AM, Matthew Brett > wrote: > > Hi, > > > > Sorry if this is a dumb question, but I just noticed some behavior of > > scipy.ndimage that surprised me: > > > > In [63]: oned = np.arange(1, 10, dtype=float) > > In [64]: scipy.ndimage.affine_transform(oned, [1], [-2], mode='reflect') > > Out[64]: array([ 2., 1., 1., 2., 3., 4., 5., 6., 7.]) > > > > OK so far. But this I was surprised by: > > > > In [68]: scipy.ndimage.affine_transform(oned, [1], [-2 - 1e-15], > mode='reflect') > > Out[68]: array([ 2., 1., 2., 2., 3., 4., 5., 6., 7.]) > > > > Why did the third value turn from a 1 into a 2? I am missing something > obvious? > > I assume for lack of answers that this is a bug? > > Any objections to opening this as an issue? > > No, please do. Warren > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Tue Nov 4 01:54:29 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 4 Nov 2014 07:54:29 +0100 Subject: [SciPy-Dev] 0.14.1 and 0.15.0 release schedule In-Reply-To: References: <543EFF87.2030101@googlemail.com> <5448287B.1020801@googlemail.com> Message-ID: On Mon, Oct 27, 2014 at 5:47 PM, Matthew Brett wrote: > Hi, > > On Mon, Oct 27, 2014 at 3:55 AM, Pauli Virtanen wrote: > > Julian Taylor googlemail.com> writes: > >> ping, I'd need to know soon what the 014.x plans are, just whether there > >> will be another 0.14 release or not, I don't need any specific dates. > > > > A 0.14.1 release is still planned, but as can be seen, the release > > dates have slipped. > > > > The 0.14.x branch currently contains some bugfixes that a Debian > > package may want to have. IIRC the only remaining thing we need to > > do for the release is to check whether there are other high-priority > > fixes that would need to be backported. > > > > Sturla's SGEMV fix is probably suitable for 0.14.1, it seems pretty > > straightforward. > > I would like to get some scipy.io.matlab fixes in for 0.14.1 - I will > try and get these done by Wednesday; will that fit with the release > schedule? > Hi all, Due to personal reasons I have had to step away from all Scipy and other open source activities for a while. My apologies for the silence. I hope to be back soon. Pauli has volunteered to finish the next release - thanks a lot for that Pauli. Best, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From prabhu at aero.iitb.ac.in Wed Nov 5 10:32:11 2014 From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran) Date: Wed, 05 Nov 2014 21:02:11 +0530 Subject: [SciPy-Dev] [ANN] CFP: SciPy India 2014: Dec 5 - 7, IIT Bombay Message-ID: <545A42FB.9070307@aero.iitb.ac.in> Hello, [Apologies for the cross-posting] The CFP and registration for SciPy India 2014 (http://scipy.in) is open. SciPy India 2014 will be held in IIT Bombay between December 5th to December 7th, 2014. Please spread the word! SciPy India is an annual conference on using Python for science and engineering research and education. The conference is currently in its sixth year and provides an opportunity to learn and implement Python in education and research. Call for Papers ================ We look forward to your submissions on the use of Python for scientific computing and education. This includes pedagogy, exploration, modeling and analysis from both applied and developmental perspectives. We welcome contributions from academia as well as industry. For details on the paper submission please see here: http://scipy.in/2014/call-for-proposals/ Important Dates ================ - Call for proposals end: 9th November 2014 We look forward to seeing you at SciPy India. Regards, Prabhu Ramachandran and Jarrod Millman From vatan.uml at gmail.com Sat Nov 15 22:56:04 2014 From: vatan.uml at gmail.com (vattan) Date: Sat, 15 Nov 2014 22:56:04 -0500 Subject: [SciPy-Dev] scikit guide, writing one Message-ID: Hello folks, just subscribed to the list and I am looking to get some feedback. I am a brand new scipy convert, never used it prior to about 3 weeks ago, always used Octave/Matlab, but since Octave doesn't have a GUI generator, I decided it was time to jump full in and here I am. anyways I am porting over my limited old scripts and functions and my fluid flow stuff has grown exponentionally and is quite convenient imho. I would love to lend it out to the community as a scikit, but it ilikely is highly divergent from what the norm and standard is as I am NOT a programmer by trade or schooling, and I have neve even used python before. I am willing to put it up on github or whever a normal place for such a kit would be if anyone is willing to help me keep it conforming to "best practices" and avoid dumb pitfalls. As it sits now it is probably too poorly written to be of any use to anyone but me, however much to my surprise I couldn't find a equivalent already out in the wild. currently it has channel objects that define a geometry, fluid flow objects that contain a channel, length, fluid. It also has a few unit converters functions for convenience, sample materials etc. I really enjoy writing this stuff, i just don't have a ton of time, but every now and then I just like to sit and code for a day straight when I can, its very cathartic vs what I normally do. From pav at iki.fi Sun Nov 16 13:53:50 2014 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 16 Nov 2014 20:53:50 +0200 Subject: [SciPy-Dev] Release schedule Message-ID: Hi, The 0.14.1 and 0.15.0 releases were delayed a bit. My suggested release plan is below: 0.14.1 - rc1: Nov 23 - final: Dec 7 High-priority bugfixes have still some time to be backported. Currently, I'm aware of the OSX/SGEMV issue which could be added, plus expm integer dtype fix. 0.15.0 - branch & beta1: Nov 23 - rc1: Dec 7 - final: Dec 20 The 0.15.0 has a number of issues tagged for it: https://github.com/scipy/scipy/milestones/0.15.0 Pauli From cournape at gmail.com Mon Nov 17 06:40:23 2014 From: cournape at gmail.com (David Cournapeau) Date: Mon, 17 Nov 2014 11:40:23 +0000 Subject: [SciPy-Dev] Release schedule In-Reply-To: References: Message-ID: Hi Paul, Thanks for taking care of this release. I will take care of the backport for expm since I am the one who reported the issue. I have noticed some issues with numpy 1.9.1 + scipy 0.14.x using the MKL (hard crases in scipy.linalg.interpolative). I am still figuring out whether this is coming from a bug in our end or something genuine. David On Sun, Nov 16, 2014 at 6:53 PM, Pauli Virtanen wrote: > Hi, > > The 0.14.1 and 0.15.0 releases were delayed a bit. My suggested release > plan is below: > > 0.14.1 > > - rc1: Nov 23 > - final: Dec 7 > > High-priority bugfixes have still some time to be backported. Currently, > I'm aware of the OSX/SGEMV issue which could be added, plus expm integer > dtype fix. > > > 0.15.0 > > - branch & beta1: Nov 23 > - rc1: Dec 7 > - final: Dec 20 > > The 0.15.0 has a number of issues tagged for it: > https://github.com/scipy/scipy/milestones/0.15.0 > > Pauli > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vatan.uml at gmail.com Sun Nov 16 14:20:38 2014 From: vatan.uml at gmail.com (vattan) Date: Sun, 16 Nov 2014 14:20:38 -0500 Subject: [SciPy-Dev] Best practice property storage Message-ID: I am working on a module to handle simple fluid and thermal problems. To simplify data entry i am storing material properties as dicts named after the material, ie air{'density':1.2,....} and my functions can just take a material that is predefined or created by the user and use it assuming the needed properties are defined. My concern is this may be too simplistic, for example in the future my module may need to vary density with temperature, but my current logic is all material properties are static. Am I better off using objects to contain mtl properties so that they can contain functions to modify inter-related properties? Thanks guys, hope to get my stuff cleaned up and on github by next weekend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan at rdodesigns.com Mon Nov 17 16:39:28 2014 From: ryan at rdodesigns.com (Ryan Orendorff) Date: Mon, 17 Nov 2014 13:39:28 -0800 Subject: [SciPy-Dev] PyOp: Linear Operator package Message-ID: Hi SciPy, We wanted to get our recent work on an extended linear operator package out there to the community and get your thoughts. We are calling our work PyOp and the motivation is to extend the scipy.sparse.linalg LinearOperator class. In particular, our goals are to integrate robust ability for matrix-free methods and use in inverse problems (forward and adjoint operations). This includes seemless composition of various forms of operators (dense/sparse matrix, matrix-free functions) and a handful of useful predefined operators (convolve, FFT, gradient, etc.). We are inoperable with the scipy LinearOperator functions, support various ways of constructing block operators (bmat), and we have implemented convenient methods for working with vectorized inputs. Source: https://github.com/rdodesigns/pyop Documentation: http://rdodesigns.github.io/pyop/ Ryan Orendorff and Daniel Hensley From gavishnoam at gmail.com Mon Nov 17 17:34:18 2014 From: gavishnoam at gmail.com (Noam Gavish) Date: Tue, 18 Nov 2014 00:34:18 +0200 Subject: [SciPy-Dev] Best practice property storage In-Reply-To: References: Message-ID: I think that you have the answer in your question: use objects. For example, you want the instances check themselves for Boyle's law. On Sun, Nov 16, 2014 at 9:20 PM, vattan wrote: > I am working on a module to handle simple fluid and thermal problems. To > simplify data entry i am storing material properties as dicts named after > the material, ie air{'density':1.2,....} and my functions can just take a > material that is predefined or created by the user and use it assuming the > needed properties are defined. > My concern is this may be too simplistic, for example in the future my > module may need to vary density with temperature, but my current logic is > all material properties are static. Am I better off using objects to > contain mtl properties so that they can contain functions to modify > inter-related properties? > > Thanks guys, hope to get my stuff cleaned up and on github by next weekend. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -- - - - If you walk the footsteps of a stranger You will learn things you never knew you never knew -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmcgibbo at gmail.com Mon Nov 17 19:23:39 2014 From: rmcgibbo at gmail.com (Robert McGibbon) Date: Mon, 17 Nov 2014 16:23:39 -0800 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: > We are only talking about making LAPACK available for Cython though. C and C++ extension modules would have to take care of this themselves using the Python C API. Perhaps we should provide an example on how to do that? Does anyone have information on how to do this? It would be very much appreciated. -Robert On Wed, Oct 1, 2014 at 11:12 AM, Chad Fulton wrote: > > > On Thu, Sep 25, 2014 at 6:53 PM, Sturla Molden > wrote: > >> On 26/09/14 03:47, Sturla Molden wrote: >> > On 25/09/14 23:22, Ian Henriksen wrote: >> > >> >> I've opened this pull request >> >> that implements this. There >> >> are still several things I'd like to finish before it gets merged, but >> >> the basic functionality is there. Feedback is welcome. >> > >> > > It would be great to have this in Scipy - we have done the same thing, but > on an ad hoc basis, in Statsmodels. It would be much preferred to have it > centralized. Thanks for the work. > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.hirschfeld at gmail.com Wed Nov 19 03:47:05 2014 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 19 Nov 2014 08:47:05 +0000 (UTC) Subject: [SciPy-Dev] Release schedule References: Message-ID: David Cournapeau gmail.com> writes: > > > > > Hi Paul, > Thanks for taking care of this release. > > I will take care of the backport for expm since I am the one who reported the issue. > > I have noticed some issues with numpy 1.9.1 + scipy 0.14.x using the MKL (hard crases in scipy.linalg.interpolative). I am still figuring out whether this is coming from a bug in our end or something genuine.David > > Hi David, I'm curious whether or not you got to the bottom of the MKL crash, and what version of the MKL you're using? I recently was experiencing random segfaults in the MKL interpolation routine with version 11.1.0.103 using cython wrappers on Win64, Python 2.7. Whilst I could reliably reproduce the segfault, it only happened at random times when under heavy load in a large simulation and I couldn't isolate a minimal test case. Although I would normally consider that it's much more likely to be a problem with my cython wrappers upgrading to MKL 11.2 solved the problem and it has been solid as a rock ever since. -Dave From ghisvail at gmail.com Wed Nov 19 04:13:11 2014 From: ghisvail at gmail.com (Ghislain Vaillant) Date: Wed, 19 Nov 2014 09:13:11 +0000 Subject: [SciPy-Dev] PyOp: Linear Operator package Message-ID: <546C5F27.2070902@gmail.com> Dear Ryan, Do we really need yet another linear operator package where existing solutions like linop [1] or pyoperators [2] exist and work well ? Wouldn't it be better to contribute to either of these projects instead ? Best regards, Ghis [1] https://github.com/ghisvail/linop [2] https://github.com/pchanial/pyoperators From larsmans at gmail.com Wed Nov 19 06:04:45 2014 From: larsmans at gmail.com (Lars Buitinck) Date: Wed, 19 Nov 2014 12:04:45 +0100 Subject: [SciPy-Dev] PyOp: Linear Operator package In-Reply-To: <546C5F27.2070902@gmail.com> References: <546C5F27.2070902@gmail.com> Message-ID: 2014-11-19 10:13 GMT+01:00 Ghislain Vaillant : > Do we really need yet another linear operator package where existing > solutions like linop [1] or pyoperators [2] exist and work well ? > Wouldn't it be better to contribute to either of these projects instead ? Pointing this discussion in a slightly different direction: is there any way that SciPy can facilitate interoperability of these various packages? Ryan's email follows a discussion I had with him and Daniel off-list after announcing my plan to patch up scipy.sparse.linalg's version of this idea. My new version includes a class hierarchy of linear operators, but it might be wise, e.g., to install subclass hooks so that linop/PyOp/pyoperators/whatever objects work seamlessly with SciPy. Vice versa, the other packages can copy this hook into their own ABCs so that everybody's linear operators work with everybody else's libraries without everyone needing to import SciPy. From dave.hirschfeld at gmail.com Wed Nov 19 09:08:37 2014 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 19 Nov 2014 14:08:37 +0000 (UTC) Subject: [SciPy-Dev] Release schedule References: Message-ID: David Cournapeau gmail.com> writes: > > > > > Hi Paul, > Thanks for taking care of this release. > > I will take care of the backport for expm since I am the one who reported the issue. > > I have noticed some issues with numpy 1.9.1 + scipy 0.14.x using the MKL (hard crases in scipy.linalg.interpolative). I am still figuring out whether this is coming from a bug in our end or something genuine.David > > Hi David, I'm curious whether or not you got to the bottom of the MKL crash, and what version of the MKL you're using? I recently was experiencing random segfaults in the MKL interpolation routine with version 11.1.0.103 using cython wrappers on Win64, Python 2.7. Whilst I could reliably reproduce the segfault, it only happened at random times when under heavy load in a large simulation and I couldn't isolate a minimal test case. Although I would normally consider that it's much more likely to be a problem with my cython wrappers upgrading to MKL 11.2 solved the problem and it has been solid as a rock ever since. -Dave From insertinterestingnamehere at gmail.com Wed Nov 19 13:17:01 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Wed, 19 Nov 2014 11:17:01 -0700 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On Mon, Nov 17, 2014 at 5:23 PM, Robert McGibbon wrote: > > We are only talking about making LAPACK available for Cython though. C > and C++ extension modules would have to take care of this themselves > using the Python C API. Perhaps we should provide an example on how to do > that? > > Does anyone have information on how to do this? It would be very much > appreciated. > Thanks for reminding me about this. The easiest solution for SciPy itself would be to declare all the function pointers as public and have Cython generate a header file to go along with the module so that C and C++ modules could use the declarations with less effort. I worked on that a little, but ran in to some trouble getting complex types to work properly. I'll revisit that in the next few days and see if I can get it working. I don't currently have a full working example on hand, but I'll get back to you if I get a good one put together. > > -Robert > > On Wed, Oct 1, 2014 at 11:12 AM, Chad Fulton wrote: > >> >> >> On Thu, Sep 25, 2014 at 6:53 PM, Sturla Molden >> wrote: >> >>> On 26/09/14 03:47, Sturla Molden wrote: >>> > On 25/09/14 23:22, Ian Henriksen wrote: >>> > >>> >> I've opened this pull request >>> >> that implements this. >>> There >>> >> are still several things I'd like to finish before it gets merged, but >>> >> the basic functionality is there. Feedback is welcome. >>> > >>> >> >> It would be great to have this in Scipy - we have done the same thing, >> but on an ad hoc basis, in Statsmodels. It would be much preferred to have >> it centralized. Thanks for the work. >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From insertinterestingnamehere at gmail.com Wed Nov 19 14:27:19 2014 From: insertinterestingnamehere at gmail.com (Ian Henriksen) Date: Wed, 19 Nov 2014 12:27:19 -0700 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: In working on the pull request to implement this, I've run in to some trouble in picking the right module structure for the new Cython modules. I'm posting here to see if we can get a few better ideas that what I currently have. In the long run, I'd like to leave space so that wrappers that operate on memoryviews instead of just pointers can be added to scipy.linalg. This would, ultimately mean that there would be several new modules added in scipy.linalg. One for each the sets of function pointers corresponding to BLAS and LAPACK, and one for each of the modules defining routines that operate on memoryviews. I'm fairly certain that the C-compiled tests that are currently there should not be included in the tests directories. I've never seen that done anywhere else and was unable to get it working when I tried here. One option would be to rewrite the tests so that they use Python callable versions of the new Cython wrappers to test for correctness. That will take me a little more time, but it is probably the best solution. My current favorite idea for the structure is to do this linalg/ cython_blas_pointers (function pointers, already written) cython_blas (memory view versions, to be added later) cython_lapack_pointers (function pointers, already written) cython_lapack (memory view versions, to be added later) and then rewrite the tests in pure Python using function calls to cython_blas and cython_lapack for the functions that I have tests for. The names here are up for discussion too. The fact that these are function pointers is really just an implementation detail, but I'm not really sure what else to call the raw function pointer interface. It seems to be the most descriptive choice, since these are function pointers that operate on pointers to arrays. If we wanted shorter module names we could do linalg/ cyblas cyblas_ptrs cylapack cylapack_ptrs Another alternative would be to put these modules all in a new submodule of scipy.linalg. The current version in the pull request does this, but the submodule is called "cython" and that is causing name collision issues. The submodule could instead be called "cylinalg" or "cython_wrappers", or something else along those lines. What are your thoughts? Thanks! -Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From sturla.molden at gmail.com Wed Nov 19 21:31:27 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Thu, 20 Nov 2014 03:31:27 +0100 Subject: [SciPy-Dev] Expose Lapack for Cython In-Reply-To: References: <20140911152440.GN19676@phare.normalesup.org> Message-ID: On 19/11/14 20:27, Ian Henriksen wrote: > Another alternative would be to put these modules all in a new submodule > of scipy.linalg. The current version in the pull request does this, but > the submodule is called "cython" and that is causing name collision issues. > The submodule could instead be called "cylinalg" or "cython_wrappers", or > something else along those lines. I think that special memoryview versions will be a hard nut to crack because there it is not obvious what the API should be. A memory has metadata while a Fortran 77 array has not, so metadata is typically passed along with the array in BLAS and LAPACK subroutines. memoryvrappers would probably also be expected to ensure correct alignment of the array and ensure it is Fortran contiguous. C pointer versions can easily be used with typed memoryviews, just pass the address of the first element. The important part is to get the versions with C pointers working. I am not sure the hypothetical memoryview versions, for which API is not even thought through, will ever be realized. If you use the metadata in typed memoryviews the API deviate so much from LAPACK that we might just as well use scipy.linalg Python functions. If you don't use the metadata they don't add any value beyond the C pointer versions. All in all, I think what you should do is ignore memoryviews and just focus on getting the C pointers versions ready for SciPy 0.15.0. The ideas of creating a typed memoryview abstraction for LAPACK is distracting the important work. Sturla From dave.hirschfeld at gmail.com Fri Nov 21 08:50:43 2014 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Fri, 21 Nov 2014 13:50:43 +0000 (UTC) Subject: [SciPy-Dev] Release schedule References: Message-ID: David Cournapeau gmail.com> writes: > > > > > Hi Paul, > Thanks for taking care of this release. > > I will take care of the backport for expm since I am the one who reported the issue. > > I have noticed some issues with numpy 1.9.1 + scipy 0.14.x using the MKL (hard crases in scipy.linalg.interpolative). I am still figuring out whether this is coming from a bug in our end or something genuine.David > > Hi David, I'm curious whether or not you got to the bottom of the MKL crash, and what version of the MKL you're using? I recently was experiencing random segfaults in the MKL interpolation routine with version 11.1.0.103 using cython wrappers on Win64, Python 2.7. Whilst I could reliably reproduce the segfault, it only happened at random times when under heavy load in a large simulation and I couldn't isolate a minimal test case. Although I would normally consider that it's much more likely to be a problem with my cython wrappers upgrading to MKL 11.2 solved the problem and it has been solid as a rock ever since. -Dave From ralf.gommers at gmail.com Sun Nov 23 11:13:38 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 23 Nov 2014 17:13:38 +0100 Subject: [SciPy-Dev] removing umfpack wrapper In-Reply-To: <544A5A36.10403@ntc.zcu.cz> References: <528549FD.7080000@ntc.zcu.cz> <544A5A36.10403@ntc.zcu.cz> Message-ID: On Fri, Oct 24, 2014 at 3:55 PM, Robert Cimrman wrote: > On 11/14/2013 11:09 PM, Robert Cimrman wrote: > > > > Anyway, I will migrate the scikit so that there is a place to go after > the > > removal. The maintenance should not be that demanding as the umfpack > library > > API has been quite stable. > > FYI: https://github.com/rc/scikit-umfpack (sources taken from the last > version > that was in scipy) > Nice, thanks Robert! Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sun Nov 23 15:50:58 2014 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 23 Nov 2014 22:50:58 +0200 Subject: [SciPy-Dev] Release schedule In-Reply-To: References: Message-ID: <547248B2.8010509@iki.fi> Dear all, 16.11.2014, 20:53, Pauli Virtanen kirjoitti: > 0.14.1 > > - rc1: Nov 23 > - final: Dec 7 > > High-priority bugfixes have still some time to be backported. Currently, > I'm aware of the OSX/SGEMV issue which could be added, plus expm integer > dtype fix. I will delay 0.14.1rc1 a couple of days, in case we manage to resolve the following remaining issue: https://github.com/scipy/scipy/issues/4168 > 0.15.0 > > - branch & beta1: Nov 23 > - rc1: Dec 7 > - final: Dec 20 > > The 0.15.0 has a number of issues tagged for it: > https://github.com/scipy/scipy/milestones/0.15.0 I have just branched 0.15.x, beta1 will follow. Bugfixes can still be backported to the maintenance/0.15.x branch for a few weeks. Best regards, Pauli Virtanen From pav at iki.fi Sun Nov 23 18:13:03 2014 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 24 Nov 2014 01:13:03 +0200 Subject: [SciPy-Dev] ANN: Scipy 0.15.0 beta 1 release Message-ID: <547269FF.7010905@iki.fi> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have finally finished preparing the Scipy 0.15.0 beta 1 release. Please try it and report any issues on the scipy-dev mailing list, and/or on Github. If no surprises turn up, the final release is planned on Dec 20 in three weeks. Source tarballs and full release notes are available at https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ Binary installers should also be up soon. Best regards, Pauli Virtanen - -------------------------------------------- SciPy 0.15.0 is the culmination of 6 months of hard work. It contains several new features, numerous bug-fixes, improved test coverage and better documentation. There have been a number of deprecations and API changes in this release, which are documented below. All users are encouraged to upgrade to this release, as there are a large number of bug-fixes and optimizations. Moreover, our development attention will now shift to bug-fix releases on the 0.16.x branch, and on adding new features on the master branch. This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or greater. New features ============ Linear Programming Interface - - ---------------------------- The new function ``scipy.optimize.linprog`` provides a generic linear programming similar to the way ``scipy.optimize.minimize`` provides a generic interface to nonlinear programming optimizers. Currently the only method supported is *simplex* which provides a two-phase, dense-matrix-based simplex algorithm. Callbacks functions are supported,allowing the user to monitor the progress of the algorithm. Differential_evolution, a global optimizer - - ------------------------------------------ A new ``differential_evolution`` function is available in the ``scipy.optimize`` module. Differential Evolution is an algorithm used for finding the global minimum of multivariate functions. It is stochastic in nature (does not use gradient methods), and can search large areas of candidate space, but often requires larger numbers of function evaluations than conventional gradient based techniques. ``scipy.signal`` improvements - - ----------------------------- The function ``max_len_seq`` was added, which computes a Maximum Length Sequence (MLS) signal. ``scipy.integrate`` improvements - - -------------------------------- It is now possible to use ``scipy.integrate`` routines to integrate multivariate ctypes functions, thus avoiding callbacks to Python and providing better performance. ``scipy.linalg`` improvements - - ----------------------------- Add function ``orthogonal_procrustes`` for solving the procrustes linear algebra problem. ``scipy.sparse`` improvements - - ----------------------------- ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its main input. ``scipy.special`` improvements - - ------------------------------ Values of ellipsoidal harmonic (i.e. Lame) functions and associated normalization constants can be now computed using ``ellip_harm``, ``ellip_harm_2``, and ``ellip_normal``. New convenience functions ``entr``, ``rel_entr`` ``kl_div``, ``huber``, and ``pseudo_huber`` were added. ``scipy.sparse.csgraph`` improvements - - ------------------------------------- Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` for computing reorderings of sparse graphs were added. ``scipy.stats`` improvements - - ---------------------------- Added a Dirichlet distribution as multivariate distribution. The new function ``scipy.stats.median_test`` computes Mood's median test. The new function ``scipy.stats.combine_pvalues`` implements Fisher's and Stouffer's methods for combining p-values. ``scipy.stats.describe`` returns a namedtuple rather than a tuple, allowing users to access results by index or by name. Deprecated features =================== The ``scipy.weave`` module is deprecated. It was the only module never ported to Python 3.x, and is not recommended to be used for new code - use Cython instead. In order to support existing code, ``scipy.weave`` has been packaged separately: `https://github.com/scipy/weave`_. It is a pure Python package, and can easily be installed with ``pip install weave``. ``scipy.special.bessel_diff_formula`` is deprecated. It is a private function, and therefore will be removed from the public API in a following release. Backwards incompatible changes ============================== scipy.ndimage - - ------------- The functions ``scipy.ndimage.minimum_positions``, ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return positions as ints instead of floats. scipy.integrate - - --------------- The format of banded Jacobians in ``scipy.integrate.ode`` solvers is changed. Note that the previous documentation of this feature was erroneous. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRyaf8ACgkQ6BQxb7O0pWC7XQCeNtdJD4ZNDXvFeNFs7N3KjQn6 8QkAoK3pFmhMrTwCrgkusl+fRNMboN2r =WSpM -----END PGP SIGNATURE----- From matthew.brett at gmail.com Mon Nov 24 21:26:16 2014 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 24 Nov 2014 18:26:16 -0800 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <547269FF.7010905@iki.fi> References: <547269FF.7010905@iki.fi> Message-ID: Hi, On Sun, Nov 23, 2014 at 3:13 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finally finished preparing the Scipy 0.15.0 beta 1 release. > Please try it and report any issues on the scipy-dev mailing list, > and/or on Github. > > If no surprises turn up, the final release is planned on Dec 20 in > three weeks. > > Source tarballs and full release notes are available at > https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ > Binary installers should also be up soon. > > Best regards, > Pauli Virtanen > > > - -------------------------------------------- > > SciPy 0.15.0 is the culmination of 6 months of hard work. It contains > several new features, numerous bug-fixes, improved test coverage and > better documentation. There have been a number of deprecations and > API changes in this release, which are documented below. All users > are encouraged to upgrade to this release, as there are a large number > of bug-fixes and optimizations. Moreover, our development attention > will now shift to bug-fix releases on the 0.16.x branch, and on adding > new features on the master branch. > > This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or > greater. > > > New features > ============ > > Linear Programming Interface > - - ---------------------------- > > The new function ``scipy.optimize.linprog`` provides a generic > linear programming similar to the way ``scipy.optimize.minimize`` > provides a generic interface to nonlinear programming optimizers. > Currently the only method supported is *simplex* which provides > a two-phase, dense-matrix-based simplex algorithm. Callbacks > functions are supported,allowing the user to monitor the progress > of the algorithm. > > Differential_evolution, a global optimizer > - - ------------------------------------------ > > A new ``differential_evolution`` function is available in the > ``scipy.optimize`` > module. Differential Evolution is an algorithm used for finding the > global > minimum of multivariate functions. It is stochastic in nature (does > not use > gradient methods), and can search large areas of candidate space, but > often > requires larger numbers of function evaluations than conventional gradient > based techniques. > > ``scipy.signal`` improvements > - - ----------------------------- > > The function ``max_len_seq`` was added, which computes a Maximum > Length Sequence (MLS) signal. > > ``scipy.integrate`` improvements > - - -------------------------------- > > It is now possible to use ``scipy.integrate`` routines to integrate > multivariate ctypes functions, thus avoiding callbacks to Python and > providing better performance. > > ``scipy.linalg`` improvements > - - ----------------------------- > > Add function ``orthogonal_procrustes`` for solving the procrustes > linear algebra problem. > > ``scipy.sparse`` improvements > - - ----------------------------- > > ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its > main input. > > ``scipy.special`` improvements > - - ------------------------------ > > Values of ellipsoidal harmonic (i.e. Lame) functions and associated > normalization constants can be now computed using ``ellip_harm``, > ``ellip_harm_2``, and ``ellip_normal``. > > New convenience functions ``entr``, ``rel_entr`` ``kl_div``, > ``huber``, and ``pseudo_huber`` were added. > > ``scipy.sparse.csgraph`` improvements > - - ------------------------------------- > > Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` > for computing reorderings of sparse graphs were added. > > ``scipy.stats`` improvements > - - ---------------------------- > > Added a Dirichlet distribution as multivariate distribution. > > The new function ``scipy.stats.median_test`` computes Mood's median test. > > The new function ``scipy.stats.combine_pvalues`` implements Fisher's > and Stouffer's methods for combining p-values. > > ``scipy.stats.describe`` returns a namedtuple rather than a tuple, > allowing > users to access results by index or by name. > > Deprecated features > =================== > > The ``scipy.weave`` module is deprecated. It was the only module > never ported > to Python 3.x, and is not recommended to be used for new code - use Cython > instead. In order to support existing code, ``scipy.weave`` has been > packaged > separately: `https://github.com/scipy/weave`_. It is a pure Python > package, and > can easily be installed with ``pip install weave``. > > ``scipy.special.bessel_diff_formula`` is deprecated. It is a private > function, > and therefore will be removed from the public API in a following release. > > > Backwards incompatible changes > ============================== > > scipy.ndimage > - - ------------- > > The functions ``scipy.ndimage.minimum_positions``, > ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return > positions as ints instead of floats. > > scipy.integrate > - - --------------- > > The format of banded Jacobians in ``scipy.integrate.ode`` solvers is > changed. Note that the previous documentation of this feature was > erroneous. I ran against current scipy stack packages, and get these errors: https://travis-ci.org/MacPython/scipy-stack-osx-testing/jobs/42022929#L324 ====================================================================== ERROR: test_netcdf.test_byte_gatts ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/test_netcdf.py", line 268, in test_byte_gatts f = netcdf_file(filename, 'w') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/netcdf.py", line 226, in __init__ self.fp = open(self.filename, '%sb' % omode) IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/data/g_byte_atts.nc' ====================================================================== ERROR: test_netcdf.test_open_append ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/test_netcdf.py", line 284, in test_open_append f = netcdf_file(filename, 'w') File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/netcdf.py", line 226, in __init__ self.fp = open(self.filename, '%sb' % omode) IOError: [Errno 13] Permission denied: '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/scipy/io/tests/data/append_dat.nc' This turns out to be because the netcdf tests are trying to write into the scipy/io/tests/data directory: https://github.com/scipy/scipy/pull/4198 Otherwise, it looks clean. I uploaded the OSX wheels to sourceforge. Cheers, Matthew From xmichael-k at web.de Mon Nov 24 02:42:39 2014 From: xmichael-k at web.de (Michael =?utf-8?b?S8OkcHBsZXI=?=) Date: Mon, 24 Nov 2014 07:42:39 +0000 (UTC) Subject: [SciPy-Dev] [Wiki] NumPy / Matlab-Cheatsheet Message-ID: Hi guys, thanks for this great cheatsheet you provided on wiki.scipy.org/NumPy_for_Matlab_Users. I'm not allowed to edit the wiki, so I would like to propose an addition regarding different array shaping conventions: Consider f.e. a Matlab zeros(1, 4). If I'm right, this results in a [0 0 0 0] or in something that Matlab treats like a 1D-Array if it makes sense. You can f.e. do diag(ones(1, 4)) and you get a matrix. However, NumPy zeros((1,4)) results in [[0 0 0 0]], which is 2D and if you try to do diag(ones((1,4))) you will get [1], which is obviously different behaviour compared to Matlab. NumPy zeros(4) yields [0 0 0 0] which seems to me is the correct equivalent. Other Matlab commands that use this array shaping syntax are also affected in the same way. I recently ran into this issue while porting some Matlab code to NumPy. Have a nice week, Michael From toddrjen at gmail.com Tue Nov 25 04:30:07 2014 From: toddrjen at gmail.com (Todd) Date: Tue, 25 Nov 2014 10:30:07 +0100 Subject: [SciPy-Dev] [Wiki] NumPy / Matlab-Cheatsheet In-Reply-To: References: Message-ID: On Nov 25, 2014 9:30 AM, "Michael K?ppler" wrote: > > Hi guys, > thanks for this great cheatsheet you provided on > wiki.scipy.org/NumPy_for_Matlab_Users. > I'm not allowed to edit the wiki, so I would like to propose an addition > regarding different array shaping conventions: Consider f.e. a Matlab > zeros(1, 4). > If I'm right, this results in a [0 0 0 0] or in something that Matlab > treats like a 1D-Array if it makes sense. You can f.e. do > diag(ones(1, 4)) and you get a matrix. > However, NumPy zeros((1,4)) results in [[0 0 0 0]], which is 2D and if you > try to do diag(ones((1,4))) you will get [1], which is obviously different > behaviour compared to Matlab. > NumPy zeros(4) yields [0 0 0 0] which seems to me is the correct > equivalent. Other Matlab commands that use this array shaping syntax are > also affected in the same way. > I recently ran into this issue while porting some Matlab code to NumPy. > > Have a nice week, > Michael Is this something that might be moved to github so it would be easier to submit changes? -------------- next part -------------- An HTML attachment was scrubbed... URL: From apps.embedded at gmail.com Tue Nov 25 04:39:23 2014 From: apps.embedded at gmail.com (Apps Embedded) Date: Tue, 25 Nov 2014 10:39:23 +0100 Subject: [SciPy-Dev] SciPy under Android Message-ID: Hi, We are about publishing an Android app with all the SciPy python packages. We will include : - Python - Numpy package - Scipy package - Matplotlib package - pandas package - Sympy package - iPython - nose package The app will be published under a freemium model. The free app will include a small top ad banner and enable user to use all the packages. However in this free app, graphics will not be available. In the premium app for a very small fee under the Play Store, user will have access to the same things as the free version but the top ad banner will be removed and the graphics will be enabled with the use of Matplotlib. We are going to call these two apps "LabPy Console Free" and "LabPy Console Premium". The licence of the work bundle will be GPL v3 but the Python software and all the associated packages will stay in their respective licence. We will of course publish the source code of all the project. We had recently the written approbation of the Python Trademark comittee from a trademark point of view. We are writing this email to see if there are no legal issue we are missing with the licence for example and if the name of the app LabPy Console Free / Premium is ok from your point of view. Best regards. Apps Embedded Team. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanlu001 at gmail.com Tue Nov 25 05:28:56 2014 From: juanlu001 at gmail.com (Juan Luis Cano) Date: Tue, 25 Nov 2014 11:28:56 +0100 Subject: [SciPy-Dev] [Wiki] NumPy / Matlab-Cheatsheet In-Reply-To: References: Message-ID: +1 On Nov 25, 2014 10:30 AM, "Todd" wrote: > > On Nov 25, 2014 9:30 AM, "Michael K?ppler" wrote: > > > > Hi guys, > > thanks for this great cheatsheet you provided on > > wiki.scipy.org/NumPy_for_Matlab_Users. > > I'm not allowed to edit the wiki, so I would like to propose an addition > > regarding different array shaping conventions: Consider f.e. a Matlab > > zeros(1, 4). > > If I'm right, this results in a [0 0 0 0] or in something that Matlab > > treats like a 1D-Array if it makes sense. You can f.e. do > > diag(ones(1, 4)) and you get a matrix. > > However, NumPy zeros((1,4)) results in [[0 0 0 0]], which is 2D and if > you > > try to do diag(ones((1,4))) you will get [1], which is obviously > different > > behaviour compared to Matlab. > > NumPy zeros(4) yields [0 0 0 0] which seems to me is the correct > > equivalent. Other Matlab commands that use this array shaping syntax are > > also affected in the same way. > > I recently ran into this issue while porting some Matlab code to NumPy. > > > > Have a nice week, > > Michael > > Is this something that might be moved to github so it would be easier to > submit changes? > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Tue Nov 25 07:53:03 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 25 Nov 2014 12:53:03 +0000 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <547269FF.7010905@iki.fi> References: <547269FF.7010905@iki.fi> Message-ID: Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker (the issue arises on scipy master as well as 0.14.1) ? On Sun, Nov 23, 2014 at 11:13 PM, Pauli Virtanen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear all, > > We have finally finished preparing the Scipy 0.15.0 beta 1 release. > Please try it and report any issues on the scipy-dev mailing list, > and/or on Github. > > If no surprises turn up, the final release is planned on Dec 20 in > three weeks. > > Source tarballs and full release notes are available at > https://sourceforge.net/projects/scipy/files/SciPy/0.15.0b1/ > Binary installers should also be up soon. > > Best regards, > Pauli Virtanen > > > - -------------------------------------------- > > SciPy 0.15.0 is the culmination of 6 months of hard work. It contains > several new features, numerous bug-fixes, improved test coverage and > better documentation. There have been a number of deprecations and > API changes in this release, which are documented below. All users > are encouraged to upgrade to this release, as there are a large number > of bug-fixes and optimizations. Moreover, our development attention > will now shift to bug-fix releases on the 0.16.x branch, and on adding > new features on the master branch. > > This release requires Python 2.6, 2.7 or 3.2-3.3 and NumPy 1.5.1 or > greater. > > > New features > ============ > > Linear Programming Interface > - - ---------------------------- > > The new function ``scipy.optimize.linprog`` provides a generic > linear programming similar to the way ``scipy.optimize.minimize`` > provides a generic interface to nonlinear programming optimizers. > Currently the only method supported is *simplex* which provides > a two-phase, dense-matrix-based simplex algorithm. Callbacks > functions are supported,allowing the user to monitor the progress > of the algorithm. > > Differential_evolution, a global optimizer > - - ------------------------------------------ > > A new ``differential_evolution`` function is available in the > ``scipy.optimize`` > module. Differential Evolution is an algorithm used for finding the > global > minimum of multivariate functions. It is stochastic in nature (does > not use > gradient methods), and can search large areas of candidate space, but > often > requires larger numbers of function evaluations than conventional gradient > based techniques. > > ``scipy.signal`` improvements > - - ----------------------------- > > The function ``max_len_seq`` was added, which computes a Maximum > Length Sequence (MLS) signal. > > ``scipy.integrate`` improvements > - - -------------------------------- > > It is now possible to use ``scipy.integrate`` routines to integrate > multivariate ctypes functions, thus avoiding callbacks to Python and > providing better performance. > > ``scipy.linalg`` improvements > - - ----------------------------- > > Add function ``orthogonal_procrustes`` for solving the procrustes > linear algebra problem. > > ``scipy.sparse`` improvements > - - ----------------------------- > > ``scipy.sparse.linalg.svds`` can now take a ``LinearOperator`` as its > main input. > > ``scipy.special`` improvements > - - ------------------------------ > > Values of ellipsoidal harmonic (i.e. Lame) functions and associated > normalization constants can be now computed using ``ellip_harm``, > ``ellip_harm_2``, and ``ellip_normal``. > > New convenience functions ``entr``, ``rel_entr`` ``kl_div``, > ``huber``, and ``pseudo_huber`` were added. > > ``scipy.sparse.csgraph`` improvements > - - ------------------------------------- > > Routines ``reverse_cuthill_mckee`` and ``maximum_bipartite_matching`` > for computing reorderings of sparse graphs were added. > > ``scipy.stats`` improvements > - - ---------------------------- > > Added a Dirichlet distribution as multivariate distribution. > > The new function ``scipy.stats.median_test`` computes Mood's median test. > > The new function ``scipy.stats.combine_pvalues`` implements Fisher's > and Stouffer's methods for combining p-values. > > ``scipy.stats.describe`` returns a namedtuple rather than a tuple, > allowing > users to access results by index or by name. > > Deprecated features > =================== > > The ``scipy.weave`` module is deprecated. It was the only module > never ported > to Python 3.x, and is not recommended to be used for new code - use Cython > instead. In order to support existing code, ``scipy.weave`` has been > packaged > separately: `https://github.com/scipy/weave`_. It is a pure Python > package, and > can easily be installed with ``pip install weave``. > > ``scipy.special.bessel_diff_formula`` is deprecated. It is a private > function, > and therefore will be removed from the public API in a following release. > > > Backwards incompatible changes > ============================== > > scipy.ndimage > - - ------------- > > The functions ``scipy.ndimage.minimum_positions``, > ``scipy.ndimage.maximum_positions`` and ``scipy.ndimage.extrema`` return > positions as ints instead of floats. > > scipy.integrate > - - --------------- > > The format of banded Jacobians in ``scipy.integrate.ode`` solvers is > changed. Note that the previous documentation of this feature was > erroneous. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlRyaf8ACgkQ6BQxb7O0pWC7XQCeNtdJD4ZNDXvFeNFs7N3KjQn6 > 8QkAoK3pFmhMrTwCrgkusl+fRNMboN2r > =WSpM > -----END PGP SIGNATURE----- > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Tue Nov 25 13:33:25 2014 From: cournape at gmail.com (David Cournapeau) Date: Tue, 25 Nov 2014 18:33:25 +0000 Subject: [SciPy-Dev] [Numpy-discussion] Scipy 0.15.0 beta 1 release In-Reply-To: <135351674438631559.674600sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <135351674438631559.674600sturla.molden-gmail.com@news.gmane.org> Message-ID: On Tue, Nov 25, 2014 at 6:10 PM, Sturla Molden wrote: > David Cournapeau wrote: > > Shall we consider > href="https://github.com/scipy/scipy/issues/4168"> > https://github.com/scipy/scipy/issues/4168 > > to be a > > blocker (the issue arises on scipy master as well as 0.14.1) ? > > > > It is really bad, but does anyone know what is really going on? > Yes, it is in the bug report. David > > Which changes to NumPy set this off? > > Sturla > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Tue Nov 25 13:39:28 2014 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Nov 2014 18:39:28 +0000 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: References: <547269FF.7010905@iki.fi> Message-ID: On Tue, Nov 25, 2014 at 12:53 PM, David Cournapeau wrote: > Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker > (the issue arises on scipy master as well as 0.14.1) ? Do you think there's anything scipy can do about it? It looks like a pure numpy bug to me. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org From sturla.molden at gmail.com Tue Nov 25 14:07:42 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 19:07:42 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> Message-ID: <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Nathaniel Smith wrote: > On Tue, Nov 25, 2014 at 12:53 PM, David Cournapeau wrote: >> Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker >> (the issue arises on scipy master as well as 0.14.1) ? > > Do you think there's anything scipy can do about it? It looks like a > pure numpy bug to me. I think we should assume it is not a bug in NumPy. There is nothing that dictates that an ndarray's buffer must be aligned. It can just as well be an unaligned view or wrap an external buffer. An ndarray is valud with any alignment, but it does not mean it can be used with intent(inout) in f2py. Then by deduction if it is not a NumPy bug it must be a SciPy bug, which means the bug must be the unprotected use of intent(inout) in the f2py wrapper. I would think it is the responsibility of SciPy to ensure that whatever is passed with intent(inout) in SciPy is properly aligned. I believe there is not NumPy bug because f2py is doing the right thing and reporting the error. Sturla From njs at pobox.com Tue Nov 25 14:14:46 2014 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Nov 2014 19:14:46 +0000 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: On Tue, Nov 25, 2014 at 7:07 PM, Sturla Molden wrote: > Nathaniel Smith wrote: >> On Tue, Nov 25, 2014 at 12:53 PM, David Cournapeau wrote: >>> Shall we consider https://github.com/scipy/scipy/issues/4168 to be a blocker >>> (the issue arises on scipy master as well as 0.14.1) ? >> >> Do you think there's anything scipy can do about it? It looks like a >> pure numpy bug to me. > > I think we should assume it is not a bug in NumPy. There is nothing that > dictates that an ndarray's buffer must be aligned. It can just as well be > an unaligned view or wrap an external buffer. An ndarray is valud with any > alignment, but it does not mean it can be used with intent(inout) in f2py. > > Then by deduction if it is not a NumPy bug it must be a SciPy bug, which > means the bug must be the unprotected use of intent(inout) in the f2py > wrapper. I would think it is the responsibility of SciPy to ensure that > whatever is passed with intent(inout) in SciPy is properly aligned. In general you have a point, but in this case the reason the array is "unaligned" is that numpy is being overly strict about its definition of "aligned". In fact, it's so strict that numpy itself doesn't provide any standard and reliable way to *create* an aligned array by this definition. (I guess scipy could create an overallocated copy and then take a slice at the right offset, but asking scipy to use such hacks to work around our bugs is clearly wrong.) -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org From pav at iki.fi Tue Nov 25 14:47:45 2014 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 25 Nov 2014 21:47:45 +0200 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: 25.11.2014, 21:07, Sturla Molden kirjoitti: [clip] > I believe there is not NumPy bug because f2py is doing the right thing and > reporting the error. Numpy changed its definition in 1.9.1. of what an array of "aligned complex doubles" means. The new definition of alignment is stricter than that defined by the C compiler, and system malloc() does not provide sufficient alignment. I do not believe there are Fortran compilers that in practice require this definition of alignment. -- Pauli Virtanen From pav at iki.fi Tue Nov 25 14:50:43 2014 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 25 Nov 2014 21:50:43 +0200 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: 25.11.2014, 21:14, Nathaniel Smith kirjoitti: [clip] > (I guess scipy could create an overallocated copy and then take a > slice at the right offset, but asking scipy to use such hacks to work > around our bugs is clearly wrong.) Note that the issue is not just with Scipy, but with *all* f2py code that is out there. Everyone who uses "double complex, intent(inout)" in their f2py wrapped code will start getting random exceptions on Windows. Users of "double complex, intent(in)" pay a performance penalty. -- Pauli Virtanen From sturla.molden at gmail.com Tue Nov 25 17:25:45 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 22:25:45 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: <98559507438646927.770478sturla.molden-gmail.com@news.gmane.org> Pauli Virtanen wrote: > The new definition of alignment is stricter than that defined by the C > compiler, and system malloc() does not provide sufficient alignment. I > do not believe there are Fortran compilers that in practice require this > definition of alignment. What they require is one thing, but at least Intel has started to recommend alignment to 32 bytes boundaries for AVX and 64 byte boundaries for Xeon Phi. Clearly someone could read this and put -align array64bytes in the FFLAGS. https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization I am not sure what ifort actually requires without this, though. Sturla From sturla.molden at gmail.com Tue Nov 25 17:44:31 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 22:44:31 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> Message-ID: <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> Pauli Virtanen wrote: > The new definition of alignment is stricter than that defined by the C > compiler, and system malloc() does not provide sufficient alignment. I > do not believe there are Fortran compilers that in practice require this > definition of alignment. All of this would have been avoided if f2py used Fortran's ISO C bindings like fwrap does. Then the alignment issue would be taken care of by the Fortran compiler itself. The root of the problem is that f2py tries to call Fortran from C in a non-standard way. Sturla From charlesnwoods at gmail.com Tue Nov 25 17:56:19 2014 From: charlesnwoods at gmail.com (Nathan Woods) Date: Tue, 25 Nov 2014 15:56:19 -0700 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> Message-ID: <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> Fortran?s ISO C bindings are a feature not present in Fortran 77, and so they cannot be counted on for something that relies on legacy compilers. > On Nov 25, 2014, at 3:44 PM, Sturla Molden wrote: > > Pauli Virtanen wrote: > >> The new definition of alignment is stricter than that defined by the C >> compiler, and system malloc() does not provide sufficient alignment. I >> do not believe there are Fortran compilers that in practice require this >> definition of alignment. > > All of this would have been avoided if f2py used Fortran's ISO C bindings > like fwrap does. Then the alignment issue would be taken care of by the > Fortran compiler itself. The root of the problem is that f2py tries to call > Fortran from C in a non-standard way. > > Sturla > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From sturla.molden at gmail.com Tue Nov 25 18:38:22 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 23:38:22 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> Message-ID: <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> Nathan Woods wrote: > Fortran?s ISO C bindings are a feature not present in Fortran 77, and so > they cannot be counted on for something that relies on legacy compilers. The purpose of Carl Kleffner's MinGW toolchain was to avoid legacy compilers. g77 was only used on Windows. At least last time this was discussed the conclusion was that we do not any longer have a limitation to Fortran 77 in SciPy. Sturla From sturla.molden at gmail.com Tue Nov 25 18:42:28 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 23:42:28 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> Message-ID: <1434879908438651698.466870sturla.molden-gmail.com@news.gmane.org> Nathan Woods wrote: > Fortran?s ISO C bindings are a feature not present in Fortran 77, and so > they cannot be counted on for something that relies on legacy compilers. https://github.com/scipy/scipy/issues/2829 From njs at pobox.com Tue Nov 25 18:49:51 2014 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 25 Nov 2014 23:49:51 +0000 Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release In-Reply-To: <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> Message-ID: On Tue, Nov 25, 2014 at 11:38 PM, Sturla Molden wrote: > Nathan Woods wrote: > >> Fortran?s ISO C bindings are a feature not present in Fortran 77, and so >> they cannot be counted on for something that relies on legacy compilers. > > The purpose of Carl Kleffner's MinGW toolchain was to avoid legacy > compilers. g77 was only used on Windows. > > At least last time this was discussed the conclusion was that we do not any > longer have a limitation to Fortran 77 in SciPy. The mingw-w64 approach is very promising, but we ain't there yet. Even some intensive debugging over the last few weeks [1] (it turns out mingw-w64 has buggy thread+floating point stuff, workaroundable for our purposes), the numpy test suite still isn't fully passing. There's also this: http://sourceforge.net/p/mingw-w64/mailman/message/31768118/ And nevermind all the projects downstream that use f2py. Throwing away f2py's support for g77 seems a bit premature. -n [1] https://github.com/numpy/numpy/issues/5194 -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org From sturla.molden at gmail.com Tue Nov 25 18:59:07 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Tue, 25 Nov 2014 23:59:07 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> Message-ID: <1240705825438652490.784686sturla.molden-gmail.com@news.gmane.org> Nathaniel Smith wrote: > Throwing away f2py's support for g77 seems a bit premature. It would be a large change to f2py and g77 would be completely gone long before it would be ready. I was just trying to point out the real root of the problem, because it is not actually data alignment as such. Sturla From sturla.molden at gmail.com Tue Nov 25 22:26:28 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 26 Nov 2014 03:26:28 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <547269FF.7010905@iki.fi> <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> Message-ID: <357675633438663515.152202sturla.molden-gmail.com@news.gmane.org> Nathaniel Smith wrote: > The mingw-w64 approach is very promising, but we ain't there yet. Even > some intensive debugging over the last few weeks [1] (it turns out > mingw-w64 has buggy thread+floating point stuff, workaroundable for > our purposes), the numpy test suite still isn't fully passing. Well, it is CPython (compiled with MSVC) that spawns threads, so I don't really see how this behavior can be blamed on mingw-w64? > There's > also this: > http://sourceforge.net/p/mingw-w64/mailman/message/31768118/ > And nevermind all the projects downstream that use f2py. This is related to libwinpthread, which is not used by SciPy AFAIK. But perhaps at some point we would like to use OpenMP? Sturla From sturla.molden at gmail.com Tue Nov 25 22:56:35 2014 From: sturla.molden at gmail.com (Sturla Molden) Date: Wed, 26 Nov 2014 03:56:35 +0000 (UTC) Subject: [SciPy-Dev] [Numpy-discussion] ANN: Scipy 0.15.0 beta 1 release References: <1792165665438634567.990743sturla.molden-gmail.com@news.gmane.org> <347587711438647327.385456sturla.molden-gmail.com@news.gmane.org> <47007B93-9EDE-4A6F-A0F3-97C33333ACCB@gmail.com> <2067848996438651250.877148sturla.molden-gmail.com@news.gmane.org> <357675633438663515.152202sturla.molden-gmail.com@news.gmane.org> Message-ID: <1132820262438666958.390018sturla.molden-gmail.com@news.gmane.org> Sturla Molden wrote: > Well, it is CPython (compiled with MSVC) that spawns threads, so I don't > really see how this behavior can be blamed on mingw-w64? Sorry, I misunderstood, ignore this. From irvin.probst at ensta-bretagne.fr Wed Nov 26 13:59:43 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Wed, 26 Nov 2014 19:59:43 +0100 Subject: [SciPy-Dev] Pole placement Message-ID: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> Hi, Is there any reason why scipy has no pole placement method (ppol in Scilab or place in Matlab)? I.e for a given linear system xdot=A*X+B*U, and a given set of poles P, find K such as eigenvalues(A-BK)=P ? Or did I miss it in the doc ? I'm aware of python-control (http://www.cds.caltech.edu/~murray/wiki/Control_Systems_Library_for_Python) but 99.9% of the time I use it it is ONLY for pole placement as scipy already provides enough tools for simple linear systems simulations, furthermore python-control's place() function only task is to call the relevant function in the Scilot library (which I also need to install BTW+ bindings from scylot). So, I've started to port in "pure" numpy/python matlab's place() function which is based on Kautsky et Al's algorithm, would it be of any intest for you ? It is not rocket science, and it is not finished yet, but I thought it could be useful for other people. Let me know what you think and sorry for the disturbance if it is not relevant for you. Regards -- Irvin From ralf.gommers at gmail.com Wed Nov 26 15:29:11 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 26 Nov 2014 21:29:11 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> Message-ID: On Wed, Nov 26, 2014 at 7:59 PM, Irvin Probst < irvin.probst at ensta-bretagne.fr> wrote: > Hi, > > Is there any reason why scipy has no pole placement method (ppol in > Scilab or place in Matlab)? Simply that no one has implemented it yet. > I.e for a given linear system xdot=A*X+B*U, > and a given set of poles P, find K such as eigenvalues(A-BK)=P ? Or did > I miss it in the doc ? > > I'm aware of python-control > ( > http://www.cds.caltech.edu/~murray/wiki/Control_Systems_Library_for_Python > ) > but 99.9% of the time I use it it is ONLY for pole placement as scipy > already provides enough tools for simple linear systems simulations, > furthermore python-control's place() function only task is to call the > relevant function in the Scilot library (which I also need to install > BTW+ bindings from scylot). > > So, I've started to port in "pure" numpy/python matlab's place() > function which is based on Kautsky et Al's algorithm, would it be of any > intest for you ? It is not rocket science, and it is not finished yet, > but I thought it could be useful for other people. > This function would be useful to add to scipy.signal it looks like. Contribution very welcome. You cannot submit code that you translated from Matlab though, you'd have to implement it based on a paper describing the algorithm or translate it from BSD-compatible code. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From irvin.probst at ensta-bretagne.fr Wed Nov 26 16:06:23 2014 From: irvin.probst at ensta-bretagne.fr (Irvin Probst) Date: Wed, 26 Nov 2014 22:06:23 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> Message-ID: <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> On Wed, 26 Nov 2014 21:29:11 +0100, Ralf Gommers wrote: > > This function would be useful to add to scipy.signal it looks like. > Contribution very welcome. You cannot submit code that you translated > from Matlab though, you'd have to implement it based on a paper > describing the algorithm or translate it from BSD-compatible code. The problem is that matlab's function was written in 1986 using the paper describing the algorithm I wished to implement (I realized that only after looking at this paper). Whatever I'll do it will still be the same algorithm providing the same solution, which in the end is not a bad thing as matlab's place() is probably the most used pole placement function. Of course I can obfuscate it such as it does not look like matlab's code but you can't change the fact that I wrote it while reading matlab's code... Do you have any advices on what I should do ? If it can be of any help see at the end of this email the header of matlab's place.m. There is also an algorithm in Scilab (I can't remember the main author name) but it's written in Fortran and I'm not fluent in this language... Source is here: http://people.eng.unimelb.edu.au/mcgood/ctrl433/matlab/place.m function [K,prec,message] = place(A,B,P) %PLACE Pole placement technique % % K = PLACE(A,B,P) computes a state-feedback matrix K such that % the eigenvalues of A-B*K are those specified in vector P. % No eigenvalue should have a multiplicity greater than the % number of inputs. % % [K,PREC,MESSAGE] = PLACE(A,B,P) returns PREC, an estimate of how % closely the eigenvalues of A-B*K match the specified locations P % (PREC measures the number of accurate decimal digits in the actual % closed-loop poles). If some nonzero closed-loop pole is more than % 10% off from the desired location, MESSAGE contains a warning % message. % % See also ACKER. % M. Wette 10-1-86 % Revised 9-25-87 JNL % Revised 8-4-92 Wes Wang % Revised 10-5-93, 6-1-94 Andy Potvin % Revised 4-11-2001 John Glass, Pascal Gahinet % % Ref:: Kautsky, Nichols, Van Dooren, "Robust Pole Assignment in Linear % State Feedback," Intl. J. Control, 41(1985)5, pp 1129-1155 % % Copyright 1986-2001 The MathWorks, Inc. % $Revision: 1.13 $ $Date: 2001/08/27 12:58:53 $ From ralf.gommers at gmail.com Wed Nov 26 16:25:24 2014 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 26 Nov 2014 22:25:24 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> Message-ID: On Wed, Nov 26, 2014 at 10:06 PM, Irvin Probst < irvin.probst at ensta-bretagne.fr> wrote: > On Wed, 26 Nov 2014 21:29:11 +0100, Ralf Gommers wrote: > > > > This function would be useful to add to scipy.signal it looks like. > > Contribution very welcome. You cannot submit code that you translated > > from Matlab though, you'd have to implement it based on a paper > > describing the algorithm or translate it from BSD-compatible code. > > The problem is that matlab's function was written in 1986 using the > paper describing the algorithm I wished to implement (I realized that > only after looking at this paper). > Whatever I'll do it will still be the same algorithm providing the same > solution, which in the end is not a bad thing as matlab's place() is > probably the most used pole placement function. > Of course I can obfuscate it such as it does not look like matlab's > code but you can't change the fact that I wrote it while reading > matlab's code... > Well, the issue is not that you implement the same algorithm which might make the source code look similar, but that you looked at the Matlab source code. Linking that source code probably doesn't help either:) What I suggest is that you contact the authors of the Scilab algorithm and ask them if they're willing to relicense their code under the BSD license for inclusion in Scipy. And then wrap that with f2py (probably won't be too hard). Ralf Do you have any advices on what I should do ? If it can be of any help > see at the end of this email the header of matlab's place.m. > > There is also an algorithm in Scilab (I can't remember the main author > name) but it's written in Fortran and I'm not fluent in this language... > > Source is here: > http://people.eng.unimelb.edu.au/mcgood/ctrl433/matlab/place.m > > > function [K,prec,message] = place(A,B,P) > %PLACE Pole placement technique > % > % K = PLACE(A,B,P) computes a state-feedback matrix K such that > % the eigenvalues of A-B*K are those specified in vector P. > % No eigenvalue should have a multiplicity greater than the > % number of inputs. > % > % [K,PREC,MESSAGE] = PLACE(A,B,P) returns PREC, an estimate of how > % closely the eigenvalues of A-B*K match the specified locations P > % (PREC measures the number of accurate decimal digits in the actual > % closed-loop poles). If some nonzero closed-loop pole is more than > % 10% off from the desired location, MESSAGE contains a warning > % message. > % > % See also ACKER. > > % M. Wette 10-1-86 > % Revised 9-25-87 JNL > % Revised 8-4-92 Wes Wang > % Revised 10-5-93, 6-1-94 Andy Potvin > % Revised 4-11-2001 John Glass, Pascal Gahinet > % > % Ref:: Kautsky, Nichols, Van Dooren, "Robust Pole Assignment in > Linear > % State Feedback," Intl. J. Control, 41(1985)5, pp 1129-1155 > % > > % Copyright 1986-2001 The MathWorks, Inc. > % $Revision: 1.13 $ $Date: 2001/08/27 12:58:53 $ > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Wed Nov 26 17:11:03 2014 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Wed, 26 Nov 2014 22:11:03 +0000 Subject: [SciPy-Dev] Blomberg open source event London 29-30 Nov Message-ID: Hi, In case somebody is interested and have not heard about it --- Blooomberg is organizing a two-day open source event for scientific python in London this weekend, Nov 28-29. The event is RSVP: http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/ Here are related annoucements/discussions in pydata and numpy lists: https://groups.google.com/forum/#!topic/pydata/Z9Nd3sQH8Lw http://mail.scipy.org/pipermail/numpy-discussion/2014-November/071724.html If you are not around, consider joining remotely --- I do not speak for the organizers, but we can always self-organize on github or ML. See you on Saturday --- in person or online, Evgeni -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.bucher at supsi.ch Wed Nov 26 17:41:58 2014 From: roberto.bucher at supsi.ch (SUPSI) Date: Wed, 26 Nov 2014 23:41:58 +0100 Subject: [SciPy-Dev] Pole placement In-Reply-To: References: <37444037c94390313c6e01bdd34b5fe5@webmail.ensta-bretagne.fr> <48828d0c3b178a5115ff6831b6f4f544@webmail.ensta-bretagne.fr> Message-ID: <54765736.5020506@supsi.ch> I've already implemented the scicoslab algorithm for my yottalab packages wich covers some not already implemented functions in the python-control package. This file: http://robertobucher.dti.supsi.ch/bucherdl/pyControlDistro.tgz contains the folder "toolbox->supsictrl>pplace" with the required files, and in yottalab.py is implemented the "placep" function. I had contacts with the people developing scicoslab, and the files where from an old slycot library version which were distributed under GPL (if I right remember). Best regards Roberto On 11/26/2014 10:25 PM, Ralf Gommers wrote: > > > On Wed, Nov 26, 2014 at 10:06 PM, Irvin Probst > > wrote: > > On Wed, 26 Nov 2014 21:29:11 +0100, Ralf Gommers wrote: > > > > This function would be useful to add to scipy.signal it looks like. > > Contribution very welcome. You cannot submit code that you > translated > > from Matlab though, you'd have to implement it based on a paper > > describing the algorithm or translate it from BSD-compatible code. > > The problem is that matlab's function was written in 1986 using the > paper describing the algorithm I wished to implement (I realized that > only after looking at this paper). > Whatever I'll do it will still be the same algorithm providing the > same > solution, which in the end is not a bad thing as matlab's place() is > probably the most used pole placement function. > Of course I can obfuscate it such as it does not look like matlab's > code but you can't change the fact that I wrote it while reading > matlab's code... > > > Well, the issue is not that you implement the same algorithm which > might make the source code look similar, but that you looked at the > Matlab source code. Linking that source code probably doesn't help > either:) > > What I suggest is that you contact the authors of the Scilab algorithm > and ask them if they're willing to relicense their code under the BSD > license for inclusion in Scipy. And then wrap that with f2py (probably > won't be too hard). > > Ralf > > > Do you have any advices on what I should do ? If it can be of any help > see at the end of this email the header of matlab's place.m. > > There is also an algorithm in Scilab (I can't remember the main author > name) but it's written in Fortran and I'm not fluent in this > language... > > Source is here: > http://people.eng.unimelb.edu.au/mcgood/ctrl433/matlab/place.m > > > function [K,prec,message] = place(A,B,P) > %PLACE Pole placement technique > % > % K = PLACE(A,B,P) computes a state-feedback matrix K such that > % the eigenvalues of A-B*K are those specified in vector P. > % No eigenvalue should have a multiplicity greater than the > % number of inputs. > % > % [K,PREC,MESSAGE] = PLACE(A,B,P) returns PREC, an estimate of how > % closely the eigenvalues of A-B*K match the specified locations P > % (PREC measures the number of accurate decimal digits in the actual > % closed-loop poles). If some nonzero closed-loop pole is more than > % 10% off from the desired location, MESSAGE contains a warning > % message. > % > % See also ACKER. > > % M. Wette 10-1-86 > % Revised 9-25-87 JNL > % Revised 8-4-92 Wes Wang > % Revised 10-5-93, 6-1-94 Andy Potvin > % Revised 4-11-2001 John Glass, Pascal Gahinet > % > % Ref:: Kautsky, Nichols, Van Dooren, "Robust Pole Assignment in > Linear > % State Feedback," Intl. J. Control, 41(1985)5, pp 1129-1155 > % > > % Copyright 1986-2001 The MathWorks, Inc. > % $Revision: 1.13 $ $Date: 2001/08/27 12:58:53 $ > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Wed Nov 26 19:38:33 2014 From: cournape at gmail.com (David Cournapeau) Date: Thu, 27 Nov 2014 00:38:33 +0000 Subject: [SciPy-Dev] Blomberg open source event London 29-30 Nov In-Reply-To: References: Message-ID: I will be there as well, helping people who are interested in either numpy or scipy On Wed, Nov 26, 2014 at 10:11 PM, Evgeni Burovski < evgeny.burovskiy at gmail.com> wrote: > Hi, > > In case somebody is interested and have not heard about it --- Blooomberg > is organizing a two-day open source event for scientific python in London > this weekend, Nov 28-29. > > The event is RSVP: > > > > > > http://go.bloomberg.com/promo/invite/bloomberg-open-source-day-scientific-python/ > > Here are related annoucements/discussions in pydata and numpy lists: > > https://groups.google.com/forum/#!topic/pydata/Z9Nd3sQH8Lw > > http://mail.scipy.org/pipermail/numpy-discussion/2014-November/071724.html > > If you are not around, consider joining remotely --- I do not speak for > the organizers, but we can always self-organize on github or ML. > > > See you on Saturday --- in person or online, > > Evgeni > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cimrman3 at ntc.zcu.cz Fri Nov 28 09:54:08 2014 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Fri, 28 Nov 2014 15:54:08 +0100 Subject: [SciPy-Dev] ANN: SfePy 2014.4 Message-ID: <54788C90.1080405@ntc.zcu.cz> I am pleased to announce release 2014.4 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method or by the isogeometric analysis (preliminary support). It is distributed under the new BSD license. Home page: http://sfepy.org Mailing list: http://groups.google.com/group/sfepy-devel Git (source) repository, issue tracker, wiki: http://github.com/sfepy Highlights of this release -------------------------- - preliminary support for 1D problems - data probes using pyVTK library For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Lubos Kejzlar, Vladimir Lukes