Mailman 3 May 2015 - SciPy-Dev

Out of Core Sparse Matrices
by Aidan Macdonald May 31, 2015

May 31, 2015

Hi, I work for Brightcloud and part of my work required me to write Out of Core Sparse Matrices. I was thinking of submitting these to Scipy as it currently has Sparse Matrices, but not out of core. I was wondering if this code would be a desired addition to SciPy. Also, currently it uses the Python Sqlite3 library. Is it okay to use the Sqlite3 package? Could I also get documentation about writing test cases? I notice that you use NOSE. It there any specification about integrating my test cases into SciPy. I would only need a simple modification to the existing sparse test cases. Thank you, Aidan Macdonald aidan(a)brightcloud.com aidan.plenert.macdonald(a)gmail.com

4 5

Re: [SciPy-Dev] [Numpy-discussion] Verify your sourceforge windows installer downloads
by David Cournapeau May 29, 2015

May 29, 2015

On Fri, May 29, 2015 at 2:00 AM, Andrew Collette <andrew.collette(a)gmail.com> wrote: > > Here is their lame excuse: > > > > > https://sourceforge.net/blog/gimp-win-project-wasnt-hijacked-just-abandoned/ > > > > It probably means this: > > > > If NumPy installers are moved away from Sourceforge, they will set up a > > mirror and load the mirrored installers with all sorts of crapware. It is > > some sort of racket the mob couldn't do better. > > I noticed that like most BSD-licensed software, NumPy's license > includes this clause: > > "Neither the name of the NumPy Developers nor the names of any > contributors may be used to endorse or promote products derived from > this software without specific prior written permission." > > There's an argument to be made that SF isn't legally permitted to > distribute poisoned installers under the name "NumPy" without > permission. I recall a similar dust-up a while ago about "Standard > Markdown" using the name "Markdown"; the original author (John Gruber) > took action and got them to change the name. > > In any case I've always been surprised that NumPy is distributed > through SourceForge, which has been sketchy for years now. Could it > simply be hosted on PyPI? > They don't accept arbitrary binaries like SF does, and some of our installer formats can't be uploaded there. David > > Andrew > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >

2 1

ANN: SfePy 2015.2
by Robert Cimrman May 29, 2015

May 29, 2015

I am pleased to announce release 2015.2 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 -------------------------- - major code simplification (removed element groups) - time stepping solvers updated for interactive use - improved finding of reference element coordinates of physical points - reorganized examples - reorganized installation on POSIX systems (sfepy-run script) 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, Anton Gladky, Matyas Novak

1 0

Verify your sourceforge windows installer downloads
by Julian Taylor May 28, 2015

May 28, 2015

hi, It has been reported that sourceforge has taken over the gimp unofficial windows downloader page and temporarily bundled the installer with unauthorized adware: https://plus.google.com/+gimp/posts/cxhB1PScFpe As NumPy is also distributing windows installers via sourceforge I recommend that when you download the files you verify the downloads via the checksums in the README.txt before using them. The README.txt is clearsigned with my gpg key so it should be safe from tampering. Unfortunately as I don't use windows I cannot give any advice on how to do the verifcation on these platforms. Maybe someone familar with available tools can chime in. I have checked the numpy downloads and they still match what I uploaded, but as sourceforge does redirect based on OS and geolocation this may not mean much. Cheers, Julian Taylor

5 5

Re: [SciPy-Dev] Repository for GSoC project
by Jaime Fernández del Río May 28, 2015

May 28, 2015

Thanks everyone for the feedback. After some more thinking, I have asked Aman to start sending PRs directly against the current master of scipy. To differentiate new from old implementations, we'll probably just prepend all file names with "ndi_" instead of the current "ni_". We will eventually start removing old functionality that has been replaced, but for quite sometime they will both coexist. This means that at some point in time, e.g. calling `ndimage.filters.uniform_filter1d` may use the new Cython code paths, while `ndimage.filters.minimum_filter1d` may still be using the old C code paths. We will not merge anything, answering Juan's question, until we have tests that validate that functionality. That does not mean that the functionality will be available to end users just yet, e.g. we may merge an iterator before any top level function that uses it. But if it does not have tests, it does not get merged. If anyone has a very strong opinion against this approach, please speak up now! Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

2 1

Repository for GSoC project
by Jaime Fernández del Río May 28, 2015

May 28, 2015

Hi all, This year I am mentoring Aman for one of the GSoC projects we have underway, "Rewriting ndimage in Cython." By its very nature it doesn't conform very well to the "many small pull requests" model: from the point of view of scipy, things are going to be broken up until almost the very last commit. I am not sure what the best way to set up a collaborative code development environment would be, and so am asking for the collective wisdom to help guide us. Aman could simply create one ginormous pull request that will grow, and grow, and not be merged until everything was ready. I don't like this idea too much, as it is going to eventually be a confusing mess, and I think it would also make it difficult for others than Aman (that would mostly be me) to contribute code. I think we could also use a branch, either on my fork of scipy or on Aman's, as the repository on which development would happen, and against which PRs would be created, and once completed send a single PR to the main scipy repo. This may work, but I don't like it much either. What probably makes more sense is to create a new branch **in the main scipy repository**, and have PRs sent and merged against that branch, which would eventually be merged with master upon completion. NumPy seems to have a couple such experimental branches ('with_maskna' and 'enable_separate_by_default'), although there is none in SciPy that I see. This would also allow us to keep the project in a controlled environment, even if by the end of the summer not every single bit of ndimage has been ported. If this third path is really the preferred way of doing things, I could probably set things up myself (Ralf gave me commit rights when I became a mentor for this project), but I'd like to hear what others think, before abusing my powers. Thanks! Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

7 10

[ndimage-gsoc2015] Weekly Summary 2015/05/25
by Jaime Fernández del Río May 27, 2015

May 27, 2015

Hi all, Aman and I had our first weekly sync meeting yesterday. After each of these weekly calls, I have asked Aman to publish a short summary, just like this one, on progress to date and plans for the week. If you would like to participate on one of these weekly meetings, just let us know. *Design Choices* 1. Use the NumPy iterator (numpy.flatiter in Python or PyArrayIterObject in C) for all basic array iteration, rather than a custom implementation as ndimage currently does. *Plan for the week* 1. Learn to use the NumPy iterator in Cython properly. 2. Send a first pull request against ndimage that: 1. Provides supporting Cython code for basic array iteration. 2. Translates an ndimage function that only requires basic iteration, to Cython. This will probably be find_objects from the measurements submodule. 3. Document the progress in a blog post. *Deliverables from last week* 1. None yet. Best, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0

`ss` and `square_of_sums` deprecation from `scipy.stats`
by Abraham Escalante May 27, 2015

May 27, 2015

Hello all, As part of StatisticsCleanup milestone `scipy.stats.ss` and `scipy.stats.square_of_sums` are to be deprecated. These are helper functions that were not meant to be exposed to users but we know for a fact that they are being used by some people, therefore we cannot just remove them from the API so we are going to put them through a normal deprecation period. If there are any objections to the deprecation of these functions, now would be a good time to speak up. Cheers, Abraham.

1 1

welcome Jaime and Anne to the Scipy core team
by Ralf Gommers May 26, 2015

May 26, 2015

Hi all, On behalf of the Scipy developers I'd like to welcome Jaime Fernandez del Rio and Anne Archibald as members of the Scipy core team. Jaime has been making improvements to mainly ndimage over the last year and will be mentoring Aman's GSoC project on ndimage. Anne used to have svn commit rights and made lots of improvements in scipy.spatial and scipy.interpolate in 2008/2009 - it's great to have her contributing again. Cheers, Ralf

3 2

dropping OS X dmg installers
by Ralf Gommers May 25, 2015

May 25, 2015

Hi, When updating the build scripts and release docs for 0.16.x I realized that: - the DMG installers haven't been built for 0.14.1 and 0.15.x - we didn't officially decide this AFAIK, but no one complained - the wheels we now have on pip for OS X are more general than the DMG installers; the latter only work with python.org Python. - wheels are also easier to build [1] and test [2] (thanks Matthew!) So shall we make it official that we won't build any more DMG installers for releases? Ralf [1] https://github.com/MacPython/scipy-wheels [2] https://github.com/MacPython/scipy-stack-osx-testing

4 5