From ralf.gommers at gmail.com Mon Apr 1 07:58:36 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 1 Apr 2013 13:58:36 +0200 Subject: [SciPy-Dev] NumPy/SciPy participation in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote: > > > > On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers wrote: > >> Hi all, >> >> It is the time of the year for Google Summer of Code applications. If we >> want to participate with Numpy and/or Scipy, we need two things: enough >> mentors and ideas for projects. If we get those, we'll apply under the PSF >> umbrella. They've outlined the timeline they're working by and guidelines >> at >> http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html. >> >> >> We should be able to come up with some interesting project ideas I'd >> think, let's put those at >> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with >> enough detail to be understandable for people new to the projects and a >> proposed mentor. >> >> We need at least 3 people willing to mentor a student. Ideally we'd have >> enough mentors this week, so we can apply to the PSF on time. If you're >> willing to be a mentor, please send me the following: name, email address, >> phone nr, and what you're interested in mentoring. If you have time >> constaints and have doubts about being able to be a primary mentor, being a >> backup mentor would also be helpful. >> > > So far we've only got one primary mentor (thanks Chuck!), most core devs > do not seem to have the bandwidth this year. If there are other people > interested in mentoring please let me know. If not, then it looks like > we're not participating this year. > Hi all, an update on GSoC'13. We do have enough mentoring power after all; NumPy/SciPy is now registered as a participating project on the PSF page: http://wiki.python.org/moin/SummerOfCode/2013 Prospective students: please have a look at http://wiki.python.org/moin/SummerOfCode/Expectations and at http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note that we require you to make one pull request to NumPy/SciPy which has to be merged *before* the application deadline (May 3). So please start thinking about that, and start a discussion on your project idea on this list. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From toddrjen at gmail.com Mon Apr 1 08:27:26 2013 From: toddrjen at gmail.com (Todd) Date: Mon, 1 Apr 2013 14:27:26 +0200 Subject: [SciPy-Dev] NumPy/SciPy participation in GSoC 2013 In-Reply-To: References: Message-ID: On Mon, Apr 1, 2013 at 1:58 PM, Ralf Gommers wrote: > > > > On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers wrote: > >> >> >> >> On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers wrote: >> >>> Hi all, >>> >>> It is the time of the year for Google Summer of Code applications. If we >>> want to participate with Numpy and/or Scipy, we need two things: enough >>> mentors and ideas for projects. If we get those, we'll apply under the PSF >>> umbrella. They've outlined the timeline they're working by and guidelines >>> at >>> http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html. >>> >>> >>> We should be able to come up with some interesting project ideas I'd >>> think, let's put those at >>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with >>> enough detail to be understandable for people new to the projects and a >>> proposed mentor. >>> >>> We need at least 3 people willing to mentor a student. Ideally we'd have >>> enough mentors this week, so we can apply to the PSF on time. If you're >>> willing to be a mentor, please send me the following: name, email address, >>> phone nr, and what you're interested in mentoring. If you have time >>> constaints and have doubts about being able to be a primary mentor, being a >>> backup mentor would also be helpful. >>> >> >> So far we've only got one primary mentor (thanks Chuck!), most core devs >> do not seem to have the bandwidth this year. If there are other people >> interested in mentoring please let me know. If not, then it looks like >> we're not participating this year. >> > > Hi all, an update on GSoC'13. We do have enough mentoring power after all; > NumPy/SciPy is now registered as a participating project on the PSF page: > http://wiki.python.org/moin/SummerOfCode/2013 > > Prospective students: please have a look at > http://wiki.python.org/moin/SummerOfCode/Expectations and at > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular > note that we require you to make one pull request to NumPy/SciPy which has > to be merged *before* the application deadline (May 3). So please start > thinking about that, and start a discussion on your project idea on this > list. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > There were a number of other ideas in this thread: http://mail.scipy.org/pipermail/numpy-discussion/2013-March/065699.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Tue Apr 2 11:24:25 2013 From: njs at pobox.com (Nathaniel Smith) Date: Tue, 2 Apr 2013 16:24:25 +0100 Subject: [SciPy-Dev] NumPy/SciPy participation in GSoC 2013 In-Reply-To: References: Message-ID: On Mon, Apr 1, 2013 at 12:58 PM, Ralf Gommers wrote: > On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers > wrote: >> >> >> >> >> On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers >> wrote: >>> >>> Hi all, >>> >>> It is the time of the year for Google Summer of Code applications. If we >>> want to participate with Numpy and/or Scipy, we need two things: enough >>> mentors and ideas for projects. If we get those, we'll apply under the PSF >>> umbrella. They've outlined the timeline they're working by and guidelines at >>> http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html. >>> >>> We should be able to come up with some interesting project ideas I'd >>> think, let's put those at >>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably with >>> enough detail to be understandable for people new to the projects and a >>> proposed mentor. >>> >>> We need at least 3 people willing to mentor a student. Ideally we'd have >>> enough mentors this week, so we can apply to the PSF on time. If you're >>> willing to be a mentor, please send me the following: name, email address, >>> phone nr, and what you're interested in mentoring. If you have time >>> constaints and have doubts about being able to be a primary mentor, being a >>> backup mentor would also be helpful. >> >> >> So far we've only got one primary mentor (thanks Chuck!), most core devs >> do not seem to have the bandwidth this year. If there are other people >> interested in mentoring please let me know. If not, then it looks like we're >> not participating this year. > > > Hi all, an update on GSoC'13. We do have enough mentoring power after all; > NumPy/SciPy is now registered as a participating project on the PSF page: > http://wiki.python.org/moin/SummerOfCode/2013 > > Prospective students: please have a look at > http://wiki.python.org/moin/SummerOfCode/Expectations and at > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular note > that we require you to make one pull request to NumPy/SciPy which has to be > merged *before* the application deadline (May 3). So please start thinking > about that, and start a discussion on your project idea on this list.> It doesn't look like I have the appropriate mojo to edit that page, but: - The NA thing at the bottom should just be deleted, dropping a student into that would be cruel... - Some new entries, perhaps someone could add? --------------- == Performance parity between numpy arrays and Python scalars == Small numpy arrays are very similar to Python scalars -- but numpy incurs a fair amount of extra overhead for simple operations. For large arrays this doesn't matter, but for code that manipulates a lot of small pieces of data, it can be a serious bottleneck. For example: {{{ In [1]: x = 1.0 In [2]: numpy_x = np.asarray(x) In [3]: timeit x + x 10000000 loops, best of 3: 61 ns per loop In [4]: timeit numpy_x + numpy_x 1000000 loops, best of 3: 1.66 us per loop }}} This project would involve profiling simple operations like the above, determining where the bottlenecks are, and devising improved algorithms to solve them, with the goal of getting the numpy time as close as possible to the Python time. Not only would this make all numpy-using code faster, but it would pave the way for future simplifications in numpy's core, which currently has a lot of duplicate code that attempts to work around these slow paths instead of fixing them properly. Some possible concrete changes: 1. numpy's "ufunc loop lookup code" (which is used to determine, e.g., whether to use the integer or floating-point versions of "+") is slow and inefficient. 2. Checking for floating point errors is very slow; we can and should do it less often. 3. When allocating the return value, the "+" for Python floats calls malloc() only once; numpy calls it twice (once for the array object itself, and a second time for the array data). Stashing both objects within a single allocation would be more efficient. 4. ...see what profiling says! We know 61 ns is possible. == Pythonic dtypes == A numpy "dtype" is an object that knows how to work with different sorts of values, represented as fixed-length packed binary values. For example, the int32 dtype knows how to convert the Python object '-1' to the four-byte buffer 0xff 0xff 0xff 0xff. Conceptually, dtype objects are arranged into a nice type hierarchy: http://docs.scipy.org/doc/numpy/_images/dtype-hierarchy.png But implementation-wise, dtypes don't use the Python class system at all. There's just a single Python class (numpy.dtype), and all dtypes are instances of it. (This is because when numpy was first designed, they only expected there to be maybe 20 dtype objects total.) This turns out to cause a number of problems -- you can't define new dtypes from Python, only from C; you can't use isinstance to compare dtypes (you have to use a hacky numpy-specific API instead); different dtypes can't easily contain state (instead, the single dtype class has gradually sprouted new fields as new dtypes turned out to need them); etc. Basically we've been reinventing the Python class system, poorly. The goal for this project is to turn dtype classes into regular Python classes with a proper type hierarchy and using the standard Python mechanisms. Longer term goals (at least the first of which is probably achievable within the SoC timeline): 1. Allow for defining new dtypes using pure Python. 2. There are a bunch of special cases in the ufunc code for handling strings and record arrays; we should make the appropriate extensions to the dtype API so that they can become regular dtypes. 3. A proper categorical data dtype. (This is trivial once the above is done.) 4. NA dtypes ------------------------------ I'm sort of tempted to propose "sparse ndarrays" as a project, but I think that's too ambitious and would just end in tears... I guess the only way to allow for incremental deliverables would be to develop it as a separate package, with the incremental pieces being changes to numpy core that made it possible to hook in such a deep change (e.g., new ufunc looping structure) from out-of-package code. -n From ralf.gommers at gmail.com Tue Apr 2 14:02:13 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 2 Apr 2013 20:02:13 +0200 Subject: [SciPy-Dev] NumPy/SciPy participation in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 2, 2013 at 5:24 PM, Nathaniel Smith wrote: > On Mon, Apr 1, 2013 at 12:58 PM, Ralf Gommers > wrote: > > On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers > > wrote: > >> > >> > >> > >> > >> On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers > >> wrote: > >>> > >>> Hi all, > >>> > >>> It is the time of the year for Google Summer of Code applications. If > we > >>> want to participate with Numpy and/or Scipy, we need two things: enough > >>> mentors and ideas for projects. If we get those, we'll apply under the > PSF > >>> umbrella. They've outlined the timeline they're working by and > guidelines at > >>> > http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html > . > >>> > >>> We should be able to come up with some interesting project ideas I'd > >>> think, let's put those at > >>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably > with > >>> enough detail to be understandable for people new to the projects and a > >>> proposed mentor. > >>> > >>> We need at least 3 people willing to mentor a student. Ideally we'd > have > >>> enough mentors this week, so we can apply to the PSF on time. If you're > >>> willing to be a mentor, please send me the following: name, email > address, > >>> phone nr, and what you're interested in mentoring. If you have time > >>> constaints and have doubts about being able to be a primary mentor, > being a > >>> backup mentor would also be helpful. > >> > >> > >> So far we've only got one primary mentor (thanks Chuck!), most core devs > >> do not seem to have the bandwidth this year. If there are other people > >> interested in mentoring please let me know. If not, then it looks like > we're > >> not participating this year. > > > > > > Hi all, an update on GSoC'13. We do have enough mentoring power after > all; > > NumPy/SciPy is now registered as a participating project on the PSF page: > > http://wiki.python.org/moin/SummerOfCode/2013 > > > > Prospective students: please have a look at > > http://wiki.python.org/moin/SummerOfCode/Expectations and at > > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular > note > > that we require you to make one pull request to NumPy/SciPy which has to > be > > merged *before* the application deadline (May 3). So please start > thinking > > about that, and start a discussion on your project idea on this list.> > > It doesn't look like I have the appropriate mojo to edit that page, but: > > - The NA thing at the bottom should just be deleted, dropping a > student into that would be cruel... > > - Some new entries, perhaps someone could add? > > --------------- > > == Performance parity between numpy arrays and Python scalars == > > Small numpy arrays are very similar to Python scalars -- but numpy > incurs a fair amount of extra overhead for simple operations. For > large arrays this doesn't matter, but for code that manipulates a lot > of small pieces of data, it can be a serious bottleneck. For example: > {{{ > In [1]: x = 1.0 > > In [2]: numpy_x = np.asarray(x) > > In [3]: timeit x + x > 10000000 loops, best of 3: 61 ns per loop > > In [4]: timeit numpy_x + numpy_x > 1000000 loops, best of 3: 1.66 us per loop > }}} > > This project would involve profiling simple operations like the above, > determining where the bottlenecks are, and devising improved > algorithms to solve them, with the goal of getting the numpy time as > close as possible to the Python time. Not only would this make all > numpy-using code faster, but it would pave the way for future > simplifications in numpy's core, which currently has a lot of > duplicate code that attempts to work around these slow paths instead > of fixing them properly. > > Some possible concrete changes: > 1. numpy's "ufunc loop lookup code" (which is used to determine, e.g., > whether to use the integer or floating-point versions of "+") is slow > and inefficient. > 2. Checking for floating point errors is very slow; we can and should > do it less often. > 3. When allocating the return value, the "+" for Python floats calls > malloc() only once; numpy calls it twice (once for the array object > itself, and a second time for the array data). Stashing both objects > within a single allocation would be more efficient. > 4. ...see what profiling says! We know 61 ns is possible. > > == Pythonic dtypes == > > A numpy "dtype" is an object that knows how to work with different > sorts of values, represented as fixed-length packed binary values. For > example, the int32 dtype knows how to convert the Python object '-1' > to the four-byte buffer 0xff 0xff 0xff 0xff. > > Conceptually, dtype objects are arranged into a nice type hierarchy: > http://docs.scipy.org/doc/numpy/_images/dtype-hierarchy.png > > But implementation-wise, dtypes don't use the Python class system at > all. There's just a single Python class (numpy.dtype), and all dtypes > are instances of it. (This is because when numpy was first designed, > they only expected there to be maybe 20 dtype objects total.) This > turns out to cause a number of problems -- you can't define new dtypes > from Python, only from C; you can't use isinstance to compare dtypes > (you have to use a hacky numpy-specific API instead); different dtypes > can't easily contain state (instead, the single dtype class has > gradually sprouted new fields as new dtypes turned out to need them); > etc. Basically we've been reinventing the Python class system, poorly. > > The goal for this project is to turn dtype classes into regular Python > classes with a proper type hierarchy and using the standard Python > mechanisms. > > Longer term goals (at least the first of which is probably achievable > within the SoC timeline): > 1. Allow for defining new dtypes using pure Python. > 2. There are a bunch of special cases in the ufunc code for handling > strings and record arrays; we should make the appropriate extensions > to the dtype API so that they can become regular dtypes. > 3. A proper categorical data dtype. (This is trivial once the above is > done.) > 4. NA dtypes > > ------------------------------ > Added those. Maybe one of the Trac admins can fix your edit rights. > > I'm sort of tempted to propose "sparse ndarrays" as a project, but I > think that's too ambitious and would just end in tears... That indeed sounds way too ambitious. Besides, there's already the idea of fixing up scipy.sparse to be much more consistent with ndarrays. That will yield some of the same benefits and should be a lot easier to do. Ralf > I guess the only way to allow for incremental deliverables would be to > develop it > as a separate package, with the incremental pieces being changes to > numpy core that made it possible to hook in such a deep change (e.g., > new ufunc looping structure) from out-of-package code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Apr 2 14:54:12 2013 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 2 Apr 2013 12:54:12 -0600 Subject: [SciPy-Dev] NumPy/SciPy participation in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 2, 2013 at 12:02 PM, Ralf Gommers wrote: > > > > On Tue, Apr 2, 2013 at 5:24 PM, Nathaniel Smith wrote: > >> On Mon, Apr 1, 2013 at 12:58 PM, Ralf Gommers >> wrote: >> > On Tue, Mar 26, 2013 at 12:27 AM, Ralf Gommers >> > wrote: >> >> >> >> >> >> >> >> >> >> On Thu, Mar 21, 2013 at 10:20 PM, Ralf Gommers > > >> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> It is the time of the year for Google Summer of Code applications. If >> we >> >>> want to participate with Numpy and/or Scipy, we need two things: >> enough >> >>> mentors and ideas for projects. If we get those, we'll apply under >> the PSF >> >>> umbrella. They've outlined the timeline they're working by and >> guidelines at >> >>> >> http://pyfound.blogspot.nl/2013/03/get-ready-for-google-summer-of-code.html >> . >> >>> >> >>> We should be able to come up with some interesting project ideas I'd >> >>> think, let's put those at >> >>> http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. Preferably >> with >> >>> enough detail to be understandable for people new to the projects and >> a >> >>> proposed mentor. >> >>> >> >>> We need at least 3 people willing to mentor a student. Ideally we'd >> have >> >>> enough mentors this week, so we can apply to the PSF on time. If >> you're >> >>> willing to be a mentor, please send me the following: name, email >> address, >> >>> phone nr, and what you're interested in mentoring. If you have time >> >>> constaints and have doubts about being able to be a primary mentor, >> being a >> >>> backup mentor would also be helpful. >> >> >> >> >> >> So far we've only got one primary mentor (thanks Chuck!), most core >> devs >> >> do not seem to have the bandwidth this year. If there are other people >> >> interested in mentoring please let me know. If not, then it looks like >> we're >> >> not participating this year. >> > >> > >> > Hi all, an update on GSoC'13. We do have enough mentoring power after >> all; >> > NumPy/SciPy is now registered as a participating project on the PSF >> page: >> > http://wiki.python.org/moin/SummerOfCode/2013 >> > >> > Prospective students: please have a look at >> > http://wiki.python.org/moin/SummerOfCode/Expectations and at >> > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas. In particular >> note >> > that we require you to make one pull request to NumPy/SciPy which has >> to be >> > merged *before* the application deadline (May 3). So please start >> thinking >> > about that, and start a discussion on your project idea on this list.> >> >> It doesn't look like I have the appropriate mojo to edit that page, but: >> >> - The NA thing at the bottom should just be deleted, dropping a >> student into that would be cruel... >> >> - Some new entries, perhaps someone could add? >> >> --------------- >> >> == Performance parity between numpy arrays and Python scalars == >> >> Small numpy arrays are very similar to Python scalars -- but numpy >> incurs a fair amount of extra overhead for simple operations. For >> large arrays this doesn't matter, but for code that manipulates a lot >> of small pieces of data, it can be a serious bottleneck. For example: >> {{{ >> In [1]: x = 1.0 >> >> In [2]: numpy_x = np.asarray(x) >> >> In [3]: timeit x + x >> 10000000 loops, best of 3: 61 ns per loop >> >> In [4]: timeit numpy_x + numpy_x >> 1000000 loops, best of 3: 1.66 us per loop >> }}} >> >> This project would involve profiling simple operations like the above, >> determining where the bottlenecks are, and devising improved >> algorithms to solve them, with the goal of getting the numpy time as >> close as possible to the Python time. Not only would this make all >> numpy-using code faster, but it would pave the way for future >> simplifications in numpy's core, which currently has a lot of >> duplicate code that attempts to work around these slow paths instead >> of fixing them properly. >> >> Some possible concrete changes: >> 1. numpy's "ufunc loop lookup code" (which is used to determine, e.g., >> whether to use the integer or floating-point versions of "+") is slow >> and inefficient. >> 2. Checking for floating point errors is very slow; we can and should >> do it less often. >> 3. When allocating the return value, the "+" for Python floats calls >> malloc() only once; numpy calls it twice (once for the array object >> itself, and a second time for the array data). Stashing both objects >> within a single allocation would be more efficient. >> 4. ...see what profiling says! We know 61 ns is possible. >> >> == Pythonic dtypes == >> >> A numpy "dtype" is an object that knows how to work with different >> sorts of values, represented as fixed-length packed binary values. For >> example, the int32 dtype knows how to convert the Python object '-1' >> to the four-byte buffer 0xff 0xff 0xff 0xff. >> >> Conceptually, dtype objects are arranged into a nice type hierarchy: >> http://docs.scipy.org/doc/numpy/_images/dtype-hierarchy.png >> >> But implementation-wise, dtypes don't use the Python class system at >> all. There's just a single Python class (numpy.dtype), and all dtypes >> are instances of it. (This is because when numpy was first designed, >> they only expected there to be maybe 20 dtype objects total.) This >> turns out to cause a number of problems -- you can't define new dtypes >> from Python, only from C; you can't use isinstance to compare dtypes >> (you have to use a hacky numpy-specific API instead); different dtypes >> can't easily contain state (instead, the single dtype class has >> gradually sprouted new fields as new dtypes turned out to need them); >> etc. Basically we've been reinventing the Python class system, poorly. >> >> The goal for this project is to turn dtype classes into regular Python >> classes with a proper type hierarchy and using the standard Python >> mechanisms. >> >> Longer term goals (at least the first of which is probably achievable >> within the SoC timeline): >> 1. Allow for defining new dtypes using pure Python. >> 2. There are a bunch of special cases in the ufunc code for handling >> strings and record arrays; we should make the appropriate extensions >> to the dtype API so that they can become regular dtypes. >> 3. A proper categorical data dtype. (This is trivial once the above is >> done.) >> 4. NA dtypes >> >> ------------------------------ >> > > > Added those. Maybe one of the Trac admins can fix your edit rights. > I'm having problems logging in also. I have an account in my name, but the password may have been changed along the line and apparently my email account also. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From wcardoen at gmail.com Wed Apr 3 11:00:54 2013 From: wcardoen at gmail.com (Wim R. Cardoen) Date: Wed, 3 Apr 2013 09:00:54 -0600 Subject: [SciPy-Dev] SciPy 0.11.0 Failures in scipy.test() Message-ID: Hello, This morning I installed numpy 1.7.0 and ran its test suite successfully. After installing scipy 0.11.0 I ran the scipy test suite and obtained a bunch of failures. (see below #2). I compiled the source code on the a RHEL6 box using gfortran (GNU Fortran (GCC) 4.4.6) as well as gcc (gcc (GCC) 4.4.6) I used the OS's blas and lapack library and compiled suitesparse myself. Do you have any idea how can I resolve these failures? Thanks, Wim #1: Configuration to compile scipy 0.11.0 ------------------------------------------------------------------------------------------------------------------------------------ import scipy >>> scipy.show_config() blas_info: libraries = ['blas', 'lapack'] library_dirs = ['/usr/lib64'] language = f77 amd_info: libraries = ['amd'] library_dirs = ['/uufs/chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib '] define_macros = [('SCIPY_AMD_H', None)] swig_opts = ['-I/uufs/ chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] include_dirs = ['/uufs/ chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] lapack_info: libraries = ['lapack', 'lapack'] library_dirs = ['/usr/lib64'] language = f77 atlas_threads_info: NOT AVAILABLE blas_opt_info: libraries = ['blas', 'lapack', 'lapack'] library_dirs = ['/usr/lib64'] language = f77 define_macros = [('NO_ATLAS_INFO', 1)] atlas_blas_threads_info: NOT AVAILABLE umfpack_info: libraries = ['umfpack', 'amd'] library_dirs = ['/uufs/chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib '] define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] swig_opts = ['-I/uufs/ chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include', '-I/uufs/ chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] include_dirs = ['/uufs/ chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] lapack_opt_info: libraries = ['lapack', 'lapack', 'blas', 'lapack', 'lapack'] library_dirs = ['/usr/lib64'] language = f77 define_macros = [('NO_ATLAS_INFO', 1)] atlas_info: NOT AVAILABLE lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE atlas_blas_info: NOT AVAILABLE mkl_info: NOT AVAILABLE -------------------------------------------------------------------------------------------------------------------------------------- #2: Failures after executing the command import scipy scipy.test() ------------------------------ ------------------------------------------------------------------------------------------------------------- ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'normal') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.00178814, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, OPpart=None, mode=normal (mismatch 100.0%) x: array([[ 2.38156418e-01, -6.75444982e+09], [ -1.07853470e-01, -8.01245676e+09], [ 1.24683023e-01, -5.19757686e+09],... y: array([[ 2.38156418e-01, -5.70949789e+08], [ -1.07853470e-01, -4.05829392e+08], [ 1.24683023e-01, 6.25800146e+07],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'buckling') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.00178814, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, OPpart=None, mode=buckling (mismatch 100.0%) x: array([[ 3.53755447e-01, -2.29114355e+04], [ -1.60204595e-01, -6.65625445e+04], [ 1.85203065e-01, -2.69012500e+04],... y: array([[ 3.53755447e-01, -8.88255444e+05], [ -1.60204595e-01, -2.39343354e+06], [ 1.85203065e-01, -3.96842525e+04],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'cayley') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.00178814, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, OPpart=None, mode=cayley (mismatch 100.0%) x: array([[ -2.38156418e-01, 1.04661597e+09], [ 1.07853470e-01, 1.39930271e+09], [ -1.24683023e-01, 9.56906461e+08],... y: array([[ -2.38156418e-01, 7.63721281e+07], [ 1.07853470e-01, 1.25169905e+08], [ -1.24683023e-01, 2.91283130e+07],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'normal') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000357628, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, OPpart=None, mode=normal (mismatch 100.0%) x: array([[ -2.38157020e-01, -9.38079485e+09], [ 1.07853829e-01, -1.09927593e+10], [ -1.24683096e-01, -7.26035649e+09],... y: array([[ -2.38157028e-01, -1.14406333e+09], [ 1.07853849e-01, -1.61444148e+09], [ -1.24683097e-01, -9.66750843e+08],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'buckling') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000357628, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, OPpart=None, mode=buckling (mismatch 100.0%) x: array([[ 3.53756177e-01, 3.54742236e+05], [ -1.60205036e-01, 9.37802669e+05], [ 1.85203150e-01, -6.91305082e+04],... y: array([[ 3.53756197e-01, 1.19154973e+07], [ -1.60205063e-01, 3.16087279e+07], [ 1.85203158e-01, -2.15500940e+06],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'LM', None, 0.5, , None, 'cayley') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.000357628, atol=0.000357628 error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, OPpart=None, mode=cayley (mismatch 100.0%) x: array([[ -2.38156244e-01, 3.27365597e+08], [ 1.07853608e-01, 4.31395993e+08], [ -1.24682902e-01, 2.93518385e+08],... y: array([[ -2.38156393e-01, 2.20001033e+07], [ 1.07853475e-01, 3.05206768e+07], [ -1.24683015e-01, 8.50334431e+06],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'SM', None, 0.5, , None, 'buckling') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.00178814, atol=0.000357628 error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, OPpart=None, mode=buckling (mismatch 100.0%) x: array([[ 3.32810915e-02, -1.39781114e+06], [ 8.83144107e-02, 6.75649002e+05], [ -5.86642416e-03, -6.19039713e+05],... y: array([[ 3.32810915e-02, -2.24275052e+05], [ 8.83144107e-02, 1.08299209e+05], [ -5.86642416e-03, -9.86191556e+04],... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, 'SM', None, 0.5, , None, 'cayley') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=0.00178814, atol=0.000357628 error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, OPpart=None, mode=cayley (mismatch 100.0%) x: array([[ 3.87506792e-03, 4.25513135e+07], [ 1.02828460e-02, -1.78393819e+07], [ -6.83054282e-04, -3.54143274e+07],... y: array([[ 3.87506792e-03, 2.90700178e+08], [ 1.02828460e-02, -1.18728352e+08], [ -6.83054282e-04, -2.87462041e+08],... ====================================================================== ....... ====================================================================== FAIL: test_arpack.test_symmetric_modes(True, , 'd', 2, 'SA', None, 0.5, , None, 'cayley') ---------------------------------------------------------------------- Traceback (most recent call last): File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", line 197, in runTest self.test(*self.arg) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", line 257, in eval_evec assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 1179, in assert_allclose verbose=verbose, header=header) File "/uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", line 645, in assert_array_compare raise AssertionError(msg) AssertionError: Not equal to tolerance rtol=4.44089e-13, atol=4.44089e-13 error for eigsh:general, typ=d, which=SA, sigma=0.5, mattype=asarray, OPpart=None, mode=cayley (mismatch 100.0%) x: array([[-0.36892684, -0.01935691], [-0.26850996, -0.11053158], [-0.40976156, -0.13223572],... y: array([[-0.43633077, -0.01935691], [-0.25161386, -0.11053158], [-0.36756684, -0.13223572],... ---------------------------------------------------------------------- Ran 5481 tests in 75.399s FAILED (KNOWNFAIL=15, SKIP=41, failures=63) Running unit tests for scipy NumPy version 1.7.0 NumPy is installed in /uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy SciPy version 0.11.0 SciPy is installed in /uufs/ chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy Python version 2.7.3 (default, Mar 28 2013, 15:20:19) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] nose version 1.1.2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Apr 3 12:40:34 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 3 Apr 2013 18:40:34 +0200 Subject: [SciPy-Dev] SciPy 0.11.0 Failures in scipy.test() In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 5:00 PM, Wim R. Cardoen wrote: > Hello, > > This morning I installed numpy 1.7.0 and ran its test suite successfully. > After installing scipy 0.11.0 I ran the scipy test suite and obtained a > bunch of failures. (see below #2). > > I compiled the source code on the a RHEL6 box using gfortran (GNU Fortran > (GCC) 4.4.6) > as well as gcc (gcc (GCC) 4.4.6) > I used the OS's blas and lapack library and compiled suitesparse myself. > Do you have any idea how can I resolve these failures? > These Arpack routines are an endless source of problems. They're sensitive to how BLAS/LAPACK was compiled and to 32/64-bit differences. Here's an open ticket with a link to a PR with more discussion: http://projects.scipy.org/scipy/ticket/1599 If you don't need the functionality, I'd say ignore it. If you do, you can try to find a new BLAS/LAPACK or try to actually understand the issue and fix it. Ralf > Thanks, > > Wim > > #1: Configuration to compile scipy 0.11.0 > > ------------------------------------------------------------------------------------------------------------------------------------ > import scipy > >>> scipy.show_config() > blas_info: > libraries = ['blas', 'lapack'] > library_dirs = ['/usr/lib64'] > language = f77 > amd_info: > libraries = ['amd'] > library_dirs = ['/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib'] > define_macros = [('SCIPY_AMD_H', None)] > swig_opts = ['-I/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] > include_dirs = ['/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] > lapack_info: > libraries = ['lapack', 'lapack'] > library_dirs = ['/usr/lib64'] > language = f77 > atlas_threads_info: > NOT AVAILABLE > blas_opt_info: > libraries = ['blas', 'lapack', 'lapack'] > library_dirs = ['/usr/lib64'] > language = f77 > define_macros = [('NO_ATLAS_INFO', 1)] > atlas_blas_threads_info: > NOT AVAILABLE > umfpack_info: > libraries = ['umfpack', 'amd'] > library_dirs = ['/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib'] > define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] > swig_opts = ['-I/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include', '-I/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] > include_dirs = ['/uufs/ > chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] > lapack_opt_info: > libraries = ['lapack', 'lapack', 'blas', 'lapack', 'lapack'] > library_dirs = ['/usr/lib64'] > language = f77 > define_macros = [('NO_ATLAS_INFO', 1)] > atlas_info: > NOT AVAILABLE > lapack_mkl_info: > NOT AVAILABLE > blas_mkl_info: > NOT AVAILABLE > atlas_blas_info: > NOT AVAILABLE > mkl_info: > NOT AVAILABLE > > -------------------------------------------------------------------------------------------------------------------------------------- > > > #2: Failures after executing the > command > import scipy > scipy.test() > > ------------------------------ > > ------------------------------------------------------------------------------------------------------------- > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'normal') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.00178814, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, > OPpart=None, mode=normal > (mismatch 100.0%) > x: array([[ 2.38156418e-01, -6.75444982e+09], > [ -1.07853470e-01, -8.01245676e+09], > [ 1.24683023e-01, -5.19757686e+09],... > y: array([[ 2.38156418e-01, -5.70949789e+08], > [ -1.07853470e-01, -4.05829392e+08], > [ 1.24683023e-01, 6.25800146e+07],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'buckling') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.00178814, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, > OPpart=None, mode=buckling > (mismatch 100.0%) > x: array([[ 3.53755447e-01, -2.29114355e+04], > [ -1.60204595e-01, -6.65625445e+04], > [ 1.85203065e-01, -2.69012500e+04],... > y: array([[ 3.53755447e-01, -8.88255444e+05], > [ -1.60204595e-01, -2.39343354e+06], > [ 1.85203065e-01, -3.96842525e+04],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'cayley') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.00178814, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, > OPpart=None, mode=cayley > (mismatch 100.0%) > x: array([[ -2.38156418e-01, 1.04661597e+09], > [ 1.07853470e-01, 1.39930271e+09], > [ -1.24683023e-01, 9.56906461e+08],... > y: array([[ -2.38156418e-01, 7.63721281e+07], > [ 1.07853470e-01, 1.25169905e+08], > [ -1.24683023e-01, 2.91283130e+07],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'normal') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.000357628, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, > OPpart=None, mode=normal > (mismatch 100.0%) > x: array([[ -2.38157020e-01, -9.38079485e+09], > [ 1.07853829e-01, -1.09927593e+10], > [ -1.24683096e-01, -7.26035649e+09],... > y: array([[ -2.38157028e-01, -1.14406333e+09], > [ 1.07853849e-01, -1.61444148e+09], > [ -1.24683097e-01, -9.66750843e+08],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'buckling') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.000357628, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, > OPpart=None, mode=buckling > (mismatch 100.0%) > x: array([[ 3.53756177e-01, 3.54742236e+05], > [ -1.60205036e-01, 9.37802669e+05], > [ 1.85203150e-01, -6.91305082e+04],... > y: array([[ 3.53756197e-01, 1.19154973e+07], > [ -1.60205063e-01, 3.16087279e+07], > [ 1.85203158e-01, -2.15500940e+06],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'LM', None, 0.5, , None, 'cayley') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.000357628, atol=0.000357628 > error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, > OPpart=None, mode=cayley > (mismatch 100.0%) > x: array([[ -2.38156244e-01, 3.27365597e+08], > [ 1.07853608e-01, 4.31395993e+08], > [ -1.24682902e-01, 2.93518385e+08],... > y: array([[ -2.38156393e-01, 2.20001033e+07], > [ 1.07853475e-01, 3.05206768e+07], > [ -1.24683015e-01, 8.50334431e+06],... > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'SM', None, 0.5, , None, 'buckling') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.00178814, atol=0.000357628 > error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, > OPpart=None, mode=buckling > (mismatch 100.0%) > x: array([[ 3.32810915e-02, -1.39781114e+06], > [ 8.83144107e-02, 6.75649002e+05], > [ -5.86642416e-03, -6.19039713e+05],... > y: array([[ 3.32810915e-02, -2.24275052e+05], > [ 8.83144107e-02, 1.08299209e+05], > [ -5.86642416e-03, -9.86191556e+04],... > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, > 'SM', None, 0.5, , None, 'cayley') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=0.00178814, atol=0.000357628 > error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, > OPpart=None, mode=cayley > (mismatch 100.0%) > x: array([[ 3.87506792e-03, 4.25513135e+07], > [ 1.02828460e-02, -1.78393819e+07], > [ -6.83054282e-04, -3.54143274e+07],... > y: array([[ 3.87506792e-03, 2.90700178e+08], > [ 1.02828460e-02, -1.18728352e+08], > [ -6.83054282e-04, -2.87462041e+08],... > > ====================================================================== > ....... > > > ====================================================================== > FAIL: test_arpack.test_symmetric_modes(True, , 'd', 2, > 'SA', None, 0.5, , None, 'cayley') > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", > line 257, in eval_evec > assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 1179, in assert_allclose > verbose=verbose, header=header) > File "/uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", > line 645, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Not equal to tolerance rtol=4.44089e-13, atol=4.44089e-13 > error for eigsh:general, typ=d, which=SA, sigma=0.5, mattype=asarray, > OPpart=None, mode=cayley > (mismatch 100.0%) > x: array([[-0.36892684, -0.01935691], > [-0.26850996, -0.11053158], > [-0.40976156, -0.13223572],... > y: array([[-0.43633077, -0.01935691], > [-0.25161386, -0.11053158], > [-0.36756684, -0.13223572],... > > ---------------------------------------------------------------------- > Ran 5481 tests in 75.399s > > FAILED (KNOWNFAIL=15, SKIP=41, failures=63) > Running unit tests for scipy > NumPy version 1.7.0 > NumPy is installed in /uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy > SciPy version 0.11.0 > SciPy is installed in /uufs/ > chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy > Python version 2.7.3 (default, Mar 28 2013, 15:20:19) [GCC 4.4.6 20120305 > (Red Hat 4.4.6-4)] > nose version 1.1.2 > > _______________________________________________ > 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 gadiyar at gmail.com Fri Apr 5 07:43:32 2013 From: gadiyar at gmail.com (Anand Gadiyar) Date: Fri, 5 Apr 2013 17:13:32 +0530 Subject: [SciPy-Dev] Import error while freezing with cxfreeze Message-ID: Hi all, I have a small program that uses numpy and scipy. I ran into a couple of errors while trying to use cxfreeze to create a windows executable. I'm running Windows 7 x64, Python 2.7.3 64-bit, Numpy 1.7.1rc1 64-bit, Scipy-0.11.0 64-bit, all binary installs from < http://www.lfd.uci.edu/~gohlke/pythonlibs/> I was able to replicate this with scipy-0.12.0c1 as well. 1) "from scipy import constants" triggers the below: Traceback (most recent call last): File "D:\Python27\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27, in exec_code in m.__dict__ File "mSimpleGui.py", line 10, in File "mSystem.py", line 7, in File "D:\Python27\lib\site-packages\scipy\__init__.py", line 64, in from numpy import show_config as show_numpy_config File "D:\Python27\lib\site-packages\numpy\__init__.py", line 165, in from core import * AttributeError: 'module' object has no attribute 'sys' 2) "from scipy import interpolate" triggers the below: Traceback (most recent call last): File "D:\Python27\lib\site-packages\cx_Freeze\initscripts\Console.py", line 27, in exec_code in m.__dict__ File "mSimpleGui.py", line 10, in File "mSystem.py", line 9, in File "mSensor.py", line 10, in File "D:\Python27\lib\site-packages\scipy\interpolate\__init__.py", line 154, in from rbf import Rbf File "D:\Python27\lib\site-packages\scipy\interpolate\rbf.py", line 50, in from scipy import linalg ImportError: cannot import name linalg I've attached a couple of small patches that fix these errors for me, but I'm not sure if these are the best way to fix. Could you please take a look? I'd be happy to test alternative fixes. Thanks in advance, Anand -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-import-sys-as-something-else-to-avoid-namespace-conf.patch Type: application/octet-stream Size: 1598 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-interpolate-import-only-the-required-function-to-avo.patch Type: application/octet-stream Size: 1700 bytes Desc: not available URL: From ralf.gommers at gmail.com Sat Apr 6 06:22:00 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 6 Apr 2013 12:22:00 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release candidate 1 In-Reply-To: References: Message-ID: On Sat, Mar 30, 2013 at 1:31 PM, Ralf Gommers wrote: > Hi, > > I am pleased to announce the availability of the first release candidate > of SciPy 0.12.0. This is shaping up to be another solid release, with > some cool new features (see highlights below) and a large amount of bug > fixes and maintenance work under the hood. The number of contributors also > keeps rising steadily, we're at 74 so far for this release. > > Sources and binaries can be found at > http://sourceforge.net/projects/scipy/files/scipy/0.12.0rc1/, release > notes are copied below. > > Please try this release and report any problems on the mailing list. If no > issues are found, the final release will be in one week. > Hi, I'm about to cut the final release but am not really sure about how heavily the beta and RC were tested. Normally there are always a few Windows-specific issues for example, this time nothing. A few "I tested this on platform X and it looks good" responses would reassure me. Thanks, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgohlke at uci.edu Sat Apr 6 06:35:47 2013 From: cgohlke at uci.edu (Christoph Gohlke) Date: Sat, 06 Apr 2013 03:35:47 -0700 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release candidate 1 In-Reply-To: References: Message-ID: <515FFA83.9060204@uci.edu> On 4/6/2013 3:22 AM, Ralf Gommers wrote: > > > > On Sat, Mar 30, 2013 at 1:31 PM, Ralf Gommers > wrote: > > Hi, > > I am pleased to announce the availability of the first release > candidate of SciPy 0.12.0. This is shaping up to be another solid > release, with some cool new features (see highlights below) and a > large amount of bug fixes and maintenance work under the hood. The > number of contributors also keeps rising steadily, we're at 74 so > far for this release. > > Sources and binaries can be found at > http://sourceforge.net/projects/scipy/files/scipy/0.12.0rc1/, > release notes are copied below. > > Please try this release and report any problems on the mailing list. > If no issues are found, the final release will be in one week. > > > Hi, I'm about to cut the final release but am not really sure about how > heavily the beta and RC were tested. Normally there are always a few > Windows-specific issues for example, this time nothing. A few "I tested > this on platform X and it looks good" responses would reassure me. > > Thanks, > Ralf > > Looks good. It builds and tests OK on Windows with msvc, numpy-MKL 1.7.1rc, Python 2.6 to 3.3, 32 and 64 bit. Occasionally/rarely test_singular fails but that is known (http://projects.scipy.org/scipy/ticket/1735). Christoph From ralf.gommers at gmail.com Sat Apr 6 06:39:52 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 6 Apr 2013 12:39:52 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release candidate 1 In-Reply-To: <515FFA83.9060204@uci.edu> References: <515FFA83.9060204@uci.edu> Message-ID: On Sat, Apr 6, 2013 at 12:35 PM, Christoph Gohlke wrote: > On 4/6/2013 3:22 AM, Ralf Gommers wrote: > > > > > > > > On Sat, Mar 30, 2013 at 1:31 PM, Ralf Gommers > > wrote: > > > > Hi, > > > > I am pleased to announce the availability of the first release > > candidate of SciPy 0.12.0. This is shaping up to be another solid > > release, with some cool new features (see highlights below) and a > > large amount of bug fixes and maintenance work under the hood. The > > number of contributors also keeps rising steadily, we're at 74 so > > far for this release. > > > > Sources and binaries can be found at > > http://sourceforge.net/projects/scipy/files/scipy/0.12.0rc1/, > > release notes are copied below. > > > > Please try this release and report any problems on the mailing list. > > If no issues are found, the final release will be in one week. > > > > > > Hi, I'm about to cut the final release but am not really sure about how > > heavily the beta and RC were tested. Normally there are always a few > > Windows-specific issues for example, this time nothing. A few "I tested > > this on platform X and it looks good" responses would reassure me. > > > > Thanks, > > Ralf > > > > > > Looks good. It builds and tests OK on Windows with msvc, numpy-MKL > 1.7.1rc, Python 2.6 to 3.3, 32 and 64 bit. > Thanks Christophe! Looks like we can finish up the release this weekend then. > > Occasionally/rarely test_singular fails but that is known > (http://projects.scipy.org/scipy/ticket/1735). > Good point, that should be then marked as knownfail for the release. I occasionally see that one on Linux as well. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From josef.pktd at gmail.com Sat Apr 6 14:07:51 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sat, 6 Apr 2013 14:07:51 -0400 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release candidate 1 In-Reply-To: References: <515FFA83.9060204@uci.edu> Message-ID: On Sat, Apr 6, 2013 at 6:39 AM, Ralf Gommers wrote: > > > > On Sat, Apr 6, 2013 at 12:35 PM, Christoph Gohlke wrote: >> >> On 4/6/2013 3:22 AM, Ralf Gommers wrote: >> > >> > >> > >> > On Sat, Mar 30, 2013 at 1:31 PM, Ralf Gommers > > > wrote: >> > >> > Hi, >> > >> > I am pleased to announce the availability of the first release >> > candidate of SciPy 0.12.0. This is shaping up to be another solid >> > release, with some cool new features (see highlights below) and a >> > large amount of bug fixes and maintenance work under the hood. The >> > number of contributors also keeps rising steadily, we're at 74 so >> > far for this release. >> > >> > Sources and binaries can be found at >> > http://sourceforge.net/projects/scipy/files/scipy/0.12.0rc1/, >> > release notes are copied below. >> > >> > Please try this release and report any problems on the mailing list. >> > If no issues are found, the final release will be in one week. >> > >> > >> > Hi, I'm about to cut the final release but am not really sure about how >> > heavily the beta and RC were tested. Normally there are always a few >> > Windows-specific issues for example, this time nothing. A few "I tested >> > this on platform X and it looks good" responses would reassure me. >> > >> > Thanks, >> > Ralf >> > >> > >> >> Looks good. It builds and tests OK on Windows with msvc, numpy-MKL >> 1.7.1rc, Python 2.6 to 3.3, 32 and 64 bit. > > > Thanks Christophe! Looks like we can finish up the release this weekend > then. >> >> >> Occasionally/rarely test_singular fails but that is known >> (http://projects.scipy.org/scipy/ticket/1735). > > > Good point, that should be then marked as knownfail for the release. I > occasionally see that one on Linux as well. I tried out the py 2.7, 32bit installer, and I don't see any errors or failures (besides singular). (statsmodels has only one failure related to fsolve, but that's for every version of scipy > 0.9. statsmodels also has one or two random failures in what should be deterministic tests, but they also happen every once in a while independent of scipy version.) Thanks, Josef > > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From ralf.gommers at gmail.com Sat Apr 6 16:15:58 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 6 Apr 2013 22:15:58 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release candidate 1 In-Reply-To: References: <515FFA83.9060204@uci.edu> Message-ID: On Sat, Apr 6, 2013 at 8:07 PM, wrote: > On Sat, Apr 6, 2013 at 6:39 AM, Ralf Gommers > wrote: > > > > > > > > On Sat, Apr 6, 2013 at 12:35 PM, Christoph Gohlke > wrote: > >> > >> On 4/6/2013 3:22 AM, Ralf Gommers wrote: > >> > > >> > > >> > > >> > On Sat, Mar 30, 2013 at 1:31 PM, Ralf Gommers >> > > wrote: > >> > > >> > Hi, > >> > > >> > I am pleased to announce the availability of the first release > >> > candidate of SciPy 0.12.0. This is shaping up to be another solid > >> > release, with some cool new features (see highlights below) and a > >> > large amount of bug fixes and maintenance work under the hood. The > >> > number of contributors also keeps rising steadily, we're at 74 so > >> > far for this release. > >> > > >> > Sources and binaries can be found at > >> > http://sourceforge.net/projects/scipy/files/scipy/0.12.0rc1/, > >> > release notes are copied below. > >> > > >> > Please try this release and report any problems on the mailing > list. > >> > If no issues are found, the final release will be in one week. > >> > > >> > > >> > Hi, I'm about to cut the final release but am not really sure about > how > >> > heavily the beta and RC were tested. Normally there are always a few > >> > Windows-specific issues for example, this time nothing. A few "I > tested > >> > this on platform X and it looks good" responses would reassure me. > >> > > >> > Thanks, > >> > Ralf > >> > > >> > > >> > >> Looks good. It builds and tests OK on Windows with msvc, numpy-MKL > >> 1.7.1rc, Python 2.6 to 3.3, 32 and 64 bit. > > > > > > Thanks Christophe! Looks like we can finish up the release this weekend > > then. > >> > >> > >> Occasionally/rarely test_singular fails but that is known > >> (http://projects.scipy.org/scipy/ticket/1735). > > > > > > Good point, that should be then marked as knownfail for the release. I > > occasionally see that one on Linux as well. > > I tried out the py 2.7, 32bit installer, and I don't see any errors or > failures (besides singular). > Thanks Josef. I created the release tag, announcement and binaries will follow. Ralf > > (statsmodels has only one failure related to fsolve, but that's for > every version of scipy > 0.9. > statsmodels also has one or two random failures in what should be > deterministic tests, but > they also happen every once in a while independent of scipy version.) > > Thanks, > > Josef > > > > > Ralf > > > > > > _______________________________________________ > > 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 ralf.gommers at gmail.com Sun Apr 7 16:09:07 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 7 Apr 2013 22:09:07 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release Message-ID: We are pleased to announce the availability of SciPy 0.12.0. This release has some cool new features (see highlights below) and a large amount of bug fixes and maintenance work under the hood. The number of contributors also keeps rising steadily - 75 people contributed patches to this release. We hope to see this trend continue. Some of the highlights of this release are: - Completed QHull wrappers in scipy.spatial. - cKDTree now a drop-in replacement for KDTree. - A new global optimizer, basinhopping. - Support for Python 2 and Python 3 from the same code base (no more 2to3). This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. Support for Python 2.4 and 2.5 has been dropped as of this release. Sources and binaries can be found at http://sourceforge.net/projects/scipy/files/scipy/0.12.0/, release notes are copied below. Enjoy, The SciPy developers ========================== SciPy 0.12.0 Release Notes ========================== SciPy 0.12.0 is the culmination of 7 months of hard work. It contains many 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.12.x branch, and on adding new features on the master branch. Some of the highlights of this release are: - Completed QHull wrappers in scipy.spatial. - cKDTree now a drop-in replacement for KDTree. - A new global optimizer, basinhopping. - Support for Python 2 and Python 3 from the same code base (no more 2to3). This release requires Python 2.6, 2.7 or 3.1-3.3 and NumPy 1.5.1 or greater. Support for Python 2.4 and 2.5 has been dropped as of this release. New features ============ ``scipy.spatial`` improvements ------------------------------ cKDTree feature-complete ^^^^^^^^^^^^^^^^^^^^^^^^ Cython version of KDTree, cKDTree, is now feature-complete. Most operations (construction, query, query_ball_point, query_pairs, count_neighbors and sparse_distance_matrix) are between 200 and 1000 times faster in cKDTree than in KDTree. With very minor caveats, cKDTree has exactly the same interface as KDTree, and can be used as a drop-in replacement. Voronoi diagrams and convex hulls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `scipy.spatial` now contains functionality for computing Voronoi diagrams and convex hulls using the Qhull library. (Delaunay triangulation was available since Scipy 0.9.0.) Delaunay improvements ^^^^^^^^^^^^^^^^^^^^^ It's now possible to pass in custom Qhull options in Delaunay triangulation. Coplanar points are now also recorded, if present. Incremental construction of Delaunay triangulations is now also possible. Spectral estimators (``scipy.signal``) -------------------------------------- The functions ``scipy.signal.periodogram`` and ``scipy.signal.welch`` were added, providing DFT-based spectral estimators. ``scipy.optimize`` improvements ------------------------------- Callback functions in L-BFGS-B and TNC ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A callback mechanism was added to L-BFGS-B and TNC minimization solvers. Basin hopping global optimization (``scipy.optimize.basinhopping``) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A new global optimization algorithm. Basinhopping is designed to efficiently find the global minimum of a smooth function. ``scipy.special`` improvements ------------------------------ Revised complex error functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The computation of special functions related to the error function now uses a new `Faddeeva library from MIT `__ which increases their numerical precision. The scaled and imaginary error functions ``erfcx`` and ``erfi`` were also added, and the Dawson integral ``dawsn`` can now be evaluated for a complex argument. Faster orthogonal polynomials ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Evaluation of orthogonal polynomials (the ``eval_*`` routines) in now faster in ``scipy.special``, and their ``out=`` argument functions properly. ``scipy.sparse.linalg`` features -------------------------------- - In ``scipy.sparse.linalg.spsolve``, the ``b`` argument can now be either a vector or a matrix. - ``scipy.sparse.linalg.inv`` was added. This uses ``spsolve`` to compute a sparse matrix inverse. - ``scipy.sparse.linalg.expm`` was added. This computes the exponential of a sparse matrix using a similar algorithm to the existing dense array implementation in ``scipy.linalg.expm``. Listing Matlab(R) file contents in ``scipy.io`` ----------------------------------------------- A new function ``whosmat`` is available in ``scipy.io`` for inspecting contents of MAT files without reading them to memory. Documented BLAS and LAPACK low-level interfaces (``scipy.linalg``) ------------------------------------------------------------------ The modules `scipy.linalg.blas` and `scipy.linalg.lapack` can be used to access low-level BLAS and LAPACK functions. Polynomial interpolation improvements (``scipy.interpolate``) ------------------------------------------------------------- The barycentric, Krogh, piecewise and pchip polynomial interpolators in ``scipy.interpolate`` accept now an ``axis`` argument. Deprecated features =================== `scipy.lib.lapack` ------------------ The module `scipy.lib.lapack` is deprecated. You can use `scipy.linalg.lapack` instead. The module `scipy.lib.blas` was deprecated earlier in Scipy 0.10.0. `fblas` and `cblas` ------------------- Accessing the modules `scipy.linalg.fblas`, `cblas`, `flapack`, `clapack` is deprecated. Instead, use the modules `scipy.linalg.lapack` and `scipy.linalg.blas`. Backwards incompatible changes ============================== Removal of ``scipy.io.save_as_module`` -------------------------------------- The function ``scipy.io.save_as_module`` was deprecated in Scipy 0.11.0, and is now removed. Its private support modules ``scipy.io.dumbdbm_patched`` and ``scipy.io.dumb_shelve`` are also removed. Other changes ============= Authors ======= * Anton Akhmerov + * Alexander Ebersp?cher + * Anne Archibald * Jisk Attema + * K.-Michael Aye + * bemasc + * Sebastian Berg + * Fran?ois Boulogne + * Matthew Brett * Lars Buitinck * Steven Byrnes + * Tim Cera + * Christian + * Keith Clawson + * David Cournapeau * Nathan Crock + * endolith * Bradley M. Froehle + * Matthew R Goodman * Christoph Gohlke * Ralf Gommers * Robert David Grant + * Yaroslav Halchenko * Charles Harris * Jonathan Helmus * Andreas Hilboll * Hugo + * Oleksandr Huziy * Jeroen Demeyer + * Johannes Sch?nberger + * Steven G. Johnson + * Chris Jordan-Squire * Jonathan Taylor + * Niklas Kroeger + * Jerome Kieffer + * kingson + * Josh Lawrence * Denis Laxalde * Alex Leach + * Tim Leslie * Richard Lindsley + * Lorenzo Luengo + * Stephen McQuay + * MinRK * Sturla Molden + * Eric Moore + * mszep + * Matt Newville + * Vlad Niculae * Travis Oliphant * David Parker + * Fabian Pedregosa * Josef Perktold * Zach Ploskey + * Alex Reinhart + * Gilles Rochefort + * Ciro Duran Santillli + * Jan Schlueter + * Jonathan Scholz + * Anthony Scopatz * Skipper Seabold * Fabrice Silva + * Scott Sinclair * Jacob Stevenson + * Sturla Molden + * Julian Taylor + * thorstenkranz + * John Travers + * True Price + * Nicky van Foreest * Jacob Vanderplas * Patrick Varilly * Daniel Velkov + * Pauli Virtanen * Stefan van der Walt * Warren Weckesser A total of 75 people contributed to this release. People with a "+" by their names contributed a patch for the first time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at hilboll.de Mon Apr 8 07:47:43 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Mon, 08 Apr 2013 13:47:43 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.12.0 release In-Reply-To: References: Message-ID: <5162AE5F.5090406@hilboll.de> > We are pleased to announce the availability of SciPy 0.12.0. This > release has some cool new features (see highlights below) and a large > amount of bug fixes and maintenance work under the hood. The number of > contributors also keeps rising steadily - 75 people contributed patches > to this release. We hope to see this trend continue. I just uploaded .deb Packages for Ubuntu 12.04LTS to ppa:pylab/stable I'm happy for any feedback regarding problems/errors/bugs/etc. Cheers, Andreas. From suryak at ieee.org Tue Apr 9 00:06:57 2013 From: suryak at ieee.org (Surya Kasturi) Date: Tue, 9 Apr 2013 09:36:57 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 Message-ID: Hi everyone, How about SciPy Central on GSoC 2013? I was thinking to participate in GSoC this year and thought of contributing to this project as GSoC student. Firstly, I was luck enough to find SPC which closely matched my interests. Since, I am already slightly familiar with the existing code, made some small contributions, I thought it would be very nice to continue my work as GSoC student during summer. Is it possible? Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorr.cecil at gmail.com Tue Apr 9 01:39:05 2013 From: lorr.cecil at gmail.com (Izzy Cecil) Date: Mon, 8 Apr 2013 23:39:05 -0600 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice Message-ID: Hey! I'm hoping to participate in the google summer of code this year. Specifically, improvements to scipy.sparse (as suggested by http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas). I'm an experienced coder, but have never really gotten my hands into a large open source project before (which is exactly why GSOC appeals to me). Scipy seems like a great fit for my interests! What's more, I have some experience in the mathematics of sparse matrix encodings. The plan is to have some small commits in sometime this week, to get the hang of things. I was wondering who would be appropriate to discus this project with, and if there were specific things I could do now to familiarize myself with the codebase. Any smaller bugs that could be fixed, or features that could be added to the library? Or should I consider a different project all together (perhaps Pythonic dtypes)? In the meantime, I'll hunt around trac, and mess with what I can, but any and all advice would be much appreciated! Thanks in advance! From ralf.gommers at gmail.com Tue Apr 9 02:20:25 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Tue, 9 Apr 2013 08:20:25 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: > Hi everyone, > > How about SciPy Central on GSoC 2013? > > I was thinking to participate in GSoC this year and thought of > contributing to this project as GSoC student. Firstly, I was luck enough to > find SPC which closely matched my interests. Since, I am already slightly > familiar with the existing code, made some small contributions, I thought > it would be very nice to continue my work as GSoC student during summer. > > Is it possible? > Hi Surya, it's definitely possible I think. And a good idea. Improving SciPy Central meets the requirements for a project set by Google and you've already met the requirement of submitting at least one patch before applying. I would encourage you to start working on a proposal, and discuss it on this list. Maybe you've seen this already, but just in case: http://wiki.python.org/moin/SummerOfCode/Application The other thing to do is find a mentor. We have several people that indicated that they'd like to be a mentor this year, maybe one of those people is interested in SPC? Or other people on the list? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Tue Apr 9 06:13:17 2013 From: suryak at ieee.org (Surya Kasturi) Date: Tue, 9 Apr 2013 15:43:17 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers wrote: > > > > On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: > >> Hi everyone, >> >> How about SciPy Central on GSoC 2013? >> >> I was thinking to participate in GSoC this year and thought of >> contributing to this project as GSoC student. Firstly, I was luck enough to >> find SPC which closely matched my interests. Since, I am already slightly >> familiar with the existing code, made some small contributions, I thought >> it would be very nice to continue my work as GSoC student during summer. >> >> Is it possible? >> > > Hi Surya, it's definitely possible I think. And a good idea. Improving > SciPy Central meets the requirements for a project set by Google and you've > already met the requirement of submitting at least one patch before > applying. > > Thanks I would encourage you to start working on a proposal, and discuss it on > this list. Maybe you've seen this already, but just in case: > http://wiki.python.org/moin/SummerOfCode/Application > > I have some ideas in mind. 1. Making SPC more dynamic. Lets say, we put the current functionality over a Content Management System (Django-CMS). We can create new pages, add new content dynamically (on fly), change page layout dynamically etc... Simply we can make the site like a extended version of blogger/ wordpress but not really a blog! This has been in my mind over long time -- just didn't find opportunity to express as I was working on new design and I was new to the code base and couldn't dare to challenge such a big enhancement directly without even knowing how existing code is! 2. Commenting system for submissions 3. Add points to submissions and reputation for users. 4. Improve search 5. API, Open Id (sign up), Feeds 6. Looking for other suggestions, ideas etc..even GSoC project proposal as a whole. Should I try to come up with a one big idea or some 4-5 small ideas (number depends on time frame, complexity etc)? Some of the above ideas are simple and don't really require total GSoC time (Open Id, Feeds) > The other thing to do is find a mentor. We have several people that > indicated that they'd like to be a mentor this year, maybe one of those > people is interested in SPC? Or other people on the list? > > >From the SPC repo, pv and andreas-h were having forked branches. They could possibly mentor me if interested! or maybe other people too Cheers, > Ralf > > > > _______________________________________________ > 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 denis at laxalde.org Wed Apr 10 03:34:48 2013 From: denis at laxalde.org (Denis Laxalde) Date: Wed, 10 Apr 2013 09:34:48 +0200 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice In-Reply-To: References: Message-ID: <51651618.2090103@laxalde.org> Hi, Izzy Cecil wrote: > I'm hoping to participate in the google summer of code this year. > Specifically, improvements to scipy.sparse (as suggested by > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas). I'm an > experienced coder, but have never really gotten my hands into a large > open source project before (which is exactly why GSOC appeals to me). > Scipy seems like a great fit for my interests! What's more, I have > some experience in the mathematics of sparse matrix encodings. The > plan is to have some small commits in sometime this week, to get the > hang of things. > > I was wondering who would be appropriate to discus this project with, I originally proposed the sparse subject so I guess I would be one of the contact point. Yet, I think this list is the proper channel for technical discussions. > and if there were specific things I could do now to familiarize myself > with the codebase. Any smaller bugs that could be fixed, or features > that could be added to the library? Or should I consider a different > project all together (perhaps Pythonic dtypes)? In the meantime, I'll > hunt around trac, and mess with what I can, but any and all advice > would be much appreciated! Nothing specific comes to mind now. Looking at trac is a good idea. Also look at numpy's tickets on github, there might be sparse related issues as well. You could also grep for TODO or XXX in the codebase as well. Good luck! -- Denis Laxalde From pav at iki.fi Wed Apr 10 04:10:59 2013 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 10 Apr 2013 08:10:59 +0000 (UTC) Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice References: Message-ID: Izzy Cecil gmail.com> writes: [clip] > I was wondering who would be appropriate to discus this project with, > and if there were specific things I could do now to familiarize myself > with the codebase. Any smaller bugs that could be fixed, or features > that could be added to the library? Or should I consider a different > project all together (perhaps Pythonic dtypes)? In the meantime, I'll > hunt around trac, and mess with what I can, but any and all advice > would be much appreciated! There's sort of a TODO list here, specified in terms of unit tests: https://github.com/scipy/scipy/blob/master/scipy/sparse/tests/test_base.py#L 1557 You notice that the CSR/CSC matrixes for instance do not have a full support for indexing, indexing for the DOK matrix type doesn't function as intended. So, fixing these is at least one project. Fixing these was begun here https://github.com/scipy/scipy/pull/425 which implemented a correct indexing mechanism for LIL matrices. However, this mechanism is not optimized for a specific matrix type (can be used as a fallback). It would be important here to not lose too much speed --- CSR and CSC have optimized fast paths for some cases. As a (part of a) GSoC project, the objective is reasonably well defined as the test suite exists. One additional thing could be to try to improve the speed of scipy.sparse, profiling common use cases and trying to optimize the most commonly encountered code paths. Then there are some additional possible things to do like integration of Expokit (matrix exponentials via Krylov methods). The dense matrix part of Expokit was done here and is almost ready: https://github.com/scipy/scipy/pull/354, the sparse (or, matrix-free) part hasn't been started but could be nice to have at the same time. Another possible question is better integration with Numpy in terms of making binary ops like np.multiply(A, B) and np.dot(A, B) overridable so that they can do the right thing for sparse matrices. This is however not so trivial as it requires some additions to Numpy. -- Pauli Virtanen From fbreitling at aip.de Wed Apr 10 05:07:41 2013 From: fbreitling at aip.de (Frank Breitling) Date: Wed, 10 Apr 2013 11:07:41 +0200 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: <51517E0A.5000804@aip.de> References: <510F8EF7.7010502@aip.de> <515173FF.4080708@aip.de> <51517E0A.5000804@aip.de> Message-ID: <51652BDD.30309@aip.de> Anybody? On 26.03.2013 11:52, Frank Breitling wrote: > A third problem is: "You are not allowed to delete attachments on this > page." > However I created the page and the attachment. I just want to > update it. Overwriting also fails. > > Frank > > > On 26.03.2013 11:10, Frank Breitling wrote: >> Thank you, I can create pages now. >> However, two issues remain: >> >> 1. I still get the following error message although the pages gets >> created (http://www.scipy.org/Cookbook/Histograms#preview): >> === >> Internal Server Error >> >> The server encountered an internal error or misconfiguration and was >> unable to complete your request. >> >> Please contact the server administrator, root at enthought.com and inform >> them of the time the error occurred, and anything you might have done >> that may have caused the error. >> >> More information about this error may be available in the server error log." >> === >> Maybe someone wants to fix this. >> >> >> 2. How can I move or delete a page? >> After creating http://www.scipy.org/Cookbook/Matplotlib/Histograms >> I realized that it would better fit into the Numpy section at >> http://www.scipy.org/Cookbook/Histograms . >> However, I didn't see a way how to move or delete the previous page. >> Can anybody tell me? >> >> >> Frank >> >> >> On 17.02.2013 01:23, Robert Kern wrote: >>> On Sat, Feb 16, 2013 at 9:07 PM, Ralf Gommers wrote: >>>> On Mon, Feb 4, 2013 at 11:35 AM, Frank Breitling wrote: >>>>> Hi, >>>>> >>>>> I have been trying to create a new page for the SciPy cookbook via >>>>> >>>>> http://www.scipy.org/Cookbook/Matplotlib/Histograms?action=edit >>>>> >>>>> but received the error below. >>>>> >>>>> Who can solve this? >>>> I'm running into the same issue. If it's one "kick the server" action away, >>>> it would be great if someone does that. Otherwise, hurrying up with the new >>>> scipy.org site may be effort better spent. >>> Please try again. As the spam pages accumulate, they eventually hit >>> the maximum number of files allowed in a directory. I have removed all >>> non-current page directories away. >>> >> _______________________________________________ >> 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 > From robert.kern at gmail.com Wed Apr 10 09:02:36 2013 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 10 Apr 2013 18:32:36 +0530 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: <51652BDD.30309@aip.de> References: <510F8EF7.7010502@aip.de> <515173FF.4080708@aip.de> <51517E0A.5000804@aip.de> <51652BDD.30309@aip.de> Message-ID: On Wed, Apr 10, 2013 at 2:37 PM, Frank Breitling wrote: > Anybody? > > On 26.03.2013 11:52, Frank Breitling wrote: >> A third problem is: "You are not allowed to delete attachments on this >> page." >> However I created the page and the attachment. I just want to >> update it. Overwriting also fails. I can try deleting that attachment if you are ready with a replacement. -- Robert Kern From fbreitling at aip.de Wed Apr 10 09:51:55 2013 From: fbreitling at aip.de (Frank Breitling) Date: Wed, 10 Apr 2013 15:51:55 +0200 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: References: <510F8EF7.7010502@aip.de> <515173FF.4080708@aip.de> <51517E0A.5000804@aip.de> <51652BDD.30309@aip.de> Message-ID: <51656E7B.4020305@aip.de> Hi Robert, I am ready with my replacement. If the web page problems are not so easy to repair could you please delete the following page and its attachment http://www.scipy.org/Cookbook/Matplotlib/Histograms as well as the attachment (but not the page) of http://www.scipy.org/Cookbook/Histograms ? Thanks in advance. Frank On 10.04.2013 15:02, Robert Kern wrote: > On Wed, Apr 10, 2013 at 2:37 PM, Frank Breitling wrote: >> Anybody? >> >> On 26.03.2013 11:52, Frank Breitling wrote: >>> A third problem is: "You are not allowed to delete attachments on this >>> page." >>> However I created the page and the attachment. I just want to >>> update it. Overwriting also fails. > I can try deleting that attachment if you are ready with a replacement. > > -- > Robert Kern > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From robert.kern at gmail.com Wed Apr 10 10:01:00 2013 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 10 Apr 2013 19:31:00 +0530 Subject: [SciPy-Dev] OSError with Cookbook In-Reply-To: <51656E7B.4020305@aip.de> References: <510F8EF7.7010502@aip.de> <515173FF.4080708@aip.de> <51517E0A.5000804@aip.de> <51652BDD.30309@aip.de> <51656E7B.4020305@aip.de> Message-ID: On Wed, Apr 10, 2013 at 7:21 PM, Frank Breitling wrote: > Hi Robert, > > I am ready with my replacement. > If the web page problems are not so easy to repair could you please > delete the following page and its attachment > > http://www.scipy.org/Cookbook/Matplotlib/Histograms > > as well as the attachment (but not the page) of > > http://www.scipy.org/Cookbook/Histograms ? Done and done. -- Robert Kern From wcardoen at gmail.com Wed Apr 10 11:37:28 2013 From: wcardoen at gmail.com (Wim R. Cardoen) Date: Wed, 10 Apr 2013 09:37:28 -0600 Subject: [SciPy-Dev] SciPy 0.11.0 Failures in scipy.test() In-Reply-To: References: Message-ID: Hello Ralf, Thanks you for your response. I compiled BLAS and LAPACK from source. This resolved the problem. In the coming days I plan to replace BLAS and LAPACK by OpenBLAS to speed up the code. Best regards, Wim On Wed, Apr 3, 2013 at 10:40 AM, Ralf Gommers wrote: > > > > On Wed, Apr 3, 2013 at 5:00 PM, Wim R. Cardoen wrote: > >> Hello, >> >> This morning I installed numpy 1.7.0 and ran its test suite successfully. >> After installing scipy 0.11.0 I ran the scipy test suite and obtained a >> bunch of failures. (see below #2). >> >> I compiled the source code on the a RHEL6 box using gfortran (GNU Fortran >> (GCC) 4.4.6) >> as well as gcc (gcc (GCC) 4.4.6) >> I used the OS's blas and lapack library and compiled suitesparse myself. >> Do you have any idea how can I resolve these failures? >> > > These Arpack routines are an endless source of problems. They're sensitive > to how BLAS/LAPACK was compiled and to 32/64-bit differences. Here's an > open ticket with a link to a PR with more discussion: > http://projects.scipy.org/scipy/ticket/1599 > > If you don't need the functionality, I'd say ignore it. If you do, you can > try to find a new BLAS/LAPACK or try to actually understand the issue and > fix it. > > Ralf > > > > >> Thanks, >> >> Wim >> >> #1: Configuration to compile scipy 0.11.0 >> >> ------------------------------------------------------------------------------------------------------------------------------------ >> import scipy >> >>> scipy.show_config() >> blas_info: >> libraries = ['blas', 'lapack'] >> library_dirs = ['/usr/lib64'] >> language = f77 >> amd_info: >> libraries = ['amd'] >> library_dirs = ['/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib'] >> define_macros = [('SCIPY_AMD_H', None)] >> swig_opts = ['-I/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] >> include_dirs = ['/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] >> lapack_info: >> libraries = ['lapack', 'lapack'] >> library_dirs = ['/usr/lib64'] >> language = f77 >> atlas_threads_info: >> NOT AVAILABLE >> blas_opt_info: >> libraries = ['blas', 'lapack', 'lapack'] >> library_dirs = ['/usr/lib64'] >> language = f77 >> define_macros = [('NO_ATLAS_INFO', 1)] >> atlas_blas_threads_info: >> NOT AVAILABLE >> umfpack_info: >> libraries = ['umfpack', 'amd'] >> library_dirs = ['/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/lib'] >> define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)] >> swig_opts = ['-I/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include', '-I/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] >> include_dirs = ['/uufs/ >> chpc.utah.edu/sys/pkg/suitesparse/4.0.2_rhel6/include'] >> lapack_opt_info: >> libraries = ['lapack', 'lapack', 'blas', 'lapack', 'lapack'] >> library_dirs = ['/usr/lib64'] >> language = f77 >> define_macros = [('NO_ATLAS_INFO', 1)] >> atlas_info: >> NOT AVAILABLE >> lapack_mkl_info: >> NOT AVAILABLE >> blas_mkl_info: >> NOT AVAILABLE >> atlas_blas_info: >> NOT AVAILABLE >> mkl_info: >> NOT AVAILABLE >> >> -------------------------------------------------------------------------------------------------------------------------------------- >> >> >> #2: Failures after executing the >> command >> import scipy >> scipy.test() >> >> ------------------------------ >> >> ------------------------------------------------------------------------------------------------------------- >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'normal') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.00178814, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, >> OPpart=None, mode=normal >> (mismatch 100.0%) >> x: array([[ 2.38156418e-01, -6.75444982e+09], >> [ -1.07853470e-01, -8.01245676e+09], >> [ 1.24683023e-01, -5.19757686e+09],... >> y: array([[ 2.38156418e-01, -5.70949789e+08], >> [ -1.07853470e-01, -4.05829392e+08], >> [ 1.24683023e-01, 6.25800146e+07],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'buckling') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.00178814, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, >> OPpart=None, mode=buckling >> (mismatch 100.0%) >> x: array([[ 3.53755447e-01, -2.29114355e+04], >> [ -1.60204595e-01, -6.65625445e+04], >> [ 1.85203065e-01, -2.69012500e+04],... >> y: array([[ 3.53755447e-01, -8.88255444e+05], >> [ -1.60204595e-01, -2.39343354e+06], >> [ 1.85203065e-01, -3.96842525e+04],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'cayley') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.00178814, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=csr_matrix, >> OPpart=None, mode=cayley >> (mismatch 100.0%) >> x: array([[ -2.38156418e-01, 1.04661597e+09], >> [ 1.07853470e-01, 1.39930271e+09], >> [ -1.24683023e-01, 9.56906461e+08],... >> y: array([[ -2.38156418e-01, 7.63721281e+07], >> [ 1.07853470e-01, 1.25169905e+08], >> [ -1.24683023e-01, 2.91283130e+07],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'normal') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.000357628, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, >> OPpart=None, mode=normal >> (mismatch 100.0%) >> x: array([[ -2.38157020e-01, -9.38079485e+09], >> [ 1.07853829e-01, -1.09927593e+10], >> [ -1.24683096e-01, -7.26035649e+09],... >> y: array([[ -2.38157028e-01, -1.14406333e+09], >> [ 1.07853849e-01, -1.61444148e+09], >> [ -1.24683097e-01, -9.66750843e+08],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'buckling') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.000357628, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, >> OPpart=None, mode=buckling >> (mismatch 100.0%) >> x: array([[ 3.53756177e-01, 3.54742236e+05], >> [ -1.60205036e-01, 9.37802669e+05], >> [ 1.85203150e-01, -6.91305082e+04],... >> y: array([[ 3.53756197e-01, 1.19154973e+07], >> [ -1.60205063e-01, 3.16087279e+07], >> [ 1.85203158e-01, -2.15500940e+06],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'LM', None, 0.5, , None, 'cayley') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.000357628, atol=0.000357628 >> error for eigsh:standard, typ=f, which=LM, sigma=0.5, mattype=asarray, >> OPpart=None, mode=cayley >> (mismatch 100.0%) >> x: array([[ -2.38156244e-01, 3.27365597e+08], >> [ 1.07853608e-01, 4.31395993e+08], >> [ -1.24682902e-01, 2.93518385e+08],... >> y: array([[ -2.38156393e-01, 2.20001033e+07], >> [ 1.07853475e-01, 3.05206768e+07], >> [ -1.24683015e-01, 8.50334431e+06],... >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'SM', None, 0.5, , None, 'buckling') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.00178814, atol=0.000357628 >> error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, >> OPpart=None, mode=buckling >> (mismatch 100.0%) >> x: array([[ 3.32810915e-02, -1.39781114e+06], >> [ 8.83144107e-02, 6.75649002e+05], >> [ -5.86642416e-03, -6.19039713e+05],... >> y: array([[ 3.32810915e-02, -2.24275052e+05], >> [ 8.83144107e-02, 1.08299209e+05], >> [ -5.86642416e-03, -9.86191556e+04],... >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'f', 2, >> 'SM', None, 0.5, , None, 'cayley') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=0.00178814, atol=0.000357628 >> error for eigsh:standard, typ=f, which=SM, sigma=0.5, mattype=csr_matrix, >> OPpart=None, mode=cayley >> (mismatch 100.0%) >> x: array([[ 3.87506792e-03, 4.25513135e+07], >> [ 1.02828460e-02, -1.78393819e+07], >> [ -6.83054282e-04, -3.54143274e+07],... >> y: array([[ 3.87506792e-03, 2.90700178e+08], >> [ 1.02828460e-02, -1.18728352e+08], >> [ -6.83054282e-04, -2.87462041e+08],... >> >> ====================================================================== >> ....... >> >> >> ====================================================================== >> FAIL: test_arpack.test_symmetric_modes(True, , 'd', 2, >> 'SA', None, 0.5, , None, 'cayley') >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/nose-1.1.2-py2.7.egg/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy/sparse/linalg/eigen/arpack/tests/test_arpack.py", >> line 257, in eval_evec >> assert_allclose(LHS, RHS, rtol=rtol, atol=atol, err_msg=err) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 1179, in assert_allclose >> verbose=verbose, header=header) >> File "/uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy/testing/utils.py", >> line 645, in assert_array_compare >> raise AssertionError(msg) >> AssertionError: >> Not equal to tolerance rtol=4.44089e-13, atol=4.44089e-13 >> error for eigsh:general, typ=d, which=SA, sigma=0.5, mattype=asarray, >> OPpart=None, mode=cayley >> (mismatch 100.0%) >> x: array([[-0.36892684, -0.01935691], >> [-0.26850996, -0.11053158], >> [-0.40976156, -0.13223572],... >> y: array([[-0.43633077, -0.01935691], >> [-0.25161386, -0.11053158], >> [-0.36756684, -0.13223572],... >> >> ---------------------------------------------------------------------- >> Ran 5481 tests in 75.399s >> >> FAILED (KNOWNFAIL=15, SKIP=41, failures=63) >> Running unit tests for scipy >> NumPy version 1.7.0 >> NumPy is installed in /uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/numpy >> SciPy version 0.11.0 >> SciPy is installed in /uufs/ >> chpc.utah.edu/sys/pkg/python/2.7.3_rhel6/lib/python2.7/site-packages/scipy >> Python version 2.7.3 (default, Mar 28 2013, 15:20:19) [GCC 4.4.6 20120305 >> (Red Hat 4.4.6-4)] >> nose version 1.1.2 >> >> _______________________________________________ >> 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 suryak at ieee.org Wed Apr 10 12:56:52 2013 From: suryak at ieee.org (Surya Kasturi) Date: Wed, 10 Apr 2013 22:26:52 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 3:43 PM, Surya Kasturi wrote: > > > > On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >> >>> Hi everyone, >>> >>> How about SciPy Central on GSoC 2013? >>> >>> I was thinking to participate in GSoC this year and thought of >>> contributing to this project as GSoC student. Firstly, I was luck enough to >>> find SPC which closely matched my interests. Since, I am already slightly >>> familiar with the existing code, made some small contributions, I thought >>> it would be very nice to continue my work as GSoC student during summer. >>> >>> Is it possible? >>> >> >> Hi Surya, it's definitely possible I think. And a good idea. Improving >> SciPy Central meets the requirements for a project set by Google and you've >> already met the requirement of submitting at least one patch before >> applying. >> >> > Thanks > > I would encourage you to start working on a proposal, and discuss it on >> this list. Maybe you've seen this already, but just in case: >> http://wiki.python.org/moin/SummerOfCode/Application >> >> I have some ideas in mind. > > 1. Making SPC more dynamic. Lets say, we put the > current functionality over a Content Management System (Django-CMS). We can > create new pages, add new content dynamically (on fly), change page layout > dynamically etc... Simply we can make the site like a extended version of > blogger/ wordpress but not really a blog! > > This has been in my mind over long time -- just didn't find opportunity to > express as I was working on new design and I was new to the code base and > couldn't dare to challenge such a big enhancement directly without even > knowing how existing code is! > > 2. Commenting system for submissions > 3. Add points to submissions and reputation for users. > 4. Improve search > 5. API, Open Id (sign up), Feeds > > 6. Looking for other suggestions, ideas etc..even GSoC project proposal as > a whole. > > Should I try to come up with a one big idea or some 4-5 small ideas > (number depends on time frame, complexity etc)? Some of the above ideas are > simple and don't really require total GSoC time (Open Id, Feeds) > > >> The other thing to do is find a mentor. We have several people that >> indicated that they'd like to be a mentor this year, maybe one of those >> people is interested in SPC? Or other people on the list? >> >> > From the SPC repo, pv and andreas-h were having forked branches. They > could possibly mentor me if interested! or maybe other people too > > Cheers, >> Ralf >> >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > Any updates? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Apr 10 13:46:46 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 10 Apr 2013 19:46:46 +0200 Subject: [SciPy-Dev] SciPy 0.11.0 Failures in scipy.test() In-Reply-To: References: Message-ID: On Wed, Apr 10, 2013 at 5:37 PM, Wim R. Cardoen wrote: > Hello Ralf, > > Thanks you for your response. > I compiled BLAS and LAPACK from source. This resolved the problem. > Great. Thanks for letting us know what the source of your issue was. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at hilboll.de Wed Apr 10 14:28:01 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Wed, 10 Apr 2013 20:28:01 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: <5165AF31.10000@hilboll.de> Am 10.04.2013 18:56, schrieb Surya Kasturi: > > > > On Tue, Apr 9, 2013 at 3:43 PM, Surya Kasturi > wrote: > > > > > On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers > > wrote: > > > > > On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi > wrote: > > Hi everyone, > > How about SciPy Central on GSoC 2013? > > I was thinking to participate in GSoC this year and thought > of contributing to this project as GSoC student. Firstly, I > was luck enough to find SPC which closely matched my > interests. Since, I am already slightly familiar with the > existing code, made some small contributions, I thought it > would be very nice to continue my work as GSoC student > during summer. > > Is it possible? > > > Hi Surya, it's definitely possible I think. And a good idea. > Improving SciPy Central meets the requirements for a project set > by Google and you've already met the requirement of submitting > at least one patch before applying. > > > Thanks > > I would encourage you to start working on a proposal, and > discuss it on this list. Maybe you've seen this already, but > just in case: http://wiki.python.org/moin/SummerOfCode/Application > > I have some ideas in mind. > > 1. Making SPC more dynamic. Lets say, we put the > current functionality over a Content Management System (Django-CMS). > We can create new pages, add new content dynamically (on fly), > change page layout dynamically etc... Simply we can make the site > like a extended version of blogger/ wordpress but not really a blog! > > This has been in my mind over long time -- just didn't find > opportunity to express as I was working on new design and I was new > to the code base and couldn't dare to challenge such a big > enhancement directly without even knowing how existing code is! > > 2. Commenting system for submissions > 3. Add points to submissions and reputation for users. > 4. Improve search > 5. API, Open Id (sign up), Feeds > > 6. Looking for other suggestions, ideas etc..even GSoC project > proposal as a whole. > > Should I try to come up with a one big idea or some 4-5 small ideas > (number depends on time frame, complexity etc)? Some of the above > ideas are simple and don't really require total GSoC time (Open Id, > Feeds) > > > The other thing to do is find a mentor. We have several people > that indicated that they'd like to be a mentor this year, maybe > one of those people is interested in SPC? Or other people on the > list? > > > From the SPC repo, pv and andreas-h were having forked branches. > They could possibly mentor me if interested! or maybe other people too > > Cheers, > Ralf > > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > Any updates? Hi Surya, I forked the SPC repo at some point because I wanted to play around. I have a good idea of what SPC might look like. However, I'm not really very much into django, so I'm not sure how suitable I would be as a mentor. What's a mentor supposed to do? What's his/her role? Requirements? Cheers, Andreas. From ralf.gommers at gmail.com Wed Apr 10 14:31:47 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 10 Apr 2013 20:31:47 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 12:13 PM, Surya Kasturi wrote: > > > > On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >> >>> Hi everyone, >>> >>> How about SciPy Central on GSoC 2013? >>> >>> I was thinking to participate in GSoC this year and thought of >>> contributing to this project as GSoC student. Firstly, I was luck enough to >>> find SPC which closely matched my interests. Since, I am already slightly >>> familiar with the existing code, made some small contributions, I thought >>> it would be very nice to continue my work as GSoC student during summer. >>> >>> Is it possible? >>> >> >> Hi Surya, it's definitely possible I think. And a good idea. Improving >> SciPy Central meets the requirements for a project set by Google and you've >> already met the requirement of submitting at least one patch before >> applying. >> >> > Thanks > > I would encourage you to start working on a proposal, and discuss it on >> this list. Maybe you've seen this already, but just in case: >> http://wiki.python.org/moin/SummerOfCode/Application >> >> I have some ideas in mind. > > 1. Making SPC more dynamic. Lets say, we put the > current functionality over a Content Management System (Django-CMS). We can > create new pages, add new content dynamically (on fly), change page layout > dynamically etc... Simply we can make the site like a extended version of > blogger/ wordpress but not really a blog! > Dynamic sounds good, but I have trouble picturing what added functionality that will bring. Probably due to me not knowing much about Django. Is it mostly for admins to create new features and do design changes quicker, or are you allowing users to do new things? > > This has been in my mind over long time -- just didn't find opportunity to > express as I was working on new design and I was new to the code base and > couldn't dare to challenge such a big enhancement directly without even > knowing how existing code is! > You have >3 months full time, so being ambitious (but realistic) is good:) > 2. Commenting system for submissions > 3. Add points to submissions and reputation for users. > 4. Improve search > 5. API, Open Id (sign up), Feeds > These all look useful. > > 6. Looking for other suggestions, ideas etc..even GSoC project proposal as > a whole. > What about version control and sharing of the code snippets? I see there's now hg support only but the infrastructure is prepared to add git (and other dvcs's). Also submitting gists somehow and making improvements of existing snippets as easy as possible could be interesting. > Should I try to come up with a one big idea or some 4-5 small ideas > (number depends on time frame, complexity etc)? Some of the above ideas are > simple and don't really require total GSoC time (Open Id, Feeds) > Either one major idea or several smaller related ones are OK. However keep in mind that even if you have just one feature/delivery, you should make a project plan that has intermediate milestones. This is for several reasons - it helps you feel you're making progress, your mentor and the community can see that things are moving forward as planned, it helps with the formal evaluation halfway through GSoC, etc. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Apr 10 14:46:17 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 10 Apr 2013 20:46:17 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <5165AF31.10000@hilboll.de> References: <5165AF31.10000@hilboll.de> Message-ID: On Wed, Apr 10, 2013 at 8:28 PM, Andreas Hilboll wrote: > Am 10.04.2013 18:56, schrieb Surya Kasturi: > > > > On Tue, Apr 9, 2013 at 3:43 PM, Surya Kasturi > > wrote: > > > > On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers > > > wrote: > > > > The other thing to do is find a mentor. We have several people > > that indicated that they'd like to be a mentor this year, maybe > > one of those people is interested in SPC? Or other people on the > > list? > > > > > > From the SPC repo, pv and andreas-h were having forked branches. > > They could possibly mentor me if interested! or maybe other people > too > > > > > > > > Any updates? > > Hi Surya, > > I forked the SPC repo at some point because I wanted to play around. I > have a good idea of what SPC might look like. However, I'm not really > very much into django, so I'm not sure how suitable I would be as a mentor. > > What's a mentor supposed to do? What's his/her role? Requirements? > Hey Andreas, the role of a mentor is to help and supervise a student with his project. There's a lot of material and advice available, so that may give a better answer than I can provide here. See for example http://www.booki.cc/gsoc-mentoring/what-makes-a-good-mentor/ and the other info under Mentoring on that page. It does require frequent contact with the student, and therefore a significant time commitment. To give you an idea, when I mentored for statsmodels last year I had a one-hour Skype call every weekend and email contact much more frequently with George. It would be great if you would be interested in mentoring or co-mentoring. Helping out with code review, design discussions etc. without being a mentor is of course also very helpful. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Apr 10 17:13:40 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 10 Apr 2013 23:13:40 +0200 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 7:39 AM, Izzy Cecil wrote: > Hey! > > I'm hoping to participate in the google summer of code this year. > Specifically, improvements to scipy.sparse (as suggested by > http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas). I'm an > experienced coder, but have never really gotten my hands into a large > open source project before (which is exactly why GSOC appeals to me). > Scipy seems like a great fit for my interests! What's more, I have > some experience in the mathematics of sparse matrix encodings. The > plan is to have some small commits in sometime this week, to get the > hang of things. > Hey Izzy, welcome! Pauli and Denis gave you some good pointers already about where to get started. Regarding the community aspects and what is expected of pull requests, you may want to read https://github.com/scipy/scipy/blob/master/HACKING.rst.txt Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Wed Apr 10 22:35:49 2013 From: suryak at ieee.org (Surya Kasturi) Date: Thu, 11 Apr 2013 08:05:49 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <5165AF31.10000@hilboll.de> References: <5165AF31.10000@hilboll.de> Message-ID: On Wed, Apr 10, 2013 at 11:58 PM, Andreas Hilboll wrote: > Am 10.04.2013 18:56, schrieb Surya Kasturi: > > > > > > > > On Tue, Apr 9, 2013 at 3:43 PM, Surya Kasturi > > wrote: > > > > > > > > > > On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers > > > wrote: > > > > > > > > > > On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi > > wrote: > > > > Hi everyone, > > > > How about SciPy Central on GSoC 2013? > > > > I was thinking to participate in GSoC this year and thought > > of contributing to this project as GSoC student. Firstly, I > > was luck enough to find SPC which closely matched my > > interests. Since, I am already slightly familiar with the > > existing code, made some small contributions, I thought it > > would be very nice to continue my work as GSoC student > > during summer. > > > > Is it possible? > > > > > > Hi Surya, it's definitely possible I think. And a good idea. > > Improving SciPy Central meets the requirements for a project set > > by Google and you've already met the requirement of submitting > > at least one patch before applying. > > > > > > Thanks > > > > I would encourage you to start working on a proposal, and > > discuss it on this list. Maybe you've seen this already, but > > just in case: > http://wiki.python.org/moin/SummerOfCode/Application > > > > I have some ideas in mind. > > > > 1. Making SPC more dynamic. Lets say, we put the > > current functionality over a Content Management System (Django-CMS). > > We can create new pages, add new content dynamically (on fly), > > change page layout dynamically etc... Simply we can make the site > > like a extended version of blogger/ wordpress but not really a blog! > > > > This has been in my mind over long time -- just didn't find > > opportunity to express as I was working on new design and I was new > > to the code base and couldn't dare to challenge such a big > > enhancement directly without even knowing how existing code is! > > > > 2. Commenting system for submissions > > 3. Add points to submissions and reputation for users. > > 4. Improve search > > 5. API, Open Id (sign up), Feeds > > > > 6. Looking for other suggestions, ideas etc..even GSoC project > > proposal as a whole. > > > > Should I try to come up with a one big idea or some 4-5 small ideas > > (number depends on time frame, complexity etc)? Some of the above > > ideas are simple and don't really require total GSoC time (Open Id, > > Feeds) > > > > > > The other thing to do is find a mentor. We have several people > > that indicated that they'd like to be a mentor this year, maybe > > one of those people is interested in SPC? Or other people on the > > list? > > > > > > From the SPC repo, pv and andreas-h were having forked branches. > > They could possibly mentor me if interested! or maybe other people > too > > > > Cheers, > > Ralf > > > > > > > > _______________________________________________ > > SciPy-Dev mailing list > > SciPy-Dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/scipy-dev > > > > > > > > Any updates? > > Hi Surya, > > I forked the SPC repo at some point because I wanted to play around. I > have a good idea of what SPC might look like. However, I'm not really > very much into django, so I'm not sure how suitable I would be as a mentor. > > What's a mentor supposed to do? What's his/her role? Requirements? > > https://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors http://en.flossmanuals.net/GSoCMentoring/what-makes-a-good-mentor/ These should give you some good idea (though I am not a mentor).. I guess there are lots of mentors who are at best to advise than me.. Cheers, Andreas. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Wed Apr 10 23:09:53 2013 From: suryak at ieee.org (Surya Kasturi) Date: Thu, 11 Apr 2013 08:39:53 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 12:01 AM, Ralf Gommers wrote: > > > > On Tue, Apr 9, 2013 at 12:13 PM, Surya Kasturi wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>> >>>> Hi everyone, >>>> >>>> How about SciPy Central on GSoC 2013? >>>> >>>> I was thinking to participate in GSoC this year and thought of >>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>> find SPC which closely matched my interests. Since, I am already slightly >>>> familiar with the existing code, made some small contributions, I thought >>>> it would be very nice to continue my work as GSoC student during summer. >>>> >>>> Is it possible? >>>> >>> >>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>> SciPy Central meets the requirements for a project set by Google and you've >>> already met the requirement of submitting at least one patch before >>> applying. >>> >>> >> Thanks >> >> I would encourage you to start working on a proposal, and discuss it on >>> this list. Maybe you've seen this already, but just in case: >>> http://wiki.python.org/moin/SummerOfCode/Application >>> >>> I have some ideas in mind. >> >> 1. Making SPC more dynamic. Lets say, we put the >> current functionality over a Content Management System (Django-CMS). We can >> create new pages, add new content dynamically (on fly), change page layout >> dynamically etc... Simply we can make the site like a extended version of >> blogger/ wordpress but not really a blog! >> > > Dynamic sounds good, but I have trouble picturing what added functionality > that will bring. Probably due to me not knowing much about Django. Is it > mostly for admins to create new features and do design changes quicker, or > are you allowing users to do new things? > Well, its mostly for admin guys. If achieved to a marginal level.. this is what we will achieve. 1. We can add static pages dynamically i.e., create pages on fly and add static content to it. uses: Suppose we want to create a page call "rules" to provide some rules to the users.. we don't have to edit the source code 2. Similarly, we can edit header, footer, right-side-bar etc.. add content to it, replace on fly 3. These two are my primary targets... may be we can achieve others too. >> This has been in my mind over long time -- just didn't find opportunity >> to express as I was working on new design and I was new to the code base >> and couldn't dare to challenge such a big enhancement directly without even >> knowing how existing code is! >> > > You have >3 months full time, so being ambitious (but realistic) is good:) > > Yeah :) > 2. Commenting system for submissions >> 3. Add points to submissions and reputation for users. >> 4. Improve search >> 5. API, Open Id (sign up), Feeds >> > > These all look useful. > Improving search -- is something I said vaguely. If I need to come up with specific feature.. May be we can add features like "search only snippets", "search only files" etc.. Please let me know if there are any other ideas too. >> 6. Looking for other suggestions, ideas etc..even GSoC project proposal >> as a whole. >> > > What about version control and sharing of the code snippets? I see there's > now hg support only but the infrastructure is prepared to add git (and > other dvcs's). Also submitting gists somehow and making improvements of > existing snippets as easy as possible could be interesting. > > Yeah, spc only supports Hg for now but do we really require another dvcs, git? adding the code as gists is an interesting idea. We can use Github API to do that when submitting.. 1. We can totally depend on Github Gists for source code.. as soon as someone submits snippets, we just create a gist and embed in the site. The problem here is that, we loose complete control over code. or 2. We can just give the gist as substitute to the existing functionality. >> Should I try to come up with a one big idea or some 4-5 small ideas >> (number depends on time frame, complexity etc)? Some of the above ideas are >> simple and don't really require total GSoC time (Open Id, Feeds) >> > > Either one major idea or several smaller related ones are OK. However keep > in mind that even if you have just one feature/delivery, you should make a > project plan that has intermediate milestones. This is for several reasons > - it helps you feel you're making progress, your mentor and the community > can see that things are moving forward as planned, it helps with the formal > evaluation halfway through GSoC, etc. > Okay. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > I guess mentor is a problem for spc... -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Wed Apr 10 23:14:14 2013 From: suryak at ieee.org (Surya Kasturi) Date: Thu, 11 Apr 2013 08:44:14 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 8:39 AM, Surya Kasturi wrote: > > > > On Thu, Apr 11, 2013 at 12:01 AM, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 12:13 PM, Surya Kasturi wrote: >> >>> >>> >>> >>> On Tue, Apr 9, 2013 at 11:50 AM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> How about SciPy Central on GSoC 2013? >>>>> >>>>> I was thinking to participate in GSoC this year and thought of >>>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>>> find SPC which closely matched my interests. Since, I am already slightly >>>>> familiar with the existing code, made some small contributions, I thought >>>>> it would be very nice to continue my work as GSoC student during summer. >>>>> >>>>> Is it possible? >>>>> >>>> >>>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>>> SciPy Central meets the requirements for a project set by Google and you've >>>> already met the requirement of submitting at least one patch before >>>> applying. >>>> >>>> >>> Thanks >>> >>> I would encourage you to start working on a proposal, and discuss it >>>> on this list. Maybe you've seen this already, but just in case: >>>> http://wiki.python.org/moin/SummerOfCode/Application >>>> >>>> I have some ideas in mind. >>> >>> 1. Making SPC more dynamic. Lets say, we put the >>> current functionality over a Content Management System (Django-CMS). We can >>> create new pages, add new content dynamically (on fly), change page layout >>> dynamically etc... Simply we can make the site like a extended version of >>> blogger/ wordpress but not really a blog! >>> >> >> Dynamic sounds good, but I have trouble picturing what added >> functionality that will bring. Probably due to me not knowing much about >> Django. Is it mostly for admins to create new features and do design >> changes quicker, or are you allowing users to do new things? >> > > Well, its mostly for admin guys. If achieved to a marginal level.. this is > what we will achieve. > > 1. We can add static pages dynamically i.e., create pages on fly and add > static content to it. > > uses: Suppose we want to create a page call "rules" to provide some rules > to the users.. we don't have to edit the source code > > > 2. Similarly, we can edit header, footer, right-side-bar etc.. add content > to it, replace on fly > > 3. These two are my primary targets... may be we can achieve others too. > > >>> This has been in my mind over long time -- just didn't find opportunity >>> to express as I was working on new design and I was new to the code base >>> and couldn't dare to challenge such a big enhancement directly without even >>> knowing how existing code is! >>> >> >> You have >3 months full time, so being ambitious (but realistic) is good:) >> >> > Yeah :) > > >> 2. Commenting system for submissions >>> 3. Add points to submissions and reputation for users. >>> 4. Improve search >>> 5. API, Open Id (sign up), Feeds >>> >> >> These all look useful. >> > > Improving search -- is something I said vaguely. If I need to come up > with specific feature.. May be we can add features like > "search only snippets", "search only files" etc.. > > Please let me know if there are any other ideas too. > > >>> 6. Looking for other suggestions, ideas etc..even GSoC project proposal >>> as a whole. >>> >> >> What about version control and sharing of the code snippets? I see >> there's now hg support only but the infrastructure is prepared to add git >> (and other dvcs's). Also submitting gists somehow and making improvements >> of existing snippets as easy as possible could be interesting. >> >> > Yeah, spc only supports Hg for now but do we really require another dvcs, > git? adding the code as gists is an interesting idea. We can use Github API > to do that when submitting.. > > 1. We can totally depend on Github Gists for source code.. as soon as > someone submits snippets, we just create a gist and embed in the site. The > problem here is that, we loose complete control over code. > > or > > 2. We can just give the gist as substitute to the existing functionality. > > >>> Should I try to come up with a one big idea or some 4-5 small ideas >>> (number depends on time frame, complexity etc)? Some of the above ideas are >>> simple and don't really require total GSoC time (Open Id, Feeds) >>> >> >> Either one major idea or several smaller related ones are OK. However >> keep in mind that even if you have just one feature/delivery, you should >> make a project plan that has intermediate milestones. This is for several >> reasons - it helps you feel you're making progress, your mentor and the >> community can see that things are moving forward as planned, it helps with >> the formal evaluation halfway through GSoC, etc. >> > > Okay. > >> >> Cheers, >> Ralf >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > I guess mentor is a problem for spc... > and I totally forgot. As far as I have seen the source code there isn't any caching mechanism on the server side. May be we can add "memcached" to the existing site.. this would improve the performance of the site a lot.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Fri Apr 12 04:13:12 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Fri, 12 Apr 2013 10:13:12 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: > > > > On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: > >> Hi everyone, >> >> How about SciPy Central on GSoC 2013? >> >> I was thinking to participate in GSoC this year and thought of >> contributing to this project as GSoC student. Firstly, I was luck enough to >> find SPC which closely matched my interests. Since, I am already slightly >> familiar with the existing code, made some small contributions, I thought >> it would be very nice to continue my work as GSoC student during summer. >> >> Is it possible? >> > > Hi Surya, it's definitely possible I think. And a good idea. Improving > SciPy Central meets the requirements for a project set by Google and you've > already met the requirement of submitting at least one patch before > applying. > > I would encourage you to start working on a proposal, and discuss it on > this list. Maybe you've seen this already, but just in case: > http://wiki.python.org/moin/SummerOfCode/Application > > The other thing to do is find a mentor. We have several people that > indicated that they'd like to be a mentor this year, maybe one of those > people is interested in SPC? Or other people on the list? > Hi, we do have a potential mentor for this project, Sebasti?n Ventura. Since he's not yet active in the Scipy community, I'll briefly introduce him. Sebastian is an experienced web developer, and has participated before in GSoC both as a student and a mentor. We came into contact via the PSF (our GSoC umbrella org), to which he had indicated that he was available as a mentor for Python GSoC projects. Once he has signed up for this mailing list - which may take a day or two because scipy.org is unresponsive right now - he'll join the discussion. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.daniel.br at gmail.com Fri Apr 12 10:36:59 2013 From: smith.daniel.br at gmail.com (Daniel Smith) Date: Fri, 12 Apr 2013 10:36:59 -0400 Subject: [SciPy-Dev] Sparse matrices Message-ID: Recently, I did some work expanding the LIL matrix class to support fancy indexing. I did some looking this morning into potentially expanding the other sparse matrix classes the same way. However, given that such things have been suggested for GSoC, I don't want to step on anyone's toes. I can move on to something else if that is recommended. Since most of that work ends up boiling down to element-wise operations. Pauli suggested that the LIL implementation could be added directly to the other classes. Looking through the CS* implementations, it looks like the fancier element wise methods used in the LIL fancy indexing could be appended to the end of __getitem__, etc. after the faster optimized methods. It might also make sense to integrate certain methods into the current setup so that things like CSC[0:1:2, 3] run quickly. Thanks, Daniel From orion at cora.nwra.com Fri Apr 12 18:59:34 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 12 Apr 2013 16:59:34 -0600 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release In-Reply-To: References: Message-ID: <516891D6.1050500@cora.nwra.com> On 04/07/2013 02:09 PM, Ralf Gommers wrote: > We are pleased to announce the availability of SciPy 0.12.0. I'm getting a segfault in the tests with python3 and numpy 1.7.1 and atlas 3.8.4: python3 -c 'import scipy; scipy.test("test_ticket_1645",2)' Running unit tests for scipy NumPy version 1.7.1 NumPy is installed in /usr/lib64/python3.3/site-packages/numpy SciPy version 0.12.0 SciPy is installed in /scratch/orion/redhat/BUILDROOT/scipy-0.12.0-1.fc20.x86_64/usr/lib64/python3.3/site-packages/scipy Python version 3.3.1 (default, Apr 10 2013, 12:41:18) [GCC 4.8.0 20130320 (Red Hat 4.8.0-0.18)] nose version 1.3.0 runTest (test_interpolate_wrapper.Test) ... ok vtest_ticket_1645 (test_lapack.TestRegression) ... Segmentation fault The segfault may be a python3 bug (http://bugs.python.org/issue17706) trying to handle a lapack error message. The lapack error is: "On entry to SGERQF parameter number 7 had an illegal value" Perhaps that is useful. http://www.scipy.org/BugReport seems to not point me anywhere useful. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From pav at iki.fi Fri Apr 12 19:10:38 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 13 Apr 2013 02:10:38 +0300 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release In-Reply-To: <516891D6.1050500@cora.nwra.com> References: <516891D6.1050500@cora.nwra.com> Message-ID: 13.04.2013 01:59, Orion Poplawski kirjoitti: [clip] > runTest (test_interpolate_wrapper.Test) ... ok > vtest_ticket_1645 (test_lapack.TestRegression) ... Segmentation fault > > The segfault may be a python3 bug (http://bugs.python.org/issue17706) trying > to handle a lapack error message. The lapack error is: > > "On entry to SGERQF parameter number 7 had an illegal value" > > Perhaps that is useful. Interesting. Can you try it on Python 3.3.0 --- that release is known to work. [clip] > http://www.scipy.org/BugReport seems to not point me anywhere useful. The page says explicitly this: -----8<----------- We make use of Trac to do project management. There, you can see what we are currently working on, as well as file bug-reports (known as tickets). Go to the relevant Trac page: - SciPy Developer Page [http://projects.scipy.org/scipy] - NumPy Developer Page Register your username (we require logins to prevent spam), by clicking on "register". You only need to do this once (i.e, SciPy and NumPy Developer Pages use the same login/password). Make sure the bug hasn't already been reported. Click on "Search". Then, type in some keywords, select "Tickets" and click "Search". File your bug-report by clicking "New Ticket" (this link is only available once you've logged in). -----8<----------- -- Pauli Virtanen From ralf.gommers at gmail.com Sat Apr 13 04:30:24 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Apr 2013 10:30:24 +0200 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release In-Reply-To: References: <516891D6.1050500@cora.nwra.com> Message-ID: On Sat, Apr 13, 2013 at 1:10 AM, Pauli Virtanen wrote: > 13.04.2013 01:59, Orion Poplawski kirjoitti: > > [clip] > > http://www.scipy.org/BugReport seems to not point me anywhere useful. > > The page says explicitly this: > No, the page indeed doesn't exist anymore. Maybe it fell victim to a recent spam cleanup. If you still have the old contents, can you paste them in again? Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Sat Apr 13 04:35:41 2013 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 13 Apr 2013 14:05:41 +0530 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release In-Reply-To: References: <516891D6.1050500@cora.nwra.com> Message-ID: On Sat, Apr 13, 2013 at 2:00 PM, Ralf Gommers wrote: > > On Sat, Apr 13, 2013 at 1:10 AM, Pauli Virtanen wrote: >> >> 13.04.2013 01:59, Orion Poplawski kirjoitti: >> >> [clip] >> > http://www.scipy.org/BugReport seems to not point me anywhere useful. >> >> The page says explicitly this: > > > No, the page indeed doesn't exist anymore. Maybe it fell victim to a recent > spam cleanup. If you still have the old contents, can you paste them in > again? Sorry about that. I have restored it. -- Robert Kern From ralf.gommers at gmail.com Sat Apr 13 05:35:25 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Apr 2013 11:35:25 +0200 Subject: [SciPy-Dev] commit rights for Eric Moore Message-ID: Hi all, Eric Moore has been a regular contributor to Scipy (and Numpy) in the past half year or so - he has for example added signal.periodogram/welch and improved the orthogonal poly support in scipy.special. Since those contributions were of high quality, I've asked him if he plans to continue contributing and is interested in obtaining commit rights for Scipy. To which his answer is yes/yes. So I propose to give him those rights. Do you all agree with that? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Sat Apr 13 05:57:59 2013 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 13 Apr 2013 15:27:59 +0530 Subject: [SciPy-Dev] commit rights for Eric Moore In-Reply-To: References: Message-ID: On Apr 13, 2013 3:05 PM, "Ralf Gommers" wrote: > > Hi all, > > Eric Moore has been a regular contributor to Scipy (and Numpy) in the past half year or so - he has for example added signal.periodogram/welch and improved the orthogonal poly support in scipy.special. Since those contributions were of high quality, I've asked him if he plans to continue contributing and is interested in obtaining commit rights for Scipy. To which his answer is yes/yes. So I propose to give him those rights. > > Do you all agree with that? +1! -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Sat Apr 13 09:03:34 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 13 Apr 2013 16:03:34 +0300 Subject: [SciPy-Dev] ANN: SciPy 0.12.0 release In-Reply-To: <516891D6.1050500@cora.nwra.com> References: <516891D6.1050500@cora.nwra.com> Message-ID: 13.04.2013 01:59, Orion Poplawski kirjoitti: [clip] > runTest (test_interpolate_wrapper.Test) ... ok > vtest_ticket_1645 (test_lapack.TestRegression) ... Segmentation fault > > The segfault may be a python3 bug (http://bugs.python.org/issue17706) trying > to handle a lapack error message. Thanks, I think there are two issues here: (i) Something is wrong with the LAPACK installation. What is the version of LAPACK that you have? (ii) The *QR routines are marked as `threadsafe` in flapack.pyf.src, which implies releasing the GIL. However, the XERBLA error handling code in python_xerbla.c inside Numpy assumes it has the GIL. (scipy.linalg doesn't have it's own python_xerbla.c, so it ends up looking for the symbol in numpy.linalg.lapack_lite --- rather unexpected!) > "On entry to SGERQF parameter number 7 had an illegal value" Parameter number 7 is LWORK. What is interesting here is that the wrapper to this routine ensures that LWORK >= M, as required by LAPACK documentation. Stepping through the execution of SGERQF in a debugger would reveal what is going wrong. [clip] > http://www.scipy.org/BugReport seems to not point me anywhere useful. 13.04.2013 11:30, Ralf Gommers kirjoitti: > No, the page indeed doesn't exist anymore. Maybe it fell victim to a > recent spam cleanup. Oops, that *is* true. Sorry for my tone in the previous mail... -- Pauli Virtanen From warren.weckesser at gmail.com Sat Apr 13 11:03:28 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sat, 13 Apr 2013 11:03:28 -0400 Subject: [SciPy-Dev] commit rights for Eric Moore In-Reply-To: References: Message-ID: On Sat, Apr 13, 2013 at 5:35 AM, Ralf Gommers wrote: > Hi all, > > Eric Moore has been a regular contributor to Scipy (and Numpy) in the past > half year or so - he has for example added signal.periodogram/welch and > improved the orthogonal poly support in scipy.special. Since those > contributions were of high quality, I've asked him if he plans to continue > contributing and is interested in obtaining commit rights for Scipy. To > which his answer is yes/yes. So I propose to give him those rights. > > Do you all agree with that? > Yes, +1. Warren > > Cheers, > Ralf > > > _______________________________________________ > 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 Sat Apr 13 16:38:51 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 13 Apr 2013 22:38:51 +0200 Subject: [SciPy-Dev] Sparse matrices In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 4:36 PM, Daniel Smith wrote: > Recently, I did some work expanding the LIL matrix class to support > fancy indexing. I did some looking this morning into potentially > expanding the other sparse matrix classes the same way. However, given > that such things have been suggested for GSoC, I don't want to step on > anyone's toes. I can move on to something else if that is recommended. > Hi Daniel, good question. I think that yes, a GSoC project focused on improving sparse matrices and interaction with numpy would be great. But I also think there's more than enough to do in scipy.sparse, certainly more than fits in a single GSoC project. So if Izzy or someone else successfully applies for that GSoC project, I don't see an issue in you working on this topic but an opportunity to move forward even faster. Furthermore GSoC doesn't start till 2 months from now, and the application process is competitive. And the reason this topic was suggested was because it's important. So by all means, go for it I'd say. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From eigenspaces at gmail.com Sat Apr 13 22:31:50 2013 From: eigenspaces at gmail.com (Patrick "Kai" Baker) Date: Sat, 13 Apr 2013 22:31:50 -0400 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.12.0 release In-Reply-To: <5162AE5F.5090406@hilboll.de> References: <5162AE5F.5090406@hilboll.de> Message-ID: > I just uploaded .deb Packages for Ubuntu 12.04LTS to > ppa:pylab/stable I just added that to my Linux Mint repository. What do I use with apt-get to install your package? On Mon, Apr 8, 2013 at 7:47 AM, Andreas Hilboll wrote: > > We are pleased to announce the availability of SciPy 0.12.0. This > > release has some cool new features (see highlights below) and a large > > amount of bug fixes and maintenance work under the hood. The number of > > contributors also keeps rising steadily - 75 people contributed patches > > to this release. We hope to see this trend continue. > > I just uploaded .deb Packages for Ubuntu 12.04LTS to > > ppa:pylab/stable > > I'm happy for any feedback regarding problems/errors/bugs/etc. > > Cheers, Andreas. > > _______________________________________________ > 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 lists at hilboll.de Sun Apr 14 05:13:53 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sun, 14 Apr 2013 11:13:53 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.12.0 release In-Reply-To: References: <5162AE5F.5090406@hilboll.de> Message-ID: <516A7351.7040403@hilboll.de> > > I just uploaded .deb Packages for Ubuntu 12.04LTS to > > > ppa:pylab/stable > > I just added that to my Linux Mint repository. What do I use with > apt-get to install your package? Hi Patrick, after the usual sudo apt-get update you can install the package with sudo apt-get install python-scipy or sudo apt-get install python3-scipy depending on which Python you're using. Cheers, A. From pav at iki.fi Sun Apr 14 07:19:31 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 14 Apr 2013 14:19:31 +0300 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice In-Reply-To: References: Message-ID: 10.04.2013 11:10, Pauli Virtanen kirjoitti: > Izzy Cecil gmail.com> writes: > [clip] >> I was wondering who would be appropriate to discus this project with, >> and if there were specific things I could do now to familiarize myself >> with the codebase. Any smaller bugs that could be fixed, or features >> that could be added to the library? Or should I consider a different >> project all together (perhaps Pythonic dtypes)? In the meantime, I'll >> hunt around trac, and mess with what I can, but any and all advice >> would be much appreciated! > > There's sort of a TODO list here, specified in terms of unit tests: > > https://github.com/scipy/scipy/blob/master/scipy/sparse/tests/test_base.py#L > 1557 [clip] And some more sparse ideas (requested by users): http://stackoverflow.com/search?tab=newest&q=[scipy]%20sparse - Implement max(axis=someaxis), mean(axis=someaxis), std(axis=someaxis), and other similar methods - Represent the LU factorization obtained via SuperLU as actual sparse matrices rather than in SuperLU's internal format. - Help with getting the support for 64-bit indices in, required for very large sparse matrices (this work is mostly done, see https://github.com/scipy/scipy/pull/442, but needs more testing and review) - Boolean operations - Fix the callback function situation with the scipy.sparse.linalg iterative solvers (different functions have different signatures) And probably many more. I think that even if there are two people working on improving the situation, there will be well enough to do for a GSoC. -- Pauli Virtanen From pav at iki.fi Sun Apr 14 07:41:12 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 14 Apr 2013 14:41:12 +0300 Subject: [SciPy-Dev] Adding an unformatted Fortran file reader to Scipy Message-ID: Hi, There's a PR adding an unformatted Fortran file reader to Scipy: https://github.com/scipy/scipy/pull/499 This looks good to us, and will probably be merged shortly. If you have experience with reading unformatted Fortran files, and something seems to be missing, now would be a good time to point out what should still be added. -- Pauli Virtanen From denis at laxalde.org Sun Apr 14 09:11:30 2013 From: denis at laxalde.org (Denis Laxalde) Date: Sun, 14 Apr 2013 15:11:30 +0200 Subject: [SciPy-Dev] commit rights for Eric Moore In-Reply-To: References: Message-ID: <516AAB02.3030209@laxalde.org> Ralf Gommers a ?crit : > Eric Moore has been a regular contributor to Scipy (and Numpy) in the > past half year or so - he has for example added signal.periodogram/welch > and improved the orthogonal poly support in scipy.special. Since those > contributions were of high quality, I've asked him if he plans to > continue contributing and is interested in obtaining commit rights for > Scipy. To which his answer is yes/yes. So I propose to give him those > rights. > > Do you all agree with that? Yes. From npkuin at gmail.com Mon Apr 15 06:18:43 2013 From: npkuin at gmail.com (Paul Kuin) Date: Mon, 15 Apr 2013 11:18:43 +0100 Subject: [SciPy-Dev] Adding an unformatted Fortran file reader to Scipy In-Reply-To: References: Message-ID: My recollection is, that the unformatted fortran files are machine specific, so cannot be moved to different architectures. I suppose that should be flagged somehow. Of course portability was the reason for developing HDF, CDF and FITS. A converter might be useful. The main reason for using unformatted data files is of course speed. For that reason just having a reader is kind of anomalous. I suppose someone might want to write an unformatted file for reading into a fortran program - which needs a writer. I guess this could be added when needed. Cheers, Paul On Sun, Apr 14, 2013 at 12:41 PM, Pauli Virtanen wrote: > Hi, > > There's a PR adding an unformatted Fortran file reader to Scipy: > > https://github.com/scipy/scipy/pull/499 > > This looks good to us, and will probably be merged shortly. > > If you have experience with reading unformatted Fortran files, and > something seems to be missing, now would be a good time to point out > what should still be added. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > -- * * * * * * * * http://www.mssl.ucl.ac.uk/~npmk/ * * * * Dr. N.P.M. Kuin (n.kuin at ucl.ac.uk) phone +44-(0)1483 (prefix) -204927 (work) -276110 (home) mobile +44(0)7806985366 skype ID: npkuin Mullard Space Science Laboratory ? University College London ? Holmbury St Mary ? Dorking ? Surrey RH5 6NT? U.K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at cerazone.net Mon Apr 15 09:12:33 2013 From: tim at cerazone.net (Cera, Tim) Date: Mon, 15 Apr 2013 09:12:33 -0400 Subject: [SciPy-Dev] Adding an unformatted Fortran file reader to Scipy In-Reply-To: References: Message-ID: > My recollection is, that the unformatted fortran files are machine > specific, so cannot be moved to different architectures. > The situation is even stranger than that. The 'unformatted' format is compiler specific. In fact, though this would be a silly thing for a compiler to do there is nothing to stop a change in between versions of the same compiler. Usually, though here also there is no guarantee, compilers that run on different machines will create the same 'unformatted' format. Of course there is always the little endian/big endian issue - but that is a problem with all FORTRAN binary files. Another reason to use one of the abstracted high-level formats like NetCDF, HDF,...etc. as pointed out by Paul. A programmer is expected to read and write 'unformatted' files with FORTRAN programs compiled with the same compiler on the same machine. We ran into this issue where we had an unchangeable Windows based analysis environment that was programmed to read an 'unformatted' file created using a Lahey FORTRAN compiled program on Windows, but we were creating the binary file with gfortran on Linux. A colleague rewrote the writing routines to recreate the Lahey 'unformatted' binary format, irregardless of compiler. Pain, but it allowed us to use our cluster for computation and the Windows analysis environment to read and process the data. Since then I have created a hand coded Python reader for the specific dataset mentioned above using Construct ( https://pypi.python.org/pypi/construct). I actually side-step the 'unformatted' format issue by using searches for particular strings. My application is hspfbintoolbox (https://pypi.python.org/pypi/hspfbintoolbox). So that is the reason that I probably will not use this since I have climbed this mountain, and don't expect to climb it again. On the other hand this PR could be useful to others, but they will have to speak up. As mentioned by Paul and in the discussion of the PR it should be clear in the documentation which compilers/platforms it works with. Kindest regards, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Apr 15 16:54:14 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 15 Apr 2013 22:54:14 +0200 Subject: [SciPy-Dev] commit rights for Eric Moore In-Reply-To: <516AAB02.3030209@laxalde.org> References: <516AAB02.3030209@laxalde.org> Message-ID: On Sun, Apr 14, 2013 at 3:11 PM, Denis Laxalde wrote: > Ralf Gommers a ?crit : > > > Eric Moore has been a regular contributor to Scipy (and Numpy) in the > > past half year or so - he has for example added signal.periodogram/welch > > and improved the orthogonal poly support in scipy.special. Since those > > contributions were of high quality, I've asked him if he plans to > > continue contributing and is interested in obtaining commit rights for > > Scipy. To which his answer is yes/yes. So I propose to give him those > > rights. > > > > Do you all agree with that? > > Yes. Great, done! Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Mon Apr 15 17:13:40 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 15 Apr 2013 15:13:40 -0600 Subject: [SciPy-Dev] SciPy 0.12.0/Numpy 1.7.1 sgerqf segfault In-Reply-To: References: <516891D6.1050500@cora.nwra.com> Message-ID: <516C6D84.3090102@cora.nwra.com> On 04/13/2013 07:03 AM, Pauli Virtanen wrote: > 13.04.2013 01:59, Orion Poplawski kirjoitti: > [clip] >> runTest (test_interpolate_wrapper.Test) ... ok >> vtest_ticket_1645 (test_lapack.TestRegression) ... Segmentation fault >> >> The segfault may be a python3 bug (http://bugs.python.org/issue17706) trying >> to handle a lapack error message. > > Thanks, I think there are two issues here: > > (i) Something is wrong with the LAPACK installation. What is the version > of LAPACK that you have? ATLAS 3.8.4 plus netlib lapack 3.4.2 (which is where I think sgerqf comes from). > (ii) The *QR routines are marked as `threadsafe` in flapack.pyf.src, > which implies releasing the GIL. However, the XERBLA error handling code > in python_xerbla.c inside Numpy assumes it has the GIL. > > (scipy.linalg doesn't have it's own python_xerbla.c, so it ends up > looking for the symbol in numpy.linalg.lapack_lite --- rather unexpected!) So, any suggestions for this? Should flapack.pyf.src not mark them as thread safe? Should scipy provide its own xerbla? >> "On entry to SGERQF parameter number 7 had an illegal value" > > Parameter number 7 is LWORK. What is interesting here is that the > wrapper to this routine ensures that LWORK >= M, as required by LAPACK > documentation. Stepping through the execution of SGERQF in a debugger > would reveal what is going wrong. Unfortunately since this is an atlas wrapped lapack function, I'm losing debug info. However, I was able to get it to link in netlib lapack first via LD_LIBARY_PATH, and - Breakpoint 3, sgerqf (m=300, n=2, a=..., lda=300, tau=..., work=..., lwork=2, info=0) So lwork is not > M. And indeed: #5 0x000000315245f0cc in PyObject_Call (func=func at entry=, arg=arg at entry=(,), kw=kw at entry={'lwork': 2}) at /usr/src/debug/Python-3.3.1/Objects/abstract.c:2082 2082 result = (*call)(func, arg, kw); Not sure where to look next. Time to move to numpy list? > > [clip] >> http://www.scipy.org/BugReport seems to not point me anywhere useful. > > 13.04.2013 11:30, Ralf Gommers kirjoitti: >> No, the page indeed doesn't exist anymore. Maybe it fell victim to a >> recent spam cleanup. > > Oops, that *is* true. Sorry for my tone in the previous mail... > NP. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From pav at iki.fi Mon Apr 15 17:32:38 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 16 Apr 2013 00:32:38 +0300 Subject: [SciPy-Dev] SciPy 0.12.0/Numpy 1.7.1 sgerqf segfault In-Reply-To: <516C6D84.3090102@cora.nwra.com> References: <516891D6.1050500@cora.nwra.com> <516C6D84.3090102@cora.nwra.com> Message-ID: 16.04.2013 00:13, Orion Poplawski kirjoitti: [clip] >> (scipy.linalg doesn't have it's own python_xerbla.c, so it ends up >> looking for the symbol in numpy.linalg.lapack_lite --- rather unexpected!) > > So, any suggestions for this? Should flapack.pyf.src not mark them as thread > safe? Should scipy provide its own xerbla? Yes, to the latter. The actual fix to this bug is with high probability a replacement from integer optional,intent(in),depend(n),check(lwork>=m||lwork==-1) :: lwork=3*m to integer optional,intent(in),depend(m),check(lwork>=m||lwork==-1) :: lwork=3*m on line 653 of scipy/linalg/flapack.pyf.src. This bug doesn't manifest always as it depends on ordering of dict entries inside f2py... [clip] > Not sure where to look next. Time to move to numpy list? It's a Scipy bug, so this list should be fine. -- Pauli Virtanen From pav at iki.fi Mon Apr 15 17:53:02 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 16 Apr 2013 00:53:02 +0300 Subject: [SciPy-Dev] SciPy 0.12.0/Numpy 1.7.1 sgerqf segfault In-Reply-To: References: <516891D6.1050500@cora.nwra.com> <516C6D84.3090102@cora.nwra.com> Message-ID: 16.04.2013 00:32, Pauli Virtanen kirjoitti: [clip] > The actual fix to this bug is with high probability a replacement from > > integer optional,intent(in),depend(n),check(lwork>=m||lwork==-1) :: > lwork=3*m > > to > > integer optional,intent(in),depend(m),check(lwork>=m||lwork==-1) :: > lwork=3*m > > on line 653 of scipy/linalg/flapack.pyf.src. This bug doesn't manifest > always as it depends on ordering of dict entries inside f2py... Note that this affects mainly the test only --- in the wrapper routines in Scipy, lwork is obtained via a workspace query, so it should be large enough in typical use. -- Pauli Virtanen From suryak at ieee.org Tue Apr 16 06:17:10 2013 From: suryak at ieee.org (Surya Kasturi) Date: Tue, 16 Apr 2013 15:47:10 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: > > > > On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >> >>> Hi everyone, >>> >>> How about SciPy Central on GSoC 2013? >>> >>> I was thinking to participate in GSoC this year and thought of >>> contributing to this project as GSoC student. Firstly, I was luck enough to >>> find SPC which closely matched my interests. Since, I am already slightly >>> familiar with the existing code, made some small contributions, I thought >>> it would be very nice to continue my work as GSoC student during summer. >>> >>> Is it possible? >>> >> >> Hi Surya, it's definitely possible I think. And a good idea. Improving >> SciPy Central meets the requirements for a project set by Google and you've >> already met the requirement of submitting at least one patch before >> applying. >> >> I would encourage you to start working on a proposal, and discuss it on >> this list. Maybe you've seen this already, but just in case: >> http://wiki.python.org/moin/SummerOfCode/Application >> >> The other thing to do is find a mentor. We have several people that >> indicated that they'd like to be a mentor this year, maybe one of those >> people is interested in SPC? Or other people on the list? >> > > Hi, we do have a potential mentor for this project, Sebasti?n Ventura. > Since he's not yet active in the Scipy community, I'll briefly introduce > him. Sebastian is an experienced web developer, and has participated before > in GSoC both as a student and a mentor. We came into contact via the PSF > (our GSoC umbrella org), to which he had indicated that he was available as > a mentor for Python GSoC projects. Once he has signed up for this mailing > list - which may take a day or two because scipy.org is unresponsive > right now - he'll join the discussion. > > Cheers, > Ralf > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > > I am waiting for him.. did he joined the mailing list? -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Tue Apr 16 11:18:15 2013 From: suryak at ieee.org (Surya Kasturi) Date: Tue, 16 Apr 2013 20:48:15 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: Hi all, I created a blog to post proposal, ideas for proposal etc.. on spc. http://surya-gsoc2013.blogspot.in/ The proposal is under making.. but I looking for someone to comment of my ideas. It would be great if someone could help me choosing some of them or all of them.. (Let me know if they have to be posted in mailing list) Thanks Surya On Tue, Apr 16, 2013 at 3:47 PM, Surya Kasturi wrote: > > > > On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>> >>>> Hi everyone, >>>> >>>> How about SciPy Central on GSoC 2013? >>>> >>>> I was thinking to participate in GSoC this year and thought of >>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>> find SPC which closely matched my interests. Since, I am already slightly >>>> familiar with the existing code, made some small contributions, I thought >>>> it would be very nice to continue my work as GSoC student during summer. >>>> >>>> Is it possible? >>>> >>> >>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>> SciPy Central meets the requirements for a project set by Google and you've >>> already met the requirement of submitting at least one patch before >>> applying. >>> >>> I would encourage you to start working on a proposal, and discuss it on >>> this list. Maybe you've seen this already, but just in case: >>> http://wiki.python.org/moin/SummerOfCode/Application >>> >>> The other thing to do is find a mentor. We have several people that >>> indicated that they'd like to be a mentor this year, maybe one of those >>> people is interested in SPC? Or other people on the list? >>> >> >> Hi, we do have a potential mentor for this project, Sebasti?n Ventura. >> Since he's not yet active in the Scipy community, I'll briefly introduce >> him. Sebastian is an experienced web developer, and has participated before >> in GSoC both as a student and a mentor. We came into contact via the PSF >> (our GSoC umbrella org), to which he had indicated that he was available as >> a mentor for Python GSoC projects. Once he has signed up for this mailing >> list - which may take a day or two because scipy.org is unresponsive >> right now - he'll join the discussion. >> >> Cheers, >> Ralf >> >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev >> >> > I am waiting for him.. did he joined the mailing list? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.a.griffith at gmail.com Tue Apr 16 11:59:03 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Tue, 16 Apr 2013 10:59:03 -0500 Subject: [SciPy-Dev] GSOC - sparse improvements, dtypes introduction Message-ID: Hello, The sparse matrix issues are the most interesting to me. I am reading up on issues with the package and testing them. However are there already enough people working on this? I'm trying to get a feeling for how much of a scope these bugs have, and what would be worthy of writing a proposal about. It seems like formulating a bool-handling specification would overlap a bit with the larger issues around dtype handling. Maybe there is a reasonable way to combine these without taking on too much work? Thanks! Blake Griffith -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Tue Apr 16 15:32:45 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 16 Apr 2013 13:32:45 -0600 Subject: [SciPy-Dev] SciPy 0.12.0/Numpy 1.7.1 sgerqf segfault In-Reply-To: References: <516891D6.1050500@cora.nwra.com> <516C6D84.3090102@cora.nwra.com> Message-ID: <516DA75D.9090605@cora.nwra.com> On 04/15/2013 03:32 PM, Pauli Virtanen wrote: > 16.04.2013 00:13, Orion Poplawski kirjoitti: > [clip] >>> (scipy.linalg doesn't have it's own python_xerbla.c, so it ends up >>> looking for the symbol in numpy.linalg.lapack_lite --- rather unexpected!) >> >> So, any suggestions for this? Should flapack.pyf.src not mark them as thread >> safe? Should scipy provide its own xerbla? > > Yes, to the latter. > > The actual fix to this bug is with high probability a replacement from > > integer optional,intent(in),depend(n),check(lwork>=m||lwork==-1) :: > lwork=3*m > > to > > integer optional,intent(in),depend(m),check(lwork>=m||lwork==-1) :: > lwork=3*m > > on line 653 of scipy/linalg/flapack.pyf.src. This bug doesn't manifest > always as it depends on ordering of dict entries inside f2py... I can confirm that this fixes it. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: scipy-gerqf.patch Type: text/x-patch Size: 731 bytes Desc: not available URL: From jsseabold at gmail.com Tue Apr 16 15:45:43 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 16 Apr 2013 15:45:43 -0400 Subject: [SciPy-Dev] Status of Migrating Issues to Github? In-Reply-To: References: Message-ID: Hi, Frustrated with Trac again. Would like to do something about it. Is there anyway for me to download the trac database without access to the server that hosts it? If not, could I get (read-only) access or help to get this sorted by some other means? Thanks, Skipper -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Tue Apr 16 16:03:17 2013 From: robert.kern at gmail.com (Robert Kern) Date: Wed, 17 Apr 2013 01:33:17 +0530 Subject: [SciPy-Dev] Status of Migrating Issues to Github? In-Reply-To: References: Message-ID: On Wed, Apr 17, 2013 at 1:15 AM, Skipper Seabold wrote: > Hi, > > Frustrated with Trac again. Would like to do something about it. Is there > anyway for me to download the trac database without access to the server > that hosts it? If not, could I get (read-only) access or help to get this > sorted by some other means? We can get you whatever you need. I'll contact you off-list. -- Robert Kern From ralf.gommers at gmail.com Tue Apr 16 18:03:42 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Apr 2013 00:03:42 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Tue, Apr 16, 2013 at 5:18 PM, Surya Kasturi wrote: > Hi all, > > I created a blog to post proposal, ideas for proposal etc.. on spc. > http://surya-gsoc2013.blogspot.in/ > > The proposal is under making.. but I looking for someone to comment of my > ideas. It would be great if someone could help me choosing some of them or > all of them.. > > (Let me know if they have to be posted in mailing list) > Hi Surya, I think posting on your blog is fine. It looks to me like you have a lot of good ideas, but it would help your proposal to group them together into a couple of themes. For example: 1. Finish and deploy new site design 2. Improve site performance and maintainability by: - adding a caching mechanism - using Django-CMS and migrating to Django 1.4.5 - add design documentation 3. Code/snippet submission by: 4. Other new features Then you have to have some idea on relative importance of all these things and how long they'll take in order to make a plan with a rough timeline attached. Cheers, Ralf > On Tue, Apr 16, 2013 at 3:47 PM, Surya Kasturi wrote: > >> >> >> >> On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: >> >>> >>> >>> >>> On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> How about SciPy Central on GSoC 2013? >>>>> >>>>> I was thinking to participate in GSoC this year and thought of >>>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>>> find SPC which closely matched my interests. Since, I am already slightly >>>>> familiar with the existing code, made some small contributions, I thought >>>>> it would be very nice to continue my work as GSoC student during summer. >>>>> >>>>> Is it possible? >>>>> >>>> >>>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>>> SciPy Central meets the requirements for a project set by Google and you've >>>> already met the requirement of submitting at least one patch before >>>> applying. >>>> >>>> I would encourage you to start working on a proposal, and discuss it on >>>> this list. Maybe you've seen this already, but just in case: >>>> http://wiki.python.org/moin/SummerOfCode/Application >>>> >>>> The other thing to do is find a mentor. We have several people that >>>> indicated that they'd like to be a mentor this year, maybe one of those >>>> people is interested in SPC? Or other people on the list? >>>> >>> >>> Hi, we do have a potential mentor for this project, Sebasti?n Ventura. >>> Since he's not yet active in the Scipy community, I'll briefly introduce >>> him. Sebastian is an experienced web developer, and has participated before >>> in GSoC both as a student and a mentor. We came into contact via the PSF >>> (our GSoC umbrella org), to which he had indicated that he was available as >>> a mentor for Python GSoC projects. Once he has signed up for this mailing >>> list - which may take a day or two because scipy.org is unresponsive >>> right now - he'll join the discussion. >>> >>> Cheers, >>> Ralf >>> >>> >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>> >>> >> I am waiting for him.. did he joined the mailing list? >> > > > _______________________________________________ > 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 lomegor at gmail.com Wed Apr 17 11:19:28 2013 From: lomegor at gmail.com (=?ISO-8859-1?Q?Sebasti=E1n_Ventura?=) Date: Wed, 17 Apr 2013 16:19:28 +0100 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: Hi, Ralf, Surya and everyone else! Sorry for not answering sooner, it seems that I missed this thread. I agree with Ralf on the grouping of the ideas, it not only makes it more organized, but it will help you when you are trying to creating a rough schedule of how you are going to do it. Order them in term of priority so you know which is more important to do. In my opinion, migrating to a CMS is one of the first things you should do, as it will make it easier to improve the design and probably avoid having to take time for that again after migrating. One thing I think is missing from this is investigating different possibilities, both for the CMS and the design. This means testing or investigating different CMS or templates or whatever to see which one suits this project best. Although I particularly like Django (and I think you do too), it doesn't mean it's the only solution or even the best one. Therefore, I think that should be a point of its own. In that point, you can also include time learning the technologies you are going to use (if you are not already familiar with them), because that may take some small time. One more thing regarding submissions. Although I like your ideas of having the code in gists and the submission available on PDF, it's important before implementing things to think about who needs it and if it's really going to be used. I'm not sure if there's anything to gain with hosting the code on gists, except better reach, but if people are still going to use the main page to look at code, it wouldn't be too important. That means that more time could be spent in improving maintainability, performance and things like that. Great ideas, by the way, and great initiative on having the blog. It's always good to have communication on those things. Keep it coming, and remember to add a rough schedule and order things by priority. Cheers, Sebastian On 16 April 2013 23:03, Ralf Gommers wrote: > > > > On Tue, Apr 16, 2013 at 5:18 PM, Surya Kasturi wrote: > >> Hi all, >> >> I created a blog to post proposal, ideas for proposal etc.. on spc. >> http://surya-gsoc2013.blogspot.in/ >> >> The proposal is under making.. but I looking for someone to comment of my >> ideas. It would be great if someone could help me choosing some of them or >> all of them.. >> >> (Let me know if they have to be posted in mailing list) >> > > Hi Surya, I think posting on your blog is fine. It looks to me like you > have a lot of good ideas, but it would help your proposal to group them > together into a couple of themes. For example: > 1. Finish and deploy new site design > 2. Improve site performance and maintainability by: > - adding a caching mechanism > - using Django-CMS and migrating to Django 1.4.5 > - add design documentation > 3. Code/snippet submission by: > > 4. Other new features > > > Then you have to have some idea on relative importance of all these things > and how long they'll take in order to make a plan with a rough timeline > attached. > > Cheers, > Ralf > > > >> On Tue, Apr 16, 2013 at 3:47 PM, Surya Kasturi wrote: >> >>> >>> >>> >>> On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> How about SciPy Central on GSoC 2013? >>>>>> >>>>>> I was thinking to participate in GSoC this year and thought of >>>>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>>>> find SPC which closely matched my interests. Since, I am already slightly >>>>>> familiar with the existing code, made some small contributions, I thought >>>>>> it would be very nice to continue my work as GSoC student during summer. >>>>>> >>>>>> Is it possible? >>>>>> >>>>> >>>>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>>>> SciPy Central meets the requirements for a project set by Google and you've >>>>> already met the requirement of submitting at least one patch before >>>>> applying. >>>>> >>>>> I would encourage you to start working on a proposal, and discuss it >>>>> on this list. Maybe you've seen this already, but just in case: >>>>> http://wiki.python.org/moin/SummerOfCode/Application >>>>> >>>>> The other thing to do is find a mentor. We have several people that >>>>> indicated that they'd like to be a mentor this year, maybe one of those >>>>> people is interested in SPC? Or other people on the list? >>>>> >>>> >>>> Hi, we do have a potential mentor for this project, Sebasti?n Ventura. >>>> Since he's not yet active in the Scipy community, I'll briefly introduce >>>> him. Sebastian is an experienced web developer, and has participated before >>>> in GSoC both as a student and a mentor. We came into contact via the PSF >>>> (our GSoC umbrella org), to which he had indicated that he was available as >>>> a mentor for Python GSoC projects. Once he has signed up for this mailing >>>> list - which may take a day or two because scipy.org is unresponsive >>>> right now - he'll join the discussion. >>>> >>>> Cheers, >>>> Ralf >>>> >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>> I am waiting for him.. did he joined the mailing list? >>> >> >> >> _______________________________________________ >> 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 jsseabold at gmail.com Wed Apr 17 13:58:07 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 17 Apr 2013 13:58:07 -0400 Subject: [SciPy-Dev] Migrating Issues to Git Message-ID: Started looking into this using the code from the numpy move and other tools. https://github.com/thouis/numpy-trac-migration https://github.com/roskakori/tratihubis The first "problem" is that it looks like it's possible github has changed some privacy settings since the numpy migration, or I'm missing something from how the old migration was done. For numpy we went trac name -> email -> github user. But now if we try to use the github API for an e-mail -> github name search, I'm only able to recover 27 user names out of 1002 trac users. Some of these are available from the numpy migration, but still <= 10%. Any ideas what to do? Ping these users by email asking to reply with github username? Update trac tickets with link to new github issue? Skipper -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Wed Apr 17 15:13:15 2013 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 17 Apr 2013 22:13:15 +0300 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: 17.04.2013 20:58, Skipper Seabold kirjoitti: [clip] > For numpy we went trac name -> email -> github user. But now if we try > to use the github API for an e-mail -> github name search, I'm only able > to recover 27 user names out of 1002 trac users. Some of these are > available from the numpy migration, but still <= 10%. > > Any ideas what to do? Ping these users by email asking to reply with > github username? Update trac tickets with link to new github issue? Or: ignore the issue, except for the current active set of developers. There's not so much dialogue between issue submitters and developers in the Trac that preserving the connections would be worth much effort. -- Pauli Virtanen From ralf.gommers at gmail.com Wed Apr 17 15:59:48 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 17 Apr 2013 21:59:48 +0200 Subject: [SciPy-Dev] GSOC - sparse improvements, dtypes introduction In-Reply-To: References: Message-ID: On Tue, Apr 16, 2013 at 5:59 PM, Blake Griffith wrote: > Hello, > The sparse matrix issues are the most interesting to me. I am reading up > on issues with the package and testing them. However are there already > enough people working on this? > Hi Blake, welcome. In my opinion it would be good to have a GSoC project on this. One other student (Izzy) has expressed interest in it so far, but I haven't seen a follow-up to his first email yet. Daniel Smith also wants to continue improving this functionality outside of GSoC, but two is not a crowd. I haven't yet seen a situation where several students want to work on the same topic, and we have no clear rules/policy. So I'll just point out a few things that may be helpful in choosing a project: - the projects listed on the ideas page aren't the only ones that we'll consider. if you have another idea related to any of the main Scipy submodules, that's perfectly fine. Given the interests of mentors and core developers, I'd say these are good modules to work on (others are too small or too much in need of maintenance): sparse, optimize, stats, signal, interpolate, spatial, linalg, special. - the application process is competitive. We'll have to rank proposals anway, if we do get two proposals on the same topic we'll still rank them according to the proposal quality, interaction with applicants on the mailing list and the PRs made so far. I'm trying to get a feeling for how much of a scope these bugs have, and > what would be worthy of writing a proposal about. > > It seems like formulating a bool-handling specification would overlap a > bit with the larger issues around dtype handling. Maybe there is a > reasonable way to combine these without taking on too much work? > I'm not sure about that. If you're referring to the "Pythonic dtypes" idea, then I think those are fairly orthogonal. The dtypes project would likely be the more challenging of the two. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.a.griffith at gmail.com Wed Apr 17 16:36:26 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Wed, 17 Apr 2013 15:36:26 -0500 Subject: [SciPy-Dev] GSOC - sparse improvements, dtypes introduction In-Reply-To: References: Message-ID: Thanks Ralf, I've started preparing a proposal relating to sparse matricies, however this is subject to change. To get aquainted with the code I've been exploring a few bugs related to the sparse module. I'm trying to figure out how to add support to the toarray() method for bool matricies (see #1153 http://projects.scipy.org/scipy/ticket/1533 ) and written up what I've found on my blog. However I ran into a bit of a wall at the SWIG wrapper. Which I have not had time to explore today. In particular, where is the class T is coming from in https://github.com/scipy/scipy/blob/master/scipy/sparse/sparsetools/coo.h#L105 My blog is here: http://cwl.cx Thanks, On Wed, Apr 17, 2013 at 2:59 PM, Ralf Gommers wrote: > > > > On Tue, Apr 16, 2013 at 5:59 PM, Blake Griffith < > blake.a.griffith at gmail.com> wrote: > >> Hello, >> The sparse matrix issues are the most interesting to me. I am reading up >> on issues with the package and testing them. However are there already >> enough people working on this? >> > > Hi Blake, welcome. In my opinion it would be good to have a GSoC project > on this. One other student (Izzy) has expressed interest in it so far, but > I haven't seen a follow-up to his first email yet. Daniel Smith also wants > to continue improving this functionality outside of GSoC, but two is not a > crowd. > > I haven't yet seen a situation where several students want to work on the > same topic, and we have no clear rules/policy. So I'll just point out a few > things that may be helpful in choosing a project: > - the projects listed on the ideas page aren't the only ones that we'll > consider. if you have another idea related to any of the main Scipy > submodules, that's perfectly fine. Given the interests of mentors and core > developers, I'd say these are good modules to work on (others are too small > or too much in need of maintenance): > sparse, optimize, stats, signal, interpolate, spatial, linalg, special. > - the application process is competitive. We'll have to rank proposals > anway, if we do get two proposals on the same topic we'll still rank them > according to the proposal quality, interaction with applicants on the > mailing list and the PRs made so far. > > I'm trying to get a feeling for how much of a scope these bugs have, and >> what would be worthy of writing a proposal about. >> >> It seems like formulating a bool-handling specification would overlap a >> bit with the larger issues around dtype handling. Maybe there is a >> reasonable way to combine these without taking on too much work? >> > > I'm not sure about that. If you're referring to the "Pythonic dtypes" > idea, then I think those are fairly orthogonal. The dtypes project would > likely be the more challenging of the two. > > Cheers, > Ralf > > _______________________________________________ > 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 pav at iki.fi Wed Apr 17 16:43:40 2013 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 17 Apr 2013 23:43:40 +0300 Subject: [SciPy-Dev] GSOC - sparse improvements, dtypes introduction In-Reply-To: References: Message-ID: Hi, 17.04.2013 23:36, Blake Griffith kirjoitti: [clip] > In particular, where is the class T is coming from > in https://github.com/scipy/scipy/blob/master/scipy/sparse/sparsetools/coo.h#L105 That's a C++ template -- "class T" means "some type, let's call it T", so it's not a specific class. The types SWIG uses are listed at the end of `sparsetools.i`. The SWIG macro INSTANTIATE_ALL defined there is then called e.g. in `csc.i` for all the relevant routines. If you look at the generated `csc_wrap.cxx`, you see calls to the routines with explicitly specified types. -- Pauli Virtanen From thouis at gmail.com Thu Apr 18 09:07:15 2013 From: thouis at gmail.com (Thouis (Ray) Jones) Date: Thu, 18 Apr 2013 09:07:15 -0400 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: I don't recall how many I was able to find through the search interface. It was not that high of a percentage, IIRC. I dealt with this by ordering unknown emails by number of references, and did some by-hand searching for github users for the top N (I think until the number of mentions of the user was below 3 or 4). From jsseabold at gmail.com Thu Apr 18 09:14:31 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 18 Apr 2013 09:14:31 -0400 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: On Thu, Apr 18, 2013 at 9:07 AM, Thouis (Ray) Jones wrote: > I don't recall how many I was able to find through the search > interface. It was not that high of a percentage, IIRC. > > I dealt with this by ordering unknown emails by number of references, > and did some by-hand searching for github users for the top N (I think > until the number of mentions of the user was below 3 or 4). > Thanks, that's helpful. I'll see what I can do. Skipper -------------- next part -------------- An HTML attachment was scrubbed... URL: From eigenspaces at gmail.com Thu Apr 18 10:33:09 2013 From: eigenspaces at gmail.com (Patrick "Kai" Baker) Date: Thu, 18 Apr 2013 10:33:09 -0400 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.12.0 release In-Reply-To: <516A7351.7040403@hilboll.de> References: <5162AE5F.5090406@hilboll.de> <516A7351.7040403@hilboll.de> Message-ID: I did that, and now SciPy 0.12 works on Python3. Thanks so much. :) But I can't import matplotlib on Python3. Also, is SciPy 0.12 for Python3 only? On Sun, Apr 14, 2013 at 5:13 AM, Andreas Hilboll wrote: > > > I just uploaded .deb Packages for Ubuntu 12.04LTS to > > > > > ppa:pylab/stable > > > > I just added that to my Linux Mint repository. What do I use with > > apt-get to install your package? > > Hi Patrick, > > after the usual > > sudo apt-get update > > you can install the package with > > sudo apt-get install python-scipy > > or > > sudo apt-get install python3-scipy > > depending on which Python you're using. > > Cheers, A. > -- http://www.Kailevynskii.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Thu Apr 18 11:43:50 2013 From: suryak at ieee.org (Surya Kasturi) Date: Thu, 18 Apr 2013 21:13:50 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: Thanks for dropping by! On Wed, Apr 17, 2013 at 8:49 PM, Sebasti?n Ventura wrote: > Hi, Ralf, Surya and everyone else! > > Sorry for not answering sooner, it seems that I missed this thread. I > agree with Ralf on the grouping of the ideas, it not only makes it more > organized, but it will help you when you are trying to creating a rough > schedule of how you are going to do it. Order them in term of priority so > you know which is more important to do. In my opinion, migrating to a CMS > is one of the first things you should do, as it will make it easier to > improve the design and probably avoid having to take time for that again > after migrating. > Yeah, I even thought of doing CMS thing first. Regarding the proposal -- I am working on it. primarily, I am looking for new ideas!! > > One thing I think is missing from this is investigating > different possibilities, both for the CMS and the design. This means > testing or investigating different CMS or templates or whatever to see > which one suits this project best. Although I particularly like Django (and > I think you do too), it doesn't mean it's the only solution or even the > best one. Therefore, I think that should be a point of its own. In that > point, you can also include time learning the technologies you are going to > use (if you are not already familiar with them), because that may take some > small time. > Actually, I never played with Django-cms or similar projects so far. This should probably take 1 or 2 days time (not sure). Regarding the reading paths.. 1. reading django-documentation, and a some advanced stuff where ever required. 2. Even though I understand databases basics, I never formally read a book (oops). I guess I should be reading it. Will try my best to complete most of the important stuff before gsoc begins. > > One more thing regarding submissions. Although I like your ideas of having > the code in gists and the submission available on PDF, it's important > before implementing things to think about who needs it and if it's really > going to be used. I'm not sure if there's anything to gain with hosting the > code on gists, except better reach, but if people are still going to use > the main page to look at code, it wouldn't be too important. That means > that more time could be spent in improving maintainability, performance and > things like that. > Gists was discussed on the mailing list some time ago (not a heavy discussion).. I guess, its just for better reach as you said. But, I just got an silly idea (excuse if its really damn bad).. can't we completely rely on Gists? We can primarily story entire snippets source on Gists.. display them, whenever needed on SPC using GitHub API. I wouldn't myself even support this idea.. but I just want to make a note of it. (pros: we don't need to have a DVCS in static content.. and maintain the source) Also, regarding "commenting system", why not use Disqus ? a lot of guys are relying on it now a days.. The problem with replying on the third-party platforms is that we loose complete control over the data at the core. This is not going to be good if we want to build a self-contained application/ platform..What if we want to shift to other platform one day.. I don't know if we can migrate all Gists, comments on it etc.. Similarly with Disqus. Should be build our own commenting system or use Disqus > > Great ideas, by the way, and great initiative on having the blog. It's > always good to have communication on those things. Keep it coming, and > remember to add a rough schedule and order things by priority. > Thanks a lot. Actually, it would be great if you can point out some areas where Scipy Central can be developed... > Cheers, > Sebastian > > > On 16 April 2013 23:03, Ralf Gommers wrote: > >> >> >> >> On Tue, Apr 16, 2013 at 5:18 PM, Surya Kasturi wrote: >> >>> Hi all, >>> >>> I created a blog to post proposal, ideas for proposal etc.. on spc. >>> http://surya-gsoc2013.blogspot.in/ >>> >>> The proposal is under making.. but I looking for someone to comment of >>> my ideas. It would be great if someone could help me choosing some of them >>> or all of them.. >>> >>> (Let me know if they have to be posted in mailing list) >>> >> >> Hi Surya, I think posting on your blog is fine. It looks to me like you >> have a lot of good ideas, but it would help your proposal to group them >> together into a couple of themes. For example: >> 1. Finish and deploy new site design >> 2. Improve site performance and maintainability by: >> - adding a caching mechanism >> - using Django-CMS and migrating to Django 1.4.5 >> - add design documentation >> 3. Code/snippet submission by: >> >> 4. Other new features >> >> >> Then you have to have some idea on relative importance of all these >> things and how long they'll take in order to make a plan with a rough >> timeline attached. >> >> Cheers, >> Ralf >> >> >> >>> On Tue, Apr 16, 2013 at 3:47 PM, Surya Kasturi wrote: >>> >>>> >>>> >>>> >>>> On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> >>>>>>> How about SciPy Central on GSoC 2013? >>>>>>> >>>>>>> I was thinking to participate in GSoC this year and thought of >>>>>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>>>>> find SPC which closely matched my interests. Since, I am already slightly >>>>>>> familiar with the existing code, made some small contributions, I thought >>>>>>> it would be very nice to continue my work as GSoC student during summer. >>>>>>> >>>>>>> Is it possible? >>>>>>> >>>>>> >>>>>> Hi Surya, it's definitely possible I think. And a good idea. >>>>>> Improving SciPy Central meets the requirements for a project set by Google >>>>>> and you've already met the requirement of submitting at least one patch >>>>>> before applying. >>>>>> >>>>>> I would encourage you to start working on a proposal, and discuss it >>>>>> on this list. Maybe you've seen this already, but just in case: >>>>>> http://wiki.python.org/moin/SummerOfCode/Application >>>>>> >>>>>> The other thing to do is find a mentor. We have several people that >>>>>> indicated that they'd like to be a mentor this year, maybe one of those >>>>>> people is interested in SPC? Or other people on the list? >>>>>> >>>>> >>>>> Hi, we do have a potential mentor for this project, Sebasti?n Ventura. >>>>> Since he's not yet active in the Scipy community, I'll briefly introduce >>>>> him. Sebastian is an experienced web developer, and has participated before >>>>> in GSoC both as a student and a mentor. We came into contact via the PSF >>>>> (our GSoC umbrella org), to which he had indicated that he was available as >>>>> a mentor for Python GSoC projects. Once he has signed up for this mailing >>>>> list - which may take a day or two because scipy.org is unresponsive >>>>> right now - he'll join the discussion. >>>>> >>>>> Cheers, >>>>> Ralf >>>>> >>>>> >>>>> _______________________________________________ >>>>> SciPy-Dev mailing list >>>>> SciPy-Dev at scipy.org >>>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>>> >>>>> >>>> I am waiting for him.. did he joined the mailing list? >>>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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 lists at hilboll.de Thu Apr 18 11:53:23 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Thu, 18 Apr 2013 17:53:23 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: <517016F3.30408@hilboll.de> > Also, regarding "commenting system", why not use Disqus > ? a lot of guys are relying on it now a days.. > > The problem with replying on the third-party platforms is that we loose > complete control over the data at the core. This is not going to be good > if we want to build a self-contained application/ platform..What if we > want to shift to other platform one day.. I don't know if we can migrate > all Gists, comments on it etc.. > > Similarly with Disqus. Should be build our own commenting system or use > Disqus Please, don't use Disqus. I'd be reluctant to require users to have accounts with third-party platforms, i.e. Disqus. Github *might* be an exception, but I think it would be better to roll our own. Not relying on gists would allow users to use the VCS of their choice, but our administrative overhead might be too large ... Cheers, Andreas. From suryak at ieee.org Thu Apr 18 12:34:59 2013 From: suryak at ieee.org (Surya Kasturi) Date: Thu, 18 Apr 2013 22:04:59 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: Message-ID: On Wed, Apr 17, 2013 at 3:33 AM, Ralf Gommers wrote: > > > > On Tue, Apr 16, 2013 at 5:18 PM, Surya Kasturi wrote: > >> Hi all, >> >> I created a blog to post proposal, ideas for proposal etc.. on spc. >> http://surya-gsoc2013.blogspot.in/ >> >> The proposal is under making.. but I looking for someone to comment of my >> ideas. It would be great if someone could help me choosing some of them or >> all of them.. >> >> (Let me know if they have to be posted in mailing list) >> > > Hi Surya, I think posting on your blog is fine. It looks to me like you > have a lot of good ideas, but it would help your proposal to group them > together into a couple of themes. For example: > 1. Finish and deploy new site design > 2. Improve site performance and maintainability by: > - adding a caching mechanism > - using Django-CMS and migrating to Django 1.4.5 > - add design documentation > 3. Code/snippet submission by: > > 4. Other new features > > > Then you have to have some idea on relative importance of all these things > and how long they'll take in order to make a plan with a rough timeline > attached. > > Cheers, > Ralf > > Thanks a lot -- will keep this example in mind. it sounds good to me. Started writing proposal :) > > >> On Tue, Apr 16, 2013 at 3:47 PM, Surya Kasturi wrote: >> >>> >>> >>> >>> On Fri, Apr 12, 2013 at 1:43 PM, Ralf Gommers wrote: >>> >>>> >>>> >>>> >>>> On Tue, Apr 9, 2013 at 8:20 AM, Ralf Gommers wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Apr 9, 2013 at 6:06 AM, Surya Kasturi wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> How about SciPy Central on GSoC 2013? >>>>>> >>>>>> I was thinking to participate in GSoC this year and thought of >>>>>> contributing to this project as GSoC student. Firstly, I was luck enough to >>>>>> find SPC which closely matched my interests. Since, I am already slightly >>>>>> familiar with the existing code, made some small contributions, I thought >>>>>> it would be very nice to continue my work as GSoC student during summer. >>>>>> >>>>>> Is it possible? >>>>>> >>>>> >>>>> Hi Surya, it's definitely possible I think. And a good idea. Improving >>>>> SciPy Central meets the requirements for a project set by Google and you've >>>>> already met the requirement of submitting at least one patch before >>>>> applying. >>>>> >>>>> I would encourage you to start working on a proposal, and discuss it >>>>> on this list. Maybe you've seen this already, but just in case: >>>>> http://wiki.python.org/moin/SummerOfCode/Application >>>>> >>>>> The other thing to do is find a mentor. We have several people that >>>>> indicated that they'd like to be a mentor this year, maybe one of those >>>>> people is interested in SPC? Or other people on the list? >>>>> >>>> >>>> Hi, we do have a potential mentor for this project, Sebasti?n Ventura. >>>> Since he's not yet active in the Scipy community, I'll briefly introduce >>>> him. Sebastian is an experienced web developer, and has participated before >>>> in GSoC both as a student and a mentor. We came into contact via the PSF >>>> (our GSoC umbrella org), to which he had indicated that he was available as >>>> a mentor for Python GSoC projects. Once he has signed up for this mailing >>>> list - which may take a day or two because scipy.org is unresponsive >>>> right now - he'll join the discussion. >>>> >>>> Cheers, >>>> Ralf >>>> >>>> >>>> _______________________________________________ >>>> SciPy-Dev mailing list >>>> SciPy-Dev at scipy.org >>>> http://mail.scipy.org/mailman/listinfo/scipy-dev >>>> >>>> >>> I am waiting for him.. did he joined the mailing list? >>> >> >> >> _______________________________________________ >> 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 eigenspaces at gmail.com Thu Apr 18 13:07:51 2013 From: eigenspaces at gmail.com (Patrick "Kai" Baker) Date: Thu, 18 Apr 2013 13:07:51 -0400 Subject: [SciPy-Dev] Ticket #1058 Message-ID: I'm new to this collaborative open source stuff so excuse any naivete on my part. I was looking through some of the reported bugs in the integration module and saw that this bug is no longer an issue with 0.12. When I ran it, I didn't get any of the errors reported. Should this be considered fixed? http://projects.scipy.org/scipy/ticket/1058 -- http://www.KailLevynskii.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Thu Apr 18 13:24:28 2013 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 18 Apr 2013 20:24:28 +0300 Subject: [SciPy-Dev] Ticket #1058 In-Reply-To: References: Message-ID: 18.04.2013 20:07, Patrick "Kai" Baker kirjoitti: > I'm new to this collaborative open source stuff so excuse any naivete on > my part. I was looking through some of the reported bugs in the > integration module and saw that this bug is no longer an issue with > 0.12. When I ran it, I didn't get any of the errors reported. Should > this be considered fixed? > > http://projects.scipy.org/scipy/ticket/1058 That still returns the wrong results for me, so I think it hasn't been addressed. -- Pauli Virtanen From lorr.cecil at gmail.com Thu Apr 18 16:08:41 2013 From: lorr.cecil at gmail.com (Izzy Cecil) Date: Thu, 18 Apr 2013 14:08:41 -0600 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice In-Reply-To: References: Message-ID: Thank you all SO MUCH for the advice! Especially Pauli --- your project suggestions have giving me some pretty distinct paths I could take. Sorry for disappearing! I had some medical issues, and then got caught in a mountain of makeup work. I saw that Blake was also interested in working on scipy.sparse, specifically implementing proper boolean sparse matrices. I hope Pauli is right in saying that there is room for two to work on sparse for this SOC! I am very excited about all of the improvements suggested! I feel like I have the skills, but at the moment I'm crunched for time, which is not a good feeling. I was looking at ticket #1042 a bit ago ( http://projects.scipy.org/scipy/ticket/1042 ), and noticed a number of things. I know how to fix them, but I'm not sure if they were design choices or not. I left a comment on the ticket describing some of the cases I was looking at. It seems like this is very related to making numpy methods overwriteable, which Pauli suggested as a SOC project all in its own. I would appreciate feedback on the questions I asked there. I haven't looked terribly much at the numpy code base, but I wondering why spmatrix doesn't inherit from np.matrix? It seems like this would make for a much better interface between preexisting components and sparse matrices. Or is that a silly question? Thanks again, everyone! On Sun, Apr 14, 2013 at 5:19 AM, Pauli Virtanen wrote: > 10.04.2013 11:10, Pauli Virtanen kirjoitti: >> Izzy Cecil gmail.com> writes: >> [clip] >>> I was wondering who would be appropriate to discus this project with, >>> and if there were specific things I could do now to familiarize myself >>> with the codebase. Any smaller bugs that could be fixed, or features >>> that could be added to the library? Or should I consider a different >>> project all together (perhaps Pythonic dtypes)? In the meantime, I'll >>> hunt around trac, and mess with what I can, but any and all advice >>> would be much appreciated! >> >> There's sort of a TODO list here, specified in terms of unit tests: >> >> https://github.com/scipy/scipy/blob/master/scipy/sparse/tests/test_base.py#L >> 1557 > [clip] > > And some more sparse ideas (requested by users): > > http://stackoverflow.com/search?tab=newest&q=[scipy]%20sparse > > - Implement max(axis=someaxis), mean(axis=someaxis), std(axis=someaxis), > and other similar methods > > - Represent the LU factorization obtained via SuperLU as actual sparse > matrices rather than in SuperLU's internal format. > > - Help with getting the support for 64-bit indices in, required for > very large sparse matrices (this work is mostly done, see > https://github.com/scipy/scipy/pull/442, but needs more testing > and review) > > - Boolean operations > > - Fix the callback function situation with the scipy.sparse.linalg > iterative solvers (different functions have different signatures) > > And probably many more. > > I think that even if there are two people working on improving the > situation, there will be well enough to do for a GSoC. > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From blake.a.griffith at gmail.com Thu Apr 18 19:46:23 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Thu, 18 Apr 2013 18:46:23 -0500 Subject: [SciPy-Dev] GSOC - improvements to the .sparse package advice In-Reply-To: References: Message-ID: Hello Izzy, I hope you are doing better. I commented on the mentioned ticket, and submitted a patch for a bug you found. Thanks for pointing it out, it was an easy fix, which is nice for my first patch! I'm still not sure exactly what I want to do for GSoC but we should communicate so that there is no overlap, and we can avoid duplicating effort. You can track some of my progress on my blog at http://cwl.cx . I have a math and physics background, hence my interest in Scipy, I took an advanced numerical methods class this semester so I'm looking for some fun ways to apply what I've learned. On Thu, Apr 18, 2013 at 3:08 PM, Izzy Cecil wrote: > Thank you all SO MUCH for the advice! Especially Pauli --- your > project suggestions have giving me some pretty distinct paths I could > take. > > Sorry for disappearing! I had some medical issues, and then got caught > in a mountain of makeup work. I saw that Blake was also interested in > working on scipy.sparse, specifically implementing proper boolean > sparse matrices. I hope Pauli is right in saying that there is room > for two to work on sparse for this SOC! I am very excited about all of > the improvements suggested! I feel like I have the skills, but at the > moment I'm crunched for time, which is not a good feeling. > > I was looking at ticket #1042 a bit ago ( > http://projects.scipy.org/scipy/ticket/1042 ), and noticed a number of > things. I know how to fix them, but I'm not sure if they were design > choices or not. I left a comment on the ticket describing some of the > cases I was looking at. It seems like this is very related to making > numpy methods overwriteable, which Pauli suggested as a SOC project > all in its own. I would appreciate feedback on the questions I asked > there. > > I haven't looked terribly much at the numpy code base, but I wondering > why spmatrix doesn't inherit from np.matrix? It seems like this would > make for a much better interface between preexisting components and > sparse matrices. Or is that a silly question? > > Thanks again, everyone! > > On Sun, Apr 14, 2013 at 5:19 AM, Pauli Virtanen wrote: > > 10.04.2013 11:10, Pauli Virtanen kirjoitti: > >> Izzy Cecil gmail.com> writes: > >> [clip] > >>> I was wondering who would be appropriate to discus this project with, > >>> and if there were specific things I could do now to familiarize myself > >>> with the codebase. Any smaller bugs that could be fixed, or features > >>> that could be added to the library? Or should I consider a different > >>> project all together (perhaps Pythonic dtypes)? In the meantime, I'll > >>> hunt around trac, and mess with what I can, but any and all advice > >>> would be much appreciated! > >> > >> There's sort of a TODO list here, specified in terms of unit tests: > >> > >> > https://github.com/scipy/scipy/blob/master/scipy/sparse/tests/test_base.py#L > >> 1557 > > [clip] > > > > And some more sparse ideas (requested by users): > > > > http://stackoverflow.com/search?tab=newest&q=[scipy]%20sparse > > > > - Implement max(axis=someaxis), mean(axis=someaxis), std(axis=someaxis), > > and other similar methods > > > > - Represent the LU factorization obtained via SuperLU as actual sparse > > matrices rather than in SuperLU's internal format. > > > > - Help with getting the support for 64-bit indices in, required for > > very large sparse matrices (this work is mostly done, see > > https://github.com/scipy/scipy/pull/442, but needs more testing > > and review) > > > > - Boolean operations > > > > - Fix the callback function situation with the scipy.sparse.linalg > > iterative solvers (different functions have different signatures) > > > > And probably many more. > > > > I think that even if there are two people working on improving the > > situation, there will be well enough to do for a GSoC. > > > > -- > > Pauli Virtanen > > > > _______________________________________________ > > 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 suryak at ieee.org Fri Apr 19 09:10:56 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 19 Apr 2013 18:40:56 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517016F3.30408@hilboll.de> References: <517016F3.30408@hilboll.de> Message-ID: On Thu, Apr 18, 2013 at 9:23 PM, Andreas Hilboll wrote: > > Also, regarding "commenting system", why not use Disqus > > ? a lot of guys are relying on it now a days.. > > > > The problem with replying on the third-party platforms is that we loose > > complete control over the data at the core. This is not going to be good > > if we want to build a self-contained application/ platform..What if we > > want to shift to other platform one day.. I don't know if we can migrate > > all Gists, comments on it etc.. > > > > Similarly with Disqus. Should be build our own commenting system or use > > Disqus > > Please, don't use Disqus. I'd be reluctant to require users to have > accounts with third-party platforms, i.e. Disqus. Github *might* be an > exception, but I think it would be better to roll our own. > > Not relying on gists would allow users to use the VCS of their choice, > but our administrative overhead might be too large ... > > Cheers, Andreas. > Okay.. My opinion is to build our own system.. but I just wanted to make a note that we even have another option like Disqus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sun Apr 21 16:27:27 2013 From: matthew.brett at gmail.com (Matthew Brett) Date: Sun, 21 Apr 2013 13:27:27 -0700 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: Hi Skipper, On Thu, Apr 18, 2013 at 6:14 AM, Skipper Seabold wrote: > On Thu, Apr 18, 2013 at 9:07 AM, Thouis (Ray) Jones > wrote: >> >> I don't recall how many I was able to find through the search >> interface. It was not that high of a percentage, IIRC. >> >> I dealt with this by ordering unknown emails by number of references, >> and did some by-hand searching for github users for the top N (I think >> until the number of mentions of the user was below 3 or 4). > > > Thanks, that's helpful. I'll see what I can do. Anything I / we can do to help? Cheers, Matthew From jsseabold at gmail.com Sun Apr 21 16:36:13 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Sun, 21 Apr 2013 16:36:13 -0400 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: On Sun, Apr 21, 2013 at 4:27 PM, Matthew Brett wrote: > Hi Skipper, > > On Thu, Apr 18, 2013 at 6:14 AM, Skipper Seabold > wrote: > > On Thu, Apr 18, 2013 at 9:07 AM, Thouis (Ray) Jones > > wrote: > >> > >> I don't recall how many I was able to find through the search > >> interface. It was not that high of a percentage, IIRC. > >> > >> I dealt with this by ordering unknown emails by number of references, > >> and did some by-hand searching for github users for the top N (I think > >> until the number of mentions of the user was below 3 or 4). > > > > > > Thanks, that's helpful. I'll see what I can do. > > Anything I / we can do to help? > > No, not unless you want to do just do it I don't think. Just a time issue. I will try to come back to this after I get done writing lectures tonight. Skipper -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.brett at gmail.com Sun Apr 21 16:38:38 2013 From: matthew.brett at gmail.com (Matthew Brett) Date: Sun, 21 Apr 2013 13:38:38 -0700 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: Yo, On Sun, Apr 21, 2013 at 1:36 PM, Skipper Seabold wrote: > On Sun, Apr 21, 2013 at 4:27 PM, Matthew Brett > wrote: >> >> Hi Skipper, >> >> On Thu, Apr 18, 2013 at 6:14 AM, Skipper Seabold >> wrote: >> > On Thu, Apr 18, 2013 at 9:07 AM, Thouis (Ray) Jones >> > wrote: >> >> >> >> I don't recall how many I was able to find through the search >> >> interface. It was not that high of a percentage, IIRC. >> >> >> >> I dealt with this by ordering unknown emails by number of references, >> >> and did some by-hand searching for github users for the top N (I think >> >> until the number of mentions of the user was below 3 or 4). >> > >> > >> > Thanks, that's helpful. I'll see what I can do. >> >> Anything I / we can do to help? >> > > No, not unless you want to do just do it I don't think. Just a time issue. I > will try to come back to this after I get done writing lectures tonight. Ok - if you think of anything, let me know, even if it's just Rubber Ducking [1] Cheers, Matthew [1] http://en.wikipedia.org/wiki/Rubber_duck_debugging From blake.a.griffith at gmail.com Sun Apr 21 22:00:48 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Sun, 21 Apr 2013 21:00:48 -0500 Subject: [SciPy-Dev] Sparse boolean specification Message-ID: Hello, I've been thinking about how I would write the bool handling. I wanted to bounce some ideas off the list, to see what y'all thought. When comparing two sparse matrices of the same type. A sparse matrix of the same type, with bool dtype, should be returned with all True elements with original sets of elements. A element without a corresponding value in the other spmatrix is False. Does this make sense? An example: >>> coo_matrix([True, True], [1,1], [2,2]) == coo_matrix([True, True], [1,3], [1,3]) coo_matrix([True], [1], [1]) When comparing sparse matrices with numpy ndarrays or matrices. The sparsematrix can probably be easily expressed as a dense matrix. So we should spmatrix.toarray() or spmatrix.todense() and compare it with the ndarray or matrix. Returning a ndarray or matrix with bool dtype where each element is a[i,j] = (b[i,j] == c[i,j]), for comparing B == C. Like wise for other comparisons. Does this sound good so far? Also, should I write this up like a PEP? Thanks! Blake G. -- http://cwl.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Apr 22 04:23:24 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 22 Apr 2013 08:23:24 +0000 (UTC) Subject: [SciPy-Dev] Sparse boolean specification References: Message-ID: Blake Griffith gmail.com> writes: [clip] > When comparing two sparse matrices of the same type. > A sparse matrix of the same type, with bool dtype, should > be returned with all True elements with original sets of > elements. A element without a corresponding value in the > other spmatrix is False. Does this make sense? An example:? > > >>> coo_matrix([True, True], [1,1], [2,2]) == coo_matrix([True, True], [1,3], [1,3]) > coo_matrix([True], [1], [1]) I think the user expectation here is rather clear: for sparse matrices A, B and sparse matrix type spmatrix, we have for all boolean operations boolean_op(A, B) is fully equivalent to spmatrix(boolean_op(A.todense(), B.todense())) Deviating from this will undoubtedly lead to surprises and bugs, and IMHO would be a design wart. The drawback here is that `==`, `<=`, `>=` become somewhat useless for sparse matrices as it tends to produce matrices filled with True. But I think this cannot be helped. This doesn't exclude adding other boolean ops, for instance ones that work inside the union of the sparsity patterns, which I think is what I think you proposed. I think these could be added, but should be added either as new functions (my preference) or methods, and you should have some use cases to tell you where these would be useful. (There could by the way be some room for making dealing with sparsity patterns easier. Not sure what exactly, but it's probably possible to think of use cases in this direction where things could be improved. For PDE matrix assembly for instance, it's commonly the case that the sparsity pattern stays constant but the values change. It can be here worthwhile to take a look at what PETSc and other packages offer.) > When comparing sparse matrices with numpy ndarrays or > matrices. The sparsematrix can probably be easily expressed > as a dense matrix. So we should spmatrix.toarray() or > spmatrix.todense() and compare it with the ndarray or > matrix. Returning a ndarray or matrix with bool > dtype where each element is a[i,j] = (b[i,j] == c[i,j]), > for comparing B == C. Like wise for other comparisons. > > Does this sound good so far?? sparse/dense can probably as well return a dense result. If broadcasting is implemented, returning dense may not be the best choice as the result can well be sparse in that case. > Also, should I write this up like a PEP? We don't have a formal process for additions, but for a larger feature additions it can be useful to have a writeup at hand. *** Regarding the bigger picture: One problem with scipy.sparse is that there are 6 different sparse matrix types, which multiplies the effort involved by a factor of 6. As I see it, the order of priority in implementing new features would be CSR & CSC > LIL > the others. Also, it will probably be better to have a 100% working implementation for CSR+CSC, rather than 80% working implementations for all types. -- Pauli Virtanen From j.j.green at gmx.fr Mon Apr 22 12:08:24 2013 From: j.j.green at gmx.fr (J.J. Green) Date: Mon, 22 Apr 2013 17:08:24 +0100 Subject: [SciPy-Dev] Sparse boolean specification In-Reply-To: References: Message-ID: <1366646904.3110.4.camel@banach> Pauli Virtanen wrote: > The drawback here is that `==`, `<=`, `>=` become somewhat > useless for sparse matrices as it tends to produce matrices > filled with True. But I think this cannot be helped. Can't you then just have a sparse structure which also hold the 'empty' value (whether it be true or false), then the non-empty cells are the opposite value. Thus !a just changed the 'empty' value and leaves the matrix structure otherwise unchanged ? From pav at iki.fi Mon Apr 22 12:29:36 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 22 Apr 2013 19:29:36 +0300 Subject: [SciPy-Dev] Sparse boolean specification In-Reply-To: <1366646904.3110.4.camel@banach> References: <1366646904.3110.4.camel@banach> Message-ID: 22.04.2013 19:08, J.J. Green kirjoitti: > Pauli Virtanen wrote: > >> The drawback here is that `==`, `<=`, `>=` become somewhat >> useless for sparse matrices as it tends to produce matrices >> filled with True. But I think this cannot be helped. > > Can't you then just have a sparse structure which also hold > the 'empty' value (whether it be true or false), then the > non-empty cells are the opposite value. Thus !a just changed > the 'empty' value and leaves the matrix structure otherwise > unchanged ? Yes, that's one option, but it involves significantly more work, introducing even more sparse matrix types in addition to the current 6. -- Pauli Virtanen From jsseabold at gmail.com Mon Apr 22 12:32:46 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 12:32:46 -0400 Subject: [SciPy-Dev] Migrating Issues to Git In-Reply-To: References: Message-ID: Err, sorry to a few of you for the issue notification spam. Apparently the @ -> atmention needs to happen elsewhere in the code as well. Will fix this for the dry runs. In the meantime, you can keep an eye out here for how this is going. https://github.com/jseabold/scipy-trac-migration/issues?state=open Skipper From jsseabold at gmail.com Mon Apr 22 14:45:51 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 14:45:51 -0400 Subject: [SciPy-Dev] issues trac migration review Message-ID: Many of the issues have been migrated. Please have a look and let me know of any problems. https://github.com/jseabold/scipy-trac-migration/issues?state=open I got rate limited by github, so I will have to continue later tonight to make sure there are no problems. You'll notice that I used the same @ -> atmention: substitution for now so that people don't get notifications, as I'm working out the kinks. I used the same trac -> github mapping as the numpy migration and added several more by hand of names I recognized as being a duplicate e-mail address of a regular contributor. If we want different issue labels, let me know. It's probably easier to format them now than to do it later. Anything else? Skipper From blake.a.griffith at gmail.com Mon Apr 22 14:51:11 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Mon, 22 Apr 2013 13:51:11 -0500 Subject: [SciPy-Dev] Sparse boolean specification In-Reply-To: References: <1366646904.3110.4.camel@banach> Message-ID: So Pauli, if this is implemented as you suggest, the specification could recommend using the inverse of the typical bool_op. For example if you think that A and B are approximately equal, instead of checking with `A == B`. You could do `A != B` and check for an empty sparse matrix? However there does not seem to be an easy way to avoid a matrix full of `True`'s if you don't know much about A or B. On Mon, Apr 22, 2013 at 11:29 AM, Pauli Virtanen wrote: > 22.04.2013 19:08, J.J. Green kirjoitti: > > Pauli Virtanen wrote: > > > >> The drawback here is that `==`, `<=`, `>=` become somewhat > >> useless for sparse matrices as it tends to produce matrices > >> filled with True. But I think this cannot be helped. > > > > Can't you then just have a sparse structure which also hold > > the 'empty' value (whether it be true or false), then the > > non-empty cells are the opposite value. Thus !a just changed > > the 'empty' value and leaves the matrix structure otherwise > > unchanged ? > > Yes, that's one option, but it involves significantly more work, > introducing even more sparse matrix types in addition to the current 6. > > -- > Pauli Virtanen > > > _______________________________________________ > 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 Mon Apr 22 15:06:40 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Apr 2013 21:06:40 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 8:45 PM, Skipper Seabold wrote: > Many of the issues have been migrated. Please have a look and let me > know of any problems. > > https://github.com/jseabold/scipy-trac-migration/issues?state=open > Looks good! Github even de-uglified the labels, so it's possible to look at the issue list for more than 30s :) > I got rate limited by github, so I will have to continue later tonight > to make sure there are no problems. > > You'll notice that I used the same @ -> atmention: substitution for > now so that people don't get notifications, as I'm working out the > kinks. I used the same trac -> github mapping as the numpy migration > and added several more by hand of names I recognized as being a > duplicate e-mail address of a regular contributor. > > If we want different issue labels, let me know. It's probably easier > to format them now than to do it later. > There are several components that should be removed (pyem, numexpr, linsolve, svm, maxentropy). The colors also need tweaking, but that can be done later. > Anything else? > Attachments. This is a bigger issue for scipy than it was for numpy, and we don't really have a good solution I think. Were you planning to leave the old ones at Trac, and keep that alive for a long time? We don't need new patches as attachment, but we do need something for data files. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Mon Apr 22 15:10:28 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 22 Apr 2013 22:10:28 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 22.04.2013 21:45, Skipper Seabold kirjoitti: [clip] > If we want different issue labels, let me know. It's probably easier > to format them now than to do it later. Maybe drop the "component: " in front of the component labels. The "numexpr", "pyem", "scipy.linsolve", "scipy.maxentropy", "svm", and "Other" component labels can also be dropped. -- Pauli Virtanen From pav at iki.fi Mon Apr 22 15:17:32 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 22 Apr 2013 22:17:32 +0300 Subject: [SciPy-Dev] Sparse boolean specification In-Reply-To: References: <1366646904.3110.4.camel@banach> Message-ID: 22.04.2013 21:51, Blake Griffith kirjoitti: > So Pauli, if this is implemented as you suggest, the specification could > recommend using the inverse of the typical bool_op. For example if you > think that A and B are approximately equal, instead of checking with `A > == B`. You could do `A != B` and check for an empty sparse matrix? > > However there does not seem to be an easy way to avoid a matrix full of > `True`'s if you don't know much about A or B. I think in the typical case where sparse matrices are useful, the matrixes contain mostly zeros, so the behavior in this case is something like A == B -> mostly True A >= B -> mostly True A <= B -> mostly True A != B -> mostly False A > B -> mostly False A < B -> mostly False ... But I indeed think that we are very much constrained to make the semantics of the comparison and boolean operators identical with how dense arrays behave. The documentation/tutorial can tell the users what is efficient and what is not, and there is also the SparseEfficiencyWarning that can be invoked when something sub-optimal is done. The option of adding a special sparse array type with a nonzero "default" value could also be possible, but it would probably require quite a bit of work. -- Pauli Virtanen From matthew.brett at gmail.com Mon Apr 22 15:20:26 2013 From: matthew.brett at gmail.com (Matthew Brett) Date: Mon, 22 Apr 2013 12:20:26 -0700 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: Hi, On Mon, Apr 22, 2013 at 11:45 AM, Skipper Seabold wrote: > Many of the issues have been migrated. Please have a look and let me > know of any problems. > > https://github.com/jseabold/scipy-trac-migration/issues?state=open > > I got rate limited by github, so I will have to continue later tonight > to make sure there are no problems. > > You'll notice that I used the same @ -> atmention: substitution for > now so that people don't get notifications, as I'm working out the > kinks. I used the same trac -> github mapping as the numpy migration > and added several more by hand of names I recognized as being a > duplicate e-mail address of a regular contributor. If you see duplicates maybe note them in a scipy .mailmap? > If we want different issue labels, let me know. It's probably easier > to format them now than to do it later. I guess there is no way to give the github issue dates from the trac tickets? It is worth adding a label 'trac import' to these issues? If the dates are not right then these guys will end up in the middle of the issues list by date (old pull requests going earlier). I can imagine wanting to go back to try and clear up old trac tickets in particular. Otherwise - looks good to me - thanks very much for doing this, Cheers Matthew From josef.pktd at gmail.com Mon Apr 22 15:27:22 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Apr 2013 15:27:22 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:20 PM, Matthew Brett wrote: > Hi, > > On Mon, Apr 22, 2013 at 11:45 AM, Skipper Seabold wrote: >> Many of the issues have been migrated. Please have a look and let me >> know of any problems. >> >> https://github.com/jseabold/scipy-trac-migration/issues?state=open >> >> I got rate limited by github, so I will have to continue later tonight >> to make sure there are no problems. >> >> You'll notice that I used the same @ -> atmention: substitution for >> now so that people don't get notifications, as I'm working out the >> kinks. I used the same trac -> github mapping as the numpy migration >> and added several more by hand of names I recognized as being a >> duplicate e-mail address of a regular contributor. > > If you see duplicates maybe note them in a scipy .mailmap? > >> If we want different issue labels, let me know. It's probably easier >> to format them now than to do it later. > > I guess there is no way to give the github issue dates from the trac tickets? > > It is worth adding a label 'trac import' to these issues? If the > dates are not right then these guys will end up in the middle of the > issues list by date (old pull requests going earlier). I can imagine > wanting to go back to try and clear up old trac tickets in particular. > > Otherwise - looks good to me - thanks very much for doing this, Is there a way to get changeset links ? for example changeset:5972 in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 The only thing I have seen so far. Josef > > Cheers > > Matthew > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From charlesnwoods at gmail.com Mon Apr 22 15:31:47 2013 From: charlesnwoods at gmail.com (Nathan Woods) Date: Mon, 22 Apr 2013 13:31:47 -0600 Subject: [SciPy-Dev] Generalization of scipy.integrate quadrature for multiple integrals Message-ID: <4422841E-C979-4621-9E8A-4E6FA381BE02@gmail.com> I needed to numerically evaluate some 3- and 4-dimensional integrals with discontinuities to high accuracy, so I wrote a python function that recursively calls scipy.integrate.quad with access to the full list of options (particularly points, in my case) for quad, unlike dblquad and tplquad. Would there be any interest in some finishing work on this and rolling into scipy.integrate? From jsseabold at gmail.com Mon Apr 22 15:42:43 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 15:42:43 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:06 PM, Ralf Gommers wrote: > On Mon, Apr 22, 2013 at 8:45 PM, Skipper Seabold >> If we want different issue labels, let me know. It's probably easier >> to format them now than to do it later. > > > There are several components that should be removed (pyem, numexpr, > linsolve, svm, maxentropy). Will do. > The colors also need tweaking, but that can be done later. Yeah, this is actually easier to do through the web ui. > >> >> Anything else? > > > Attachments. This is a bigger issue for scipy than it was for numpy, and we > don't really have a good solution I think. Were you planning to leave the > old ones at Trac, and keep that alive for a long time? We don't need new > patches as attachment, but we do need something for data files. I don't have control of the trac machine, but I assume the server will be left on in a read-only state. As for new data submissions...well...open issue I guess. Github accepts image attachments and posts them to their server on amazon. I assume this functionality will be extended at some point. They've been talking about it for 4 years now. We could instruct people to use e-mail attachments and post them to the list then link to the message in the issue? Skipper From jsseabold at gmail.com Mon Apr 22 15:43:15 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 15:43:15 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:10 PM, Pauli Virtanen wrote: > 22.04.2013 21:45, Skipper Seabold kirjoitti: > [clip] >> If we want different issue labels, let me know. It's probably easier >> to format them now than to do it later. > > Maybe drop the "component: " in front of the component labels. Sure. Skipper From jsseabold at gmail.com Mon Apr 22 15:46:51 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 15:46:51 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:20 PM, Matthew Brett wrote: > Hi, > > On Mon, Apr 22, 2013 at 11:45 AM, Skipper Seabold wrote: >> Many of the issues have been migrated. Please have a look and let me >> know of any problems. >> >> https://github.com/jseabold/scipy-trac-migration/issues?state=open >> >> I got rate limited by github, so I will have to continue later tonight >> to make sure there are no problems. >> >> You'll notice that I used the same @ -> atmention: substitution for >> now so that people don't get notifications, as I'm working out the >> kinks. I used the same trac -> github mapping as the numpy migration >> and added several more by hand of names I recognized as being a >> duplicate e-mail address of a regular contributor. > > If you see duplicates maybe note them in a scipy .mailmap? I'm not sure it's an ongoing issue at this point since it was trac user names. There may still be a few in the git log but that's another issue. I'm happy to push the scipy lists though, if it would help. > >> If we want different issue labels, let me know. It's probably easier >> to format them now than to do it later. > > I guess there is no way to give the github issue dates from the trac tickets? No it doesn't look like the create issue post request allows this unfortunately. > > It is worth adding a label 'trac import' to these issues? If the > dates are not right then these guys will end up in the middle of the > issues list by date (old pull requests going earlier). I can imagine > wanting to go back to try and clear up old trac tickets in particular. Yes, I could add the label if it will be helpful. Sounds reasonable to me. Skipper From jsseabold at gmail.com Mon Apr 22 15:48:01 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Mon, 22 Apr 2013 15:48:01 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:27 PM, wrote: > Is there a way to get changeset links ? > > for example > changeset:5972 > in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 > Yeah, that should be doable. I'll add it to the list. Skipper From josef.pktd at gmail.com Mon Apr 22 16:34:35 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Apr 2013 16:34:35 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold wrote: > On Mon, Apr 22, 2013 at 3:27 PM, wrote: >> Is there a way to get changeset links ? >> >> for example >> changeset:5972 >> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 >> > > Yeah, that should be doable. I'll add it to the list. Thanks, same for tickets ticket:1082 3rd comment here https://github.com/jseabold/scipy-trac-migration/issues/1081 Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From pav at iki.fi Mon Apr 22 16:35:38 2013 From: pav at iki.fi (Pauli Virtanen) Date: Mon, 22 Apr 2013 23:35:38 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 22.04.2013 22:42, Skipper Seabold kirjoitti: [clip] > As for new data submissions...well...open issue I guess. Github > accepts image attachments and posts them to their server on amazon. I > assume this functionality will be extended at some point. They've been > talking about it for 4 years now. We could instruct people to use > e-mail attachments and post them to the list then link to the message > in the issue? E-mail has the problem that it spams N+1 people who are not interested in the potentially big data file, plus it's a hassle to subscribe to the list so that you can post. It probably needs to be something simple, otherwise what happens is dropbox/mediafire/ad-supported-upload-service-of-your-choice which do not necessarily have a very long lifetimes. A third-party web app can use Github for authentication: http://developer.github.com/v3/oauth/ But nobody seems to have written so far (or at least I can't find) something that does this. -- Pauli Virtanen From warren.weckesser at gmail.com Mon Apr 22 17:14:25 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Mon, 22 Apr 2013 17:14:25 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On 4/22/13, Skipper Seabold wrote: > Many of the issues have been migrated. Please have a look and let me > know of any problems. > > https://github.com/jseabold/scipy-trac-migration/issues?state=open > > I got rate limited by github, so I will have to continue later tonight > to make sure there are no problems. > > You'll notice that I used the same @ -> atmention: substitution for > now so that people don't get notifications, as I'm working out the > kinks. I used the same trac -> github mapping as the numpy migration > and added several more by hand of names I recognized as being a > duplicate e-mail address of a regular contributor. > > If we want different issue labels, let me know. It's probably easier > to format them now than to do it later. > > Anything else? Can we take this as a good time to simply drop all the "Statistics Review" tickets? My understanding is that they were part of an ambitious plan from several years ago, but, as far as I can tell, those ticket have no real purpose any more. Warren > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From ralf.gommers at gmail.com Mon Apr 22 17:17:30 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Apr 2013 23:17:30 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser < warren.weckesser at gmail.com> wrote: > On 4/22/13, Skipper Seabold wrote: > > Many of the issues have been migrated. Please have a look and let me > > know of any problems. > > > > https://github.com/jseabold/scipy-trac-migration/issues?state=open > > > > I got rate limited by github, so I will have to continue later tonight > > to make sure there are no problems. > > > > You'll notice that I used the same @ -> atmention: substitution for > > now so that people don't get notifications, as I'm working out the > > kinks. I used the same trac -> github mapping as the numpy migration > > and added several more by hand of names I recognized as being a > > duplicate e-mail address of a regular contributor. > > > > If we want different issue labels, let me know. It's probably easier > > to format them now than to do it later. > > > > Anything else? > > > Can we take this as a good time to simply drop all the "Statistics > Review" tickets? +1 Ralf > My understanding is that they were part of an > ambitious plan from several years ago, but, as far as I can tell, > those ticket have no real purpose any more. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Mon Apr 22 17:38:52 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Mon, 22 Apr 2013 23:38:52 +0200 Subject: [SciPy-Dev] [SciPy-User] ANN: SciPy 0.12.0 release In-Reply-To: References: <5162AE5F.5090406@hilboll.de> <516A7351.7040403@hilboll.de> Message-ID: On Thu, Apr 18, 2013 at 4:33 PM, Patrick "Kai" Baker wrote: > I did that, and now SciPy 0.12 works on Python3. Thanks so much. :) But I > can't import matplotlib on Python3. > You need to install all libraries you want for the same Python version. So if you have scipy for Python 3.2 and only one matplotlib on your system for another Python version, that won't work. > Also, is SciPy 0.12 for Python3 only? > No, SciPy 0.12.0 works with Python 2.6 - 3.3. Ralf > > On Sun, Apr 14, 2013 at 5:13 AM, Andreas Hilboll wrote: > >> > > I just uploaded .deb Packages for Ubuntu 12.04LTS to >> > >> > > ppa:pylab/stable >> > >> > I just added that to my Linux Mint repository. What do I use with >> > apt-get to install your package? >> >> Hi Patrick, >> >> after the usual >> >> sudo apt-get update >> >> you can install the package with >> >> sudo apt-get install python-scipy >> >> or >> >> sudo apt-get install python3-scipy >> >> depending on which Python you're using. >> >> Cheers, A. >> > > > > -- > http://www.Kailevynskii.net/ > > _______________________________________________ > 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 josef.pktd at gmail.com Mon Apr 22 17:41:25 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Apr 2013 17:41:25 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: > > > > On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser > wrote: >> >> On 4/22/13, Skipper Seabold wrote: >> > Many of the issues have been migrated. Please have a look and let me >> > know of any problems. >> > >> > https://github.com/jseabold/scipy-trac-migration/issues?state=open >> > >> > I got rate limited by github, so I will have to continue later tonight >> > to make sure there are no problems. >> > >> > You'll notice that I used the same @ -> atmention: substitution for >> > now so that people don't get notifications, as I'm working out the >> > kinks. I used the same trac -> github mapping as the numpy migration >> > and added several more by hand of names I recognized as being a >> > duplicate e-mail address of a regular contributor. >> > >> > If we want different issue labels, let me know. It's probably easier >> > to format them now than to do it later. >> > >> > Anything else? >> >> >> Can we take this as a good time to simply drop all the "Statistics >> Review" tickets? > > > +1 But you have to separate out the empty ones, some actually contain information. Josef > > Ralf > >> >> My understanding is that they were part of an >> ambitious plan from several years ago, but, as far as I can tell, >> those ticket have no real purpose any more. > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From josef.pktd at gmail.com Mon Apr 22 19:12:48 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Apr 2013 19:12:48 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 4:34 PM, wrote: > On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold wrote: >> On Mon, Apr 22, 2013 at 3:27 PM, wrote: >>> Is there a way to get changeset links ? >>> >>> for example >>> changeset:5972 >>> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 >>> >> >> Yeah, that should be doable. I'll add it to the list. > > Thanks, > > same for tickets > ticket:1082 > 3rd comment here https://github.com/jseabold/scipy-trac-migration/issues/1081 looks like there are quite a few ways of specifying changesets/revision r6160 in last comment here https://github.com/jseabold/scipy-trac-migration/issues/992 Josef > > Josef >> >> Skipper >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev From josef.pktd at gmail.com Mon Apr 22 19:36:22 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Mon, 22 Apr 2013 19:36:22 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 7:12 PM, wrote: > On Mon, Apr 22, 2013 at 4:34 PM, wrote: >> On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold wrote: >>> On Mon, Apr 22, 2013 at 3:27 PM, wrote: >>>> Is there a way to get changeset links ? >>>> >>>> for example >>>> changeset:5972 >>>> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 >>>> >>> >>> Yeah, that should be doable. I'll add it to the list. >> >> Thanks, >> >> same for tickets >> ticket:1082 >> 3rd comment here https://github.com/jseabold/scipy-trac-migration/issues/1081 > > > looks like there are quite a few ways of specifying changesets/revision > r6160 > in last comment here https://github.com/jseabold/scipy-trac-migration/issues/992 #1394 last comment in https://github.com/jseabold/scipy-trac-migration/issues/956 > > Josef > >> >> Josef >>> >>> Skipper >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev From blake.a.griffith at gmail.com Tue Apr 23 00:13:16 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Mon, 22 Apr 2013 23:13:16 -0500 Subject: [SciPy-Dev] Adding boolean support to the sparse package, design choices Message-ID: I've been investigating how I would go about doing this, so far there seem to be three ways. (A) By keeping all the operations in python and using it's bool dtype.(B) By adding bool support to the existing C++ routines we currently have. (C) Or by converting back and forth from int8 to bool where the python and C++ interface. (A) Seems like it might be the easiest, but slowest, and inconsistent with how other types are handled. (B) Seems like the *right* way but I'm not sure how I would add bool support to the routines we have. Should I write new functions just for bool operations? Or can support for bool types be added to the existing functions? (C) I think I could do this by adding a new attribute to sparse matrices like 'native_dtype' and always convert back to it after using a C++ routine... This seems kind of hackish. I think (B) is probably the right choice. Suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.a.griffith at gmail.com Tue Apr 23 00:27:39 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Mon, 22 Apr 2013 23:27:39 -0500 Subject: [SciPy-Dev] Sparse boolean specification In-Reply-To: References: <1366646904.3110.4.camel@banach> Message-ID: Thanks for the suggestions Pauli, I've begun drafting a specification it is on GitHub: https://github.com/cowlicks/scipy-sparse-boolean-spec/blob/master/scipep.rst It's still very rough and missing a lot. There is a citation to your recommendation in there. On Mon, Apr 22, 2013 at 2:17 PM, Pauli Virtanen wrote: > 22.04.2013 21:51, Blake Griffith kirjoitti: > > So Pauli, if this is implemented as you suggest, the specification could > > recommend using the inverse of the typical bool_op. For example if you > > think that A and B are approximately equal, instead of checking with `A > > == B`. You could do `A != B` and check for an empty sparse matrix? > > > > However there does not seem to be an easy way to avoid a matrix full of > > `True`'s if you don't know much about A or B. > > I think in the typical case where sparse matrices are useful, the > matrixes contain mostly zeros, so the behavior in this case is something > like > > A == B -> mostly True > A >= B -> mostly True > A <= B -> mostly True > A != B -> mostly False > A > B -> mostly False > A < B -> mostly False > ... > > But I indeed think that we are very much constrained to make the > semantics of the comparison and boolean operators identical with how > dense arrays behave. > > The documentation/tutorial can tell the users what is efficient and what > is not, and there is also the SparseEfficiencyWarning that can be > invoked when something sub-optimal is done. > > The option of adding a special sparse array type with a nonzero > "default" value could also be possible, but it would probably require > quite a bit of work. > > -- > Pauli Virtanen > > _______________________________________________ > 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 pav at iki.fi Tue Apr 23 04:19:58 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 08:19:58 +0000 (UTC) Subject: [SciPy-Dev] =?utf-8?q?Adding_boolean_support_to_the_sparse_packag?= =?utf-8?q?e=2C=09design_choices?= References: Message-ID: Blake Griffith gmail.com> writes: [clip] > I've been investigating how I would go about doing this, > so far there seem to be three ways. (A) By keeping all the > operations in python and using it's bool dtype.(B) By adding > bool support to the existing C++ routines we currently have. > (C) Or by converting back and forth from int8 to bool where > the python and C++ interface. [clip] > (B) Seems like the *right* way but I'm not sure how I would > add bool support to the routines we have. Should I write > new functions just for bool operations? Or can support for > bool types be added to the existing functions? [clip] I think this can be done by adding to the sparsetools/*.h files new routines such as #define COMPARE_EQ 0 #define COMPARE_GT 1 #define COMPARE_LT 2 ... template void csr_cmp_csr(const I n_row, const I n_col, const I Ap[], const I Aj[], const T Ax[], const I Bp[], const I Bj[], const T Bx[], I Cp[], I Cj[], T2 Cx[], int cmpflag) { if (cmpflag == COMPARE_EQ) { csr_binop_csr(n_row,n_col,Ap,Aj,Ax,Bp,Bj,Bx,Cp,Cj,Cx,std::equal_to()); } else if ... } Note that the generic code doing the heavy lifting for binary operations is already there, so you can just use those functions. What needs to be changed is: - Change the csr_binop_csr C++ templates (and ditto for the other routines) so that the return type can be different from the input argument types. I.e., add a new template type as above. - Read on SWIG type maps and try to understand how they work. Best place to start is probably the SWIG documentation, and to try some simple examples first. - Add new type maps for the comparison routines, with signatures T, T -> bool - Add type maps for logical operation routines (or, and, xor, ...) with signatures bool, bool -> bool - The numerical type used for booleans internally inside sparsetools should be int8/char (the builtin C++ bool type can be bigger than int8). - SWIG can be told to dispatch differently for NPY_BOOL and NPY_INT8 arrays. You probably need to look inside numpy.i how this magic happens. -- Pauli Virtanen From pav at iki.fi Tue Apr 23 04:23:39 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 08:23:39 +0000 (UTC) Subject: [SciPy-Dev] issues trac migration review References: Message-ID: gmail.com> writes: [clip] > looks like there are quite a few ways of specifying changesets/revision > r6160 Those could be mapped to Git commit IDs. I don't have the mapping any more, but it should be possible to reconstruct it by comparing the commit times in the svn log and git log. The SVN repo is offline, so you'll need to log on projects.scipy.org to get the log. -- Pauli Virtanen From pav at iki.fi Tue Apr 23 04:28:20 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 08:28:20 +0000 (UTC) Subject: [SciPy-Dev] =?utf-8?q?Adding_boolean_support_to_the_sparse_packag?= =?utf-8?q?e=2C=09design_choices?= References: Message-ID: Pauli Virtanen iki.fi> writes: [clip] > - Read on SWIG type maps and try to understand how they work. > Best place to start is probably the SWIG documentation, and to try > some simple examples first. Btw, look at the code SWIG generates in the cxx files. It's pretty funny --- and probably the reason for the ballooning compile times of these files. -- Pauli Virtanen From jsseabold at gmail.com Tue Apr 23 08:13:32 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 08:13:32 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 4:35 PM, Pauli Virtanen wrote: > 22.04.2013 22:42, Skipper Seabold kirjoitti: > [clip] >> As for new data submissions...well...open issue I guess. Github >> accepts image attachments and posts them to their server on amazon. I >> assume this functionality will be extended at some point. They've been >> talking about it for 4 years now. We could instruct people to use >> e-mail attachments and post them to the list then link to the message >> in the issue? > > E-mail has the problem that it spams N+1 people who are not interested > in the potentially big data file, plus it's a hassle to subscribe to the > list so that you can post. > > It probably needs to be something simple, otherwise what happens is > dropbox/mediafire/ad-supported-upload-service-of-your-choice which do > not necessarily have a very long lifetimes. > > A third-party web app can use Github for authentication: > http://developer.github.com/v3/oauth/ > But nobody seems to have written so far (or at least I can't find) > something that does this. Might this be something we could use scipy-central for? I don't know anything about that server setup / file attachment situation. Just an idea. Still not zero effort. We might also consider setting up using projects.scipy.org to allow scp of files, though I wouldn't want to volunteer anyone to be the ssh key gatekeeper (I guess it should be keymaster) and you still have to copy the link over. Skipper From jsseabold at gmail.com Tue Apr 23 08:24:27 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 08:24:27 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 4:23 AM, Pauli Virtanen wrote: > gmail.com> writes: > [clip] >> looks like there are quite a few ways of specifying changesets/revision >> r6160 > > Those could be mapped to Git commit IDs. I don't have the mapping > any more, but it should be possible to reconstruct it by comparing > the commit times in the svn log and git log. > > The SVN repo is offline, so you'll need to log on projects.scipy.org > to get the log. > Using git svn find-rev rXXXX should work, but there's either a missing mapping in .git/svn or a version compatibility problem with my git-svn. I'll see what I can do. Skipper From jsseabold at gmail.com Tue Apr 23 08:53:15 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 08:53:15 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 5:41 PM, wrote: > On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>> Can we take this as a good time to simply drop all the "Statistics >>> Review" tickets? >> >> +1 > > But you have to separate out the empty ones, some actually contain information. Do you have an example of one that has any information? Github or trac is fine, but I haven't found one yet. Skipper From lists at hilboll.de Tue Apr 23 09:19:18 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Tue, 23 Apr 2013 15:19:18 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: <51768A56.9090601@hilboll.de> >>> As for new data submissions...well...open issue I guess. Github >>> accepts image attachments and posts them to their server on amazon. I >>> assume this functionality will be extended at some point. They've been >>> talking about it for 4 years now. We could instruct people to use >>> e-mail attachments and post them to the list then link to the message >>> in the issue? >> >> E-mail has the problem that it spams N+1 people who are not interested >> in the potentially big data file, plus it's a hassle to subscribe to the >> list so that you can post. >> >> It probably needs to be something simple, otherwise what happens is >> dropbox/mediafire/ad-supported-upload-service-of-your-choice which do >> not necessarily have a very long lifetimes. >> >> A third-party web app can use Github for authentication: >> http://developer.github.com/v3/oauth/ >> But nobody seems to have written so far (or at least I can't find) >> something that does this. > > Might this be something we could use scipy-central for? I don't know > anything about that server setup / file attachment situation. Just an > idea. Still not zero effort. +1 From josef.pktd at gmail.com Tue Apr 23 10:14:42 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:14:42 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 8:53 AM, Skipper Seabold wrote: > On Mon, Apr 22, 2013 at 5:41 PM, wrote: >> On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >>> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>>> Can we take this as a good time to simply drop all the "Statistics >>>> Review" tickets? >>> >>> +1 >> >> But you have to separate out the empty ones, some actually contain information. > > Do you have an example of one that has any information? Github or trac > is fine, but I haven't found one yet. I usually sorted by last change date. firefox just crashed, so it will take some time to find some again. https://github.com/jseabold/scipy-trac-migration/issues/171 github issues sort by "recently updated" will be useless. open http://projects.scipy.org/scipy/ticket/74 closed http://projects.scipy.org/scipy/ticket/113 http://projects.scipy.org/scipy/ticket/105 I guess most closed tickets where closed intentionally http://projects.scipy.org/scipy/query?status=apply&status=closed&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&component=scipy.stats&order=priority I see only two open ones here http://projects.scipy.org/scipy/query?status=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&component=scipy.stats&order=priority I don't have my password right now to write a custom report like http://projects.scipy.org/scipy/report/11 Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From jsseabold at gmail.com Tue Apr 23 10:17:10 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 10:17:10 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:14 AM, wrote: > On Tue, Apr 23, 2013 at 8:53 AM, Skipper Seabold wrote: >> On Mon, Apr 22, 2013 at 5:41 PM, wrote: >>> On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >>>> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>>>> Can we take this as a good time to simply drop all the "Statistics >>>>> Review" tickets? >>>> >>>> +1 >>> >>> But you have to separate out the empty ones, some actually contain information. >> >> Do you have an example of one that has any information? Github or trac >> is fine, but I haven't found one yet. > > I usually sorted by last change date. > Good idea. Ok, I'll just keep all the ones that have any comment history. Skipper From josef.pktd at gmail.com Tue Apr 23 10:20:46 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:20:46 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:17 AM, Skipper Seabold wrote: > On Tue, Apr 23, 2013 at 10:14 AM, wrote: >> On Tue, Apr 23, 2013 at 8:53 AM, Skipper Seabold wrote: >>> On Mon, Apr 22, 2013 at 5:41 PM, wrote: >>>> On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >>>>> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>>>>> Can we take this as a good time to simply drop all the "Statistics >>>>>> Review" tickets? >>>>> >>>>> +1 >>>> >>>> But you have to separate out the empty ones, some actually contain information. >>> >>> Do you have an example of one that has any information? Github or trac >>> is fine, but I haven't found one yet. >> >> I usually sorted by last change date. >> > > Good idea. Ok, I'll just keep all the ones that have any comment history. Or somebody finishes up the Statistics Review. (Should be almost done anyway, at least basic check.) I cannot even find anymore what's still open and empty. Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From josef.pktd at gmail.com Tue Apr 23 10:28:47 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:28:47 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:20 AM, wrote: > On Tue, Apr 23, 2013 at 10:17 AM, Skipper Seabold wrote: >> On Tue, Apr 23, 2013 at 10:14 AM, wrote: >>> On Tue, Apr 23, 2013 at 8:53 AM, Skipper Seabold wrote: >>>> On Mon, Apr 22, 2013 at 5:41 PM, wrote: >>>>> On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >>>>>> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>>>>>> Can we take this as a good time to simply drop all the "Statistics >>>>>>> Review" tickets? >>>>>> >>>>>> +1 >>>>> >>>>> But you have to separate out the empty ones, some actually contain information. >>>> >>>> Do you have an example of one that has any information? Github or trac >>>> is fine, but I haven't found one yet. >>> >>> I usually sorted by last change date. >>> >> >> Good idea. Ok, I'll just keep all the ones that have any comment history. > > Or somebody finishes up the Statistics Review. > (Should be almost done anyway, at least basic check.) > > I cannot even find anymore what's still open and empty. Ok found them http://projects.scipy.org/scipy/report/11?USER=anonymous&page=5 There are still a lot of empty ones. Quite a few of the functions have been checked (and fixed) with other tickets. Deleting them sounds ok, since there hasn't been any volunteers to check them one by one. Josef > > Josef > >> >> Skipper >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev From josef.pktd at gmail.com Tue Apr 23 10:30:54 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:30:54 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:28 AM, wrote: > On Tue, Apr 23, 2013 at 10:20 AM, wrote: >> On Tue, Apr 23, 2013 at 10:17 AM, Skipper Seabold wrote: >>> On Tue, Apr 23, 2013 at 10:14 AM, wrote: >>>> On Tue, Apr 23, 2013 at 8:53 AM, Skipper Seabold wrote: >>>>> On Mon, Apr 22, 2013 at 5:41 PM, wrote: >>>>>> On Mon, Apr 22, 2013 at 5:17 PM, Ralf Gommers wrote: >>>>>>> On Mon, Apr 22, 2013 at 11:14 PM, Warren Weckesser >>>>>>>> Can we take this as a good time to simply drop all the "Statistics >>>>>>>> Review" tickets? >>>>>>> >>>>>>> +1 >>>>>> >>>>>> But you have to separate out the empty ones, some actually contain information. >>>>> >>>>> Do you have an example of one that has any information? Github or trac >>>>> is fine, but I haven't found one yet. >>>> >>>> I usually sorted by last change date. >>>> >>> >>> Good idea. Ok, I'll just keep all the ones that have any comment history. >> >> Or somebody finishes up the Statistics Review. >> (Should be almost done anyway, at least basic check.) >> >> I cannot even find anymore what's still open and empty. > > Ok found them http://projects.scipy.org/scipy/report/11?USER=anonymous&page=5 > There are still a lot of empty ones. > > Quite a few of the functions have been checked (and fixed) with other tickets. > Deleting them sounds ok, since there hasn't been any volunteers to check them > one by one. Checking issues without comments works on github https://github.com/jseabold/scipy-trac-migration/issues?direction=asc&labels=component%3A+scipy.stats&page=1&sort=comments&state=open Josef > > Josef > >> >> Josef >> >>> >>> Skipper >>> _______________________________________________ >>> SciPy-Dev mailing list >>> SciPy-Dev at scipy.org >>> http://mail.scipy.org/mailman/listinfo/scipy-dev From josef.pktd at gmail.com Tue Apr 23 10:35:03 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:35:03 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: new problem: false links, cross references https://github.com/jseabold/scipy-trac-migration/issues/71 triggered by #71 in description of https://github.com/jseabold/scipy-trac-migration/issues/550 ``` Python Version: 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] ``` Josef From josef.pktd at gmail.com Tue Apr 23 10:51:42 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:51:42 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:35 AM, wrote: > new problem: false links, cross references > > https://github.com/jseabold/scipy-trac-migration/issues/71 > triggered by #71 in description of > https://github.com/jseabold/scipy-trac-migration/issues/550 > > ``` > Python Version: > 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] > ``` That's a problem with not using literal {{{ }}} not with github transition the Trac ticket has the same cross-link http://projects.scipy.org/scipy/ticket/550 Trac just doesn't show the back-link. I don't think there is anything to fix automatically. Josef > > Josef From josef.pktd at gmail.com Tue Apr 23 10:51:42 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 10:51:42 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 10:35 AM, wrote: > new problem: false links, cross references > > https://github.com/jseabold/scipy-trac-migration/issues/71 > triggered by #71 in description of > https://github.com/jseabold/scipy-trac-migration/issues/550 > > ``` > Python Version: > 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] > ``` That's a problem with not using literal {{{ }}} not with github transition the Trac ticket has the same cross-link http://projects.scipy.org/scipy/ticket/550 Trac just doesn't show the back-link. I don't think there is anything to fix automatically. Josef > > Josef From pav at iki.fi Tue Apr 23 12:26:49 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 19:26:49 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 23.04.2013 17:28, josef.pktd at gmail.com kirjoitti: [clip] > Quite a few of the functions have been checked (and fixed) with other tickets. > Deleting them sounds ok, since there hasn't been any volunteers to check them > one by one. There are only two open tickets left in the stats review. I don't think there's a particular reason to delete them, closing them can be enough if they are not useful. http://projects.scipy.org/scipy/query?status=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&summary=~review&order=priority -- Pauli Virtanen From josef.pktd at gmail.com Tue Apr 23 12:35:00 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 12:35:00 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 12:26 PM, Pauli Virtanen wrote: > 23.04.2013 17:28, josef.pktd at gmail.com kirjoitti: > [clip] >> Quite a few of the functions have been checked (and fixed) with other tickets. >> Deleting them sounds ok, since there hasn't been any volunteers to check them >> one by one. > > There are only two open tickets left in the stats review. I don't think > there's a particular reason to delete them, closing them can be enough > if they are not useful. > > http://projects.scipy.org/scipy/query?status=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&summary=~review&order=priority Something has changed in trac some time ago that they don't show up anymore in this view. They are still there somewhere (for example at end of report/11), and will get added to the github issues https://github.com/jseabold/scipy-trac-migration/issues?direction=asc&labels=component%3A+scipy.stats&page=1&sort=comments&state=open Josef > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From pav at iki.fi Tue Apr 23 12:30:03 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 19:30:03 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 23.04.2013 15:13, Skipper Seabold kirjoitti: [clip] > Might this be something we could use scipy-central for? I don't know > anything about that server setup / file attachment situation. Just an > idea. Still not zero effort. I don't think it can be directly used, and using it for dumping generally useless stuff (except for the specific bug report) doesn't align with the purpose of the site. A separate file upload form can be written in a couple of hours or so if we want to go that way. That's an extra system to maintain. The only question is account management, but as noted, it's possible to reuse Github's authentication for that. -- Pauli Virtanen From pav at iki.fi Tue Apr 23 12:51:12 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 23 Apr 2013 19:51:12 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 23.04.2013 19:35, josef.pktd at gmail.com kirjoitti: > On Tue, Apr 23, 2013 at 12:26 PM, Pauli Virtanen wrote: [clip] >> There are only two open tickets left in the stats review. I don't think >> there's a particular reason to delete them, closing them can be enough >> if they are not useful. >> >> http://projects.scipy.org/scipy/query?status=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&summary=~review&order=priority > > Something has changed in trac some time ago that they don't show up > anymore in this view. [clip] I see --- they're in the accepted status which is no longer present. They do appear if you remove the status filter. Well, seems there are still several left over, so either closing or deleting propably goes. -- Pauli Virtanen From josef.pktd at gmail.com Tue Apr 23 12:56:40 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 12:56:40 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 12:35 PM, wrote: > On Tue, Apr 23, 2013 at 12:26 PM, Pauli Virtanen wrote: >> 23.04.2013 17:28, josef.pktd at gmail.com kirjoitti: >> [clip] >>> Quite a few of the functions have been checked (and fixed) with other tickets. >>> Deleting them sounds ok, since there hasn't been any volunteers to check them >>> one by one. >> >> There are only two open tickets left in the stats review. I don't think >> there's a particular reason to delete them, closing them can be enough >> if they are not useful. >> >> http://projects.scipy.org/scipy/query?status=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&summary=~review&order=priority > > Something has changed in trac some time ago that they don't show up > anymore in this view. the empty (?) review tickets have status=accepted which is not one of the standard options http://projects.scipy.org/scipy/query?status=accepted&summary=~review&order=priority I changed the status and milestone for some of the review tickets Josef > > They are still there somewhere (for example at end of report/11), and > will get added to the github issues > > https://github.com/jseabold/scipy-trac-migration/issues?direction=asc&labels=component%3A+scipy.stats&page=1&sort=comments&state=open > > Josef > >> >> -- >> Pauli Virtanen >> >> _______________________________________________ >> SciPy-Dev mailing list >> SciPy-Dev at scipy.org >> http://mail.scipy.org/mailman/listinfo/scipy-dev From jsseabold at gmail.com Tue Apr 23 12:56:21 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 12:56:21 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 7:12 PM, wrote: > On Mon, Apr 22, 2013 at 4:34 PM, wrote: >> On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold wrote: >>> On Mon, Apr 22, 2013 at 3:27 PM, wrote: >>>> Is there a way to get changeset links ? >>>> >>>> for example >>>> changeset:5972 >>>> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 >>>> >>> >>> Yeah, that should be doable. I'll add it to the list. >> >> Thanks, >> >> same for tickets >> ticket:1082 >> 3rd comment here https://github.com/jseabold/scipy-trac-migration/issues/1081 > > > looks like there are quite a few ways of specifying changesets/revision > r6160 > in last comment here https://github.com/jseabold/scipy-trac-migration/issues/992 > I'm only grabbing the ones that are specified changeset:XXXX and rXXX. Y'all are more familiar with trac. Is this sufficient? Do people use the [XXX] traclinks? Are there any other traclinks that I should look out for? It doesn't look like there is much use of ticket:XXXX but rather #XXX. There are some cross links to numpy tickets that I can probably update to numpy's github issue tracker, but I'd prefer to do this only if you think it's worth it. Let me know. Skipper From josef.pktd at gmail.com Tue Apr 23 13:05:14 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Tue, 23 Apr 2013 13:05:14 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 12:56 PM, Skipper Seabold wrote: > On Mon, Apr 22, 2013 at 7:12 PM, wrote: >> On Mon, Apr 22, 2013 at 4:34 PM, wrote: >>> On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold wrote: >>>> On Mon, Apr 22, 2013 at 3:27 PM, wrote: >>>>> Is there a way to get changeset links ? >>>>> >>>>> for example >>>>> changeset:5972 >>>>> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/620 >>>>> >>>> >>>> Yeah, that should be doable. I'll add it to the list. >>> >>> Thanks, >>> >>> same for tickets >>> ticket:1082 >>> 3rd comment here https://github.com/jseabold/scipy-trac-migration/issues/1081 >> >> >> looks like there are quite a few ways of specifying changesets/revision >> r6160 >> in last comment here https://github.com/jseabold/scipy-trac-migration/issues/992 >> > > I'm only grabbing the ones that are specified changeset:XXXX and rXXX. > Y'all are more familiar with trac. Is this sufficient? Do people use > the [XXX] traclinks? > > Are there any other traclinks that I should look out for? It doesn't > look like there is much use of ticket:XXXX but rather #XXX. There are > some cross links to numpy tickets that I can probably update to > numpy's github issue tracker, but I'd prefer to do this only if you > think it's worth it. Let me know. I think I used only these 4 changeset:XXXX and rXXX ticket:XXXX and #XXX none of the other ones look very familiar http://projects.scipy.org/scipy/wiki/TracLinks Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From warren.weckesser at gmail.com Tue Apr 23 13:06:11 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Tue, 23 Apr 2013 13:06:11 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 12:56 PM, Skipper Seabold wrote: > On Mon, Apr 22, 2013 at 7:12 PM, wrote: > > On Mon, Apr 22, 2013 at 4:34 PM, wrote: > >> On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold > wrote: > >>> On Mon, Apr 22, 2013 at 3:27 PM, wrote: > >>>> Is there a way to get changeset links ? > >>>> > >>>> for example > >>>> changeset:5972 > >>>> in last comment here > https://github.com/jseabold/scipy-trac-migration/issues/620 > >>>> > >>> > >>> Yeah, that should be doable. I'll add it to the list. > >> > >> Thanks, > >> > >> same for tickets > >> ticket:1082 > >> 3rd comment here > https://github.com/jseabold/scipy-trac-migration/issues/1081 > > > > > > looks like there are quite a few ways of specifying changesets/revision > > r6160 > > in last comment here > https://github.com/jseabold/scipy-trac-migration/issues/992 > > > > I'm only grabbing the ones that are specified changeset:XXXX and rXXX. > Y'all are more familiar with trac. Is this sufficient? Do people use > the [XXX] traclinks? > > Are there any other traclinks that I should look out for? It doesn't > look like there is much use of ticket:XXXX but rather #XXX. There are > some cross links to numpy tickets that I can probably update to > numpy's github issue tracker, but I'd prefer to do this only if you > think it's worth it. Let me know. > > There is commit: which links to the commit on github. See, for example, http://projects.scipy.org/scipy/ticket/1896 Warren Skipper > _______________________________________________ > 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 jsseabold at gmail.com Tue Apr 23 13:49:47 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Tue, 23 Apr 2013 13:49:47 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Tue, Apr 23, 2013 at 1:06 PM, Warren Weckesser wrote: > > On Tue, Apr 23, 2013 at 12:56 PM, Skipper Seabold > wrote: >> >> On Mon, Apr 22, 2013 at 7:12 PM, wrote: >> > On Mon, Apr 22, 2013 at 4:34 PM, wrote: >> >> On Mon, Apr 22, 2013 at 3:48 PM, Skipper Seabold >> >> wrote: >> >>> On Mon, Apr 22, 2013 at 3:27 PM, wrote: >> >>>> Is there a way to get changeset links ? >> >>>> >> >>>> for example >> >>>> changeset:5972 >> >>>> in last comment here >> >>>> https://github.com/jseabold/scipy-trac-migration/issues/620 >> >>>> >> >>> >> >>> Yeah, that should be doable. I'll add it to the list. >> >> >> >> Thanks, >> >> >> >> same for tickets >> >> ticket:1082 >> >> 3rd comment here >> >> https://github.com/jseabold/scipy-trac-migration/issues/1081 >> > >> > >> > looks like there are quite a few ways of specifying changesets/revision >> > r6160 >> > in last comment here >> > https://github.com/jseabold/scipy-trac-migration/issues/992 >> > >> >> I'm only grabbing the ones that are specified changeset:XXXX and rXXX. >> Y'all are more familiar with trac. Is this sufficient? Do people use >> the [XXX] traclinks? >> >> Are there any other traclinks that I should look out for? It doesn't >> look like there is much use of ticket:XXXX but rather #XXX. There are >> some cross links to numpy tickets that I can probably update to >> numpy's github issue tracker, but I'd prefer to do this only if you >> think it's worth it. Let me know. >> > > > There is commit: which links to the commit on github. See, for > example, http://projects.scipy.org/scipy/ticket/1896 > Thanks, that one should be handled from the numpy migration. I was wondering what that code was for... Skipper From ewm at redtetrahedron.org Tue Apr 23 21:22:32 2013 From: ewm at redtetrahedron.org (Eric Moore) Date: Tue, 23 Apr 2013 21:22:32 -0400 Subject: [SciPy-Dev] commit rights for Eric Moore In-Reply-To: References: <516AAB02.3030209@laxalde.org> Message-ID: <517733D8.2060107@redtetrahedron.org> Ralf Gommers wrote: > > > > On Sun, Apr 14, 2013 at 3:11 PM, Denis Laxalde > wrote: > > Ralf Gommers a ?crit : > > > Eric Moore has been a regular contributor to Scipy (and Numpy) in the > > past half year or so - he has for example added > signal.periodogram/welch > > and improved the orthogonal poly support in scipy.special. Since > those > > contributions were of high quality, I've asked him if he plans to > > continue contributing and is interested in obtaining commit > rights for > > Scipy. To which his answer is yes/yes. So I propose to give him those > > rights. > > > > Do you all agree with that? > > Yes. > > > Great, done! > > Ralf > > Thanks! I'm excited. I'm sorry I didn't say anything here earlier. -Eric From andyfaff at gmail.com Wed Apr 24 13:13:26 2013 From: andyfaff at gmail.com (Andrew Nelson) Date: Wed, 24 Apr 2013 13:13:26 -0400 Subject: [SciPy-Dev] Adding startiter keyword to scipy.integrate.quadrature Message-ID: Dear dev list, please forgive any glaring faux pas I might make. This is my first time contributing to scipy development. I am proposing to add the 'startiter' keyword to scipy.integrate.quadrature. At the moment the adaptive quadrature starts from a Gaussian quadrature order of 1 and finishes when maxiter iterations are reached (unless the termination criteria are met). For the problem I deal with I know that I have to start iteration from approx. order 15 onwards. Which means that orders 1 through 14 are wasted. This would correspond to 105 calculations of the function to be integrated (1+2+3+4...+14). Adding the startiter keyword enables one to start at an arbitrary order, saving a reasonable amount of calculation time. Would such this addition be suitable for inclusion into scipy? If so, I can prepare a pull request. regards, Andrew. -- _____________________________________ Dr. Andrew Nelson _____________________________________ From jsseabold at gmail.com Wed Apr 24 14:00:01 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 24 Apr 2013 14:00:01 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: Round 2. I got github to temporarily up the rate limit for this, so it's great if we can finish in the next 2 days. Since I'm using oauth now, I moved the issues to https://github.com/scipy-gitbot/scipy-trac-migration/issues Some issues that were raised upthread about traclinks. These should be fixed now. Let me know if you see any that aren't. I assume the hash will be a correct link in the scipy repo, but I can change it to be an absolute URL to be sure if needed. r5205 in second to last comment https://github.com/scipy-gitbot/scipy-trac-migration/issues/620 ticket: in issue body here https://github.com/scipy-gitbot/scipy-trac-migration/issues/1620 changset: in first comment https://github.com/scipy-gitbot/scipy-trac-migration/issues/837 #1394 in last comment here https://github.com/scipy-gitbot/scipy-trac-migration/issues/956 A decent amount of the SVN revision numbers are not in git. If you still see a rXXXX, it was either not in git or had some formatting issue in the commit message that I didn't properly escape for when calling git log --grep. Let me know if you think it's the latter. I had some problems with PyGithub that should now be fixed. To make sure nothing comes up during the real deal, I'll do one more dry-run this afternoon to be sure there are no hiccups, then hopefully we can do the migration tonight or sometime tomorrow, though I'll need some help on the on the scipy repo end. For posterity, if anyone is also wanted to use this code, I had to make some changes to the numpy migration code and patch PyGithub for correctly doing oauth authentication. https://github.com/jseabold/scipy-trac-migration Skipper From ralf.gommers at gmail.com Wed Apr 24 14:12:27 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 24 Apr 2013 20:12:27 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 8:00 PM, Skipper Seabold wrote: > Round 2. I got github to temporarily up the rate limit for this, so > it's great if we can finish in the next 2 days. Since I'm using oauth > now, I moved the issues to > > https://github.com/scipy-gitbot/scipy-trac-migration/issues > > Some issues that were raised upthread about traclinks. These should be > fixed now. Let me know if you see any that aren't. I assume the hash > will be a correct link in the scipy repo, but I can change it to be an > absolute URL to be sure if needed. > Hash should work. If it's easy to do, can we use gh-1234 instead of #1234 for issue numbering on Github? Otherwise things are more confusing, since comments in the code using # refer to Trac now. We should keep that habit also for future commits. > r5205 in second to last comment > https://github.com/scipy-gitbot/scipy-trac-migration/issues/620 > > ticket: in issue body here > https://github.com/scipy-gitbot/scipy-trac-migration/issues/1620 > > changset: in first comment > https://github.com/scipy-gitbot/scipy-trac-migration/issues/837 > > #1394 in last comment here > https://github.com/scipy-gitbot/scipy-trac-migration/issues/956 > > A decent amount of the SVN revision numbers are not in git. Any idea how that happened? > If you still see a rXXXX, it was either not in git or had some formatting > issue in the commit message that I didn't properly escape for when > calling git log --grep. Let me know if you think it's the latter. > > I had some problems with PyGithub that should now be fixed. To make > sure nothing comes up during the real deal, I'll do one more dry-run > this afternoon to be sure there are no hiccups, then hopefully we can > do the migration tonight or sometime tomorrow, though I'll need some > help on the on the scipy repo end. > I can turn on Issues now, and give you push access (you need those I guess?). Anything else? Cheers, Ralf > For posterity, if anyone is also wanted to use this code, I had to > make some changes to the numpy migration code and patch PyGithub for > correctly doing oauth authentication. > > https://github.com/jseabold/scipy-trac-migration > > Skipper > _______________________________________________ > 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 jsseabold at gmail.com Wed Apr 24 14:26:09 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 24 Apr 2013 14:26:09 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 2:12 PM, Ralf Gommers wrote: > On Wed, Apr 24, 2013 at 8:00 PM, Skipper Seabold > wrote: >> >> Round 2. I got github to temporarily up the rate limit for this, so >> it's great if we can finish in the next 2 days. Since I'm using oauth >> now, I moved the issues to >> >> https://github.com/scipy-gitbot/scipy-trac-migration/issues >> >> Some issues that were raised upthread about traclinks. These should be >> fixed now. Let me know if you see any that aren't. I assume the hash >> will be a correct link in the scipy repo, but I can change it to be an >> absolute URL to be sure if needed. > > > Hash should work. > > If it's easy to do, can we use gh-1234 instead of #1234 for issue numbering > on Github? Otherwise things are more confusing, since comments in the code > using # refer to Trac now. We should keep that habit also for future > commits. Should be easy enough to do in the migration. Can't speak for changing old habits. > >> >> r5205 in second to last comment >> https://github.com/scipy-gitbot/scipy-trac-migration/issues/620 >> >> ticket: in issue body here >> https://github.com/scipy-gitbot/scipy-trac-migration/issues/1620 >> >> changset: in first comment >> https://github.com/scipy-gitbot/scipy-trac-migration/issues/837 >> >> #1394 in last comment here >> https://github.com/scipy-gitbot/scipy-trac-migration/issues/956 >> >> A decent amount of the SVN revision numbers are not in git. > > > Any idea how that happened? No idea. Some look like commits for things that were removed from github - maybe deprecated modules. Some were commits that may have been later backed out. Some svnmerge commits. Some were commits without a commit message. I filter on the commit dates, so I should even be picking up the ambiguous commit messages from the early days though. I can post some examples if it's worth it. > >> >> If you still see a rXXXX, it was either not in git or had some formatting >> issue in the commit message that I didn't properly escape for when >> calling git log --grep. Let me know if you think it's the latter. >> >> I had some problems with PyGithub that should now be fixed. To make >> sure nothing comes up during the real deal, I'll do one more dry-run >> this afternoon to be sure there are no hiccups, then hopefully we can >> do the migration tonight or sometime tomorrow, though I'll need some >> help on the on the scipy repo end. > > > I can turn on Issues now, and give you push access (you need those I > guess?). Anything else? IIUC, I won't need push access through the web ui, I'll need someone to get me a token for the oauth app running the code in the docstring here https://github.com/jseabold/scipy-trac-migration/blob/master/ghissues.py It's not clear to me how to do this without giving you the client_secret, so we can figure this out off list. > > Cheers, > Ralf > > >> >> For posterity, if anyone is also wanted to use this code, I had to >> make some changes to the numpy migration code and patch PyGithub for >> correctly doing oauth authentication. >> >> https://github.com/jseabold/scipy-trac-migration >> >> Skipper >> >> _______________________________________________ >> 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 > From jsseabold at gmail.com Wed Apr 24 14:32:56 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 24 Apr 2013 14:32:56 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 2:26 PM, Skipper Seabold wrote: > On Wed, Apr 24, 2013 at 2:12 PM, Ralf Gommers wrote: >> I can turn on Issues now, and give you push access (you need those I >> guess?). Anything else? > The other thing is trac. I don't know about the timing for making trac read only. People are still commenting on tickets / filing new ones today. > IIUC, I won't need push access through the web ui, I'll need someone > to get me a token for the oauth app running the code in the docstring > here > > https://github.com/jseabold/scipy-trac-migration/blob/master/ghissues.py > > It's not clear to me how to do this without giving you the > client_secret, so we can figure this out off list. Oh, nevermind. I run the code with client_secret. I just need someone with scipy commit rights to authorize the app for the scipy repo and send me the token that's returned after authorizing. We can still work this out off list. Skipper From ralf.gommers at gmail.com Wed Apr 24 14:43:42 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 24 Apr 2013 20:43:42 +0200 Subject: [SciPy-Dev] GSoC application time! Message-ID: Hi, This is for all students planning to put in a GSoC'13 application for Numpy/Scipy. As you probably noticed, you are now able to submit your application in Melange. We're participating under the PSF org. Terri Oda, who is the PSF organizer, sent out the below announcement with tips and requirements as well as a helpful application template - please read those. When you have a draft proposal ready, I suggest you a) submit it already, since you can edit it later b) discuss it on the numpy-discussion or scipy-dev list If you haven't submitted a pull request yet, it's a good idea to do so asap - getting your first patch merged may be nontrivial and require some rework, so don't wait till the last day! Of all the requirements, I want to stress that discussing your proposal and interacting with the community is especially important. Not only will it help improve your proposal, it is also something we will pay attention to when ranking the proposals. Reason: it's a good predictor of the success of your project, both in terms of code/features contributed and of whether you're interested and likely to stay involved after GSoC ends. The latter is at least as important to us as the former. Cheers, Ralf P.S. I will be offline from April 25th to 29th. ---------- Forwarded message ---------- From: Terri Oda Date: Mon, Apr 22, 2013 at 12:22 AM Subject: [Soc2013-general] Student Application Template (Applications start April 22!) To: soc2013-general at python.org As hopefully all of you are aware, student applications to GSoC will be opening April 22 19:00 UTC (tomorrow to me) and closing May 3rd. I highly recommend that you all submit applications early -- you can modify them up until the final deadline. Google will not extend the deadline for any reason, including technical problems with the melange system (which have been known to happen at the last minute in the past), so the sooner you can get an application in the better! We have a template to help you prepare your application with the PSF: http://wiki.python.org/moin/**SummerOfCode/**ApplicationTemplate2013 Your sub-organizations may have additional requirements; ask them if there's any extra information they need from you. Please note a few things we ask for that are not always required by other orgs: * We do require students to blog about their projects, so you will need to set up a GSoC blog for weekly status updates and any other thoughts you wish to record about your project. * We do require students to submit a link to some sort of code sample, preferably a patch to the sub-org to which you are applying. Talk to your mentors if you're uncertain what would be appropriate. * Don't forget to put the name of your sub-organization (e.g. OpenHatch, MNE-Python) into the title of your application. If you're not sure about how to write a good proposal, ask your prospective mentors: they're the ones who will be deciding if they hire you or not, so they get the final word as to what a good proposal looks like for them. Terri ______________________________**_________________ Soc2013-general mailing list Soc2013-general at python.org http://mail.python.org/**mailman/listinfo/soc2013-**general -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Wed Apr 24 14:50:30 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 24 Apr 2013 20:50:30 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 8:32 PM, Skipper Seabold wrote: > On Wed, Apr 24, 2013 at 2:26 PM, Skipper Seabold > wrote: > > On Wed, Apr 24, 2013 at 2:12 PM, Ralf Gommers > wrote: > >> I can turn on Issues now, and give you push access (you need those I > >> guess?). Anything else? > > > > The other thing is trac. I don't know about the timing for making trac > read only. People are still commenting on tickets / filing new ones > today. > Good point. That actually didn't work well for the numpy move - I think it's still not read-only. Who knows about Trac and has admin rights? Can we make it read-only before Skipper starts uploading issues? Not being able to comment on existing tickets for a day would be better than losing those comments. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Wed Apr 24 15:51:23 2013 From: pav at iki.fi (Pauli Virtanen) Date: Wed, 24 Apr 2013 22:51:23 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 24.04.2013 21:50, Ralf Gommers kirjoitti: [clip] > Good point. That actually didn't work well for the numpy move - I think > it's still not read-only. Who knows about Trac and has admin rights? Can > we make it read-only before Skipper starts uploading issues? Not being > able to comment on existing tickets for a day would be better than > losing those comments. The Numpy Trac was made read-only in the sense that you cannot add new tickets, but only some days after the transition. I have necessary admin rights to make the changes. We can make the Trac temporarily read-only for some time, if there's a timeline for the transition. -- Pauli Virtanen From jsseabold at gmail.com Wed Apr 24 16:59:18 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 24 Apr 2013 16:59:18 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 3:51 PM, Pauli Virtanen wrote: > 24.04.2013 21:50, Ralf Gommers kirjoitti: > [clip] >> Good point. That actually didn't work well for the numpy move - I think >> it's still not read-only. Who knows about Trac and has admin rights? Can >> we make it read-only before Skipper starts uploading issues? Not being >> able to comment on existing tickets for a day would be better than >> losing those comments. > > The Numpy Trac was made read-only in the sense that you cannot add new > tickets, but only some days after the transition. > > I have necessary admin rights to make the changes. We can make the Trac > temporarily read-only for some time, if there's a timeline for the > transition. I'm doing what is hopefully a last test run now. Whenever it's done 1-2 hours, provided everything is fine, I can do the final move. Also, it turns out it is probably easier if the scipy-gitbot account has write access to the scipy repo. Thanks, Skipper From ralf.gommers at gmail.com Wed Apr 24 17:13:01 2013 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 24 Apr 2013 23:13:01 +0200 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 9:51 PM, Pauli Virtanen wrote: > 24.04.2013 21:50, Ralf Gommers kirjoitti: > [clip] > > Good point. That actually didn't work well for the numpy move - I think > > it's still not read-only. Who knows about Trac and has admin rights? Can > > we make it read-only before Skipper starts uploading issues? Not being > > able to comment on existing tickets for a day would be better than > > losing those comments. > > The Numpy Trac was made read-only in the sense that you cannot add new > tickets, but only some days after the transition. > Ah okay, that works. You can still comment on existing tickets, but the large red banner should be enough to redirect everyone to Github. Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsseabold at gmail.com Wed Apr 24 21:52:42 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Wed, 24 Apr 2013 21:52:42 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 4:59 PM, Skipper Seabold wrote: > I'm doing what is hopefully a last test run now. Whenever it's done > 1-2 hours, provided everything is fine, I can do the final move. > What I hope is a last round is up, if anyone wants to check. There were a few additional regex patterns for traclinks I had to come back to and fix. https://github.com/scipy-gitbot/scipy-trac-migration/issues I hope to do the migration to the official repo either late tonight or early in the morning. Skipper From warren.weckesser at gmail.com Thu Apr 25 13:01:49 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Thu, 25 Apr 2013 13:01:49 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Wed, Apr 24, 2013 at 9:52 PM, Skipper Seabold wrote: > On Wed, Apr 24, 2013 at 4:59 PM, Skipper Seabold > wrote: > > I'm doing what is hopefully a last test run now. Whenever it's done > > 1-2 hours, provided everything is fine, I can do the final move. > > > > What I hope is a last round is up, if anyone wants to check. There > were a few additional regex patterns for traclinks I had to come back > to and fix. > > https://github.com/scipy-gitbot/scipy-trac-migration/issues > > I hope to do the migration to the official repo either late tonight or > early in the morning. > Hey Skipper, I assume you are doing the conversion, because I am getting hundreds of emails from scipy-gitbot. Is that unavoidable? Warren > Skipper > _______________________________________________ > 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 jsseabold at gmail.com Thu Apr 25 13:08:35 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 13:08:35 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Thu, Apr 25, 2013 at 1:01 PM, Warren Weckesser wrote: > > On Wed, Apr 24, 2013 at 9:52 PM, Skipper Seabold > wrote: >> >> On Wed, Apr 24, 2013 at 4:59 PM, Skipper Seabold >> wrote: >> > I'm doing what is hopefully a last test run now. Whenever it's done >> > 1-2 hours, provided everything is fine, I can do the final move. >> > >> >> What I hope is a last round is up, if anyone wants to check. There >> were a few additional regex patterns for traclinks I had to come back >> to and fix. >> >> https://github.com/scipy-gitbot/scipy-trac-migration/issues >> >> I hope to do the migration to the official repo either late tonight or >> early in the morning. > > > > Hey Skipper, I assume you are doing the conversion, because I am getting > hundreds of emails from scipy-gitbot. Is that unavoidable? It is, unfortunately, if you want to be linked with your issues going forward. I was wondering if the warning notification worked. Some people apparently got the notification, but I don't know if everyone did. https://github.com/scipy-gitbot/scipy-trac-migration/issues/1885 Skipper From pav at iki.fi Thu Apr 25 13:17:15 2013 From: pav at iki.fi (Pauli Virtanen) Date: Thu, 25 Apr 2013 20:17:15 +0300 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: 25.04.2013 20:01, Warren Weckesser kirjoitti: [clip] > Hey Skipper, I assume you are doing the conversion, because I am getting > hundreds of emails from scipy-gitbot. Is that unavoidable? I think you can turn the email notifications off from Github's settings until the conversion is finished. Pauli From josef.pktd at gmail.com Thu Apr 25 13:23:23 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 25 Apr 2013 13:23:23 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: It gives a nice folder in gmail with 764 threads right now that are locally searchable. Josef On Thu, Apr 25, 2013 at 1:17 PM, Pauli Virtanen wrote: > 25.04.2013 20:01, Warren Weckesser kirjoitti: > [clip] >> Hey Skipper, I assume you are doing the conversion, because I am getting >> hundreds of emails from scipy-gitbot. Is that unavoidable? > > I think you can turn the email notifications off from Github's settings > until the conversion is finished. > > Pauli > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From jsseabold at gmail.com Thu Apr 25 14:34:23 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 14:34:23 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: All, Like removing a band-aid. The pain should be over. It seems to have gone pretty smoothly from the problems log, but let me know if you notice anything. I can fix problems for now, but I'd prefer not to make changes through the API after we announce that it's live. Feels dirty. https://github.com/scipy/scipy/issues Incidentally, it would probably be good if someone could take a snapshot of the trac attachments from that server just in case. I didn't do this. Skipper From jsseabold at gmail.com Thu Apr 25 14:58:12 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 14:58:12 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: On Thu, Apr 25, 2013 at 2:34 PM, Skipper Seabold wrote: > All, > > Like removing a band-aid. The pain should be over. It seems to have > gone pretty smoothly from the problems log, but let me know if you > notice anything. I can fix problems for now, but I'd prefer not to > make changes through the API after we announce that it's live. Feels > dirty. > > https://github.com/scipy/scipy/issues > > Incidentally, it would probably be good if someone could take a > snapshot of the trac attachments from that server just in case. I > didn't do this. > So maybe the notifications weren't such a great idea. So far I know that I only spammed a few people from their curt responses, and github contacted me to let me know that I flooded github's servers with a backlog of notifications. So let's hold off for at least a few hours before publicizing the move any more / using the issue tracker and generating more notifications. Skipper From pierre.haessig at crans.org Thu Apr 25 16:24:08 2013 From: pierre.haessig at crans.org (Pierre Haessig) Date: Thu, 25 Apr 2013 22:24:08 +0200 Subject: [SciPy-Dev] Multilinear interpolation In-Reply-To: <512B533D.1000105@gmail.com> References: <51260E4E.4010405@gmail.com> <51263127.7070306@gmail.com> <512B533D.1000105@gmail.com> Message-ID: <517990E8.2040206@crans.org> Hi Pablo, Le 25/02/2013 13:04, Pablo Winant a ?crit : > So I made an attempt using tempita in the case of regularly spaced > grids. For now, it is in a temporary repository in github: > > https://github.com/albop/python_interpolation > > There is a file multilinear_cython.pyx.in which must be interpreted to > produce multilinear_cython.pyx . There is also a multilinear.py file > containing an object oriented wrapper for the compiled routines. > > Here is an example: > > http://nbviewer.ipython.org/urls/raw.github.com/albop/python_interpolation/master/interpolation.ipynb > > Before, I do the same for irregularly spaced grid, I have some questions: > - I included the templates as Python strings in the .pyx.in file . Was > there a better way ? > - I was not sure about how to deal with single/double precision in the > cython code. I was just wondering what was the status of your work on a multilinear interpolation. I'm currently working on a small stochastic dynamic programming code where an interpolator is a key underlying component. I've been using scipy.interpolate.RectBivariateSpline so far because I was solving only a 2D state-space problem, but for genericity, a N-D interpolator is required (although the "curse of dimensionality" probably implies N <= 3 !) By looking at you're Githup repositories, it seems you've integrated the interpolation code in https://github.com/albop/dolo. Is that indeed the case ? This makes me ask two questions : 1) do you plan to integrate it in scipy.interpolate ? 2) did you benchmark your code against existing N-D interpolator like LinearNDInterpolator ? best, Pierre -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From ewm at redtetrahedron.org Thu Apr 25 19:16:55 2013 From: ewm at redtetrahedron.org (Eric Moore) Date: Thu, 25 Apr 2013 19:16:55 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: Message-ID: <5179B967.6010702@redtetrahedron.org> Skipper Seabold wrote: > On Thu, Apr 25, 2013 at 2:34 PM, Skipper Seabold wrote: >> All, >> >> Like removing a band-aid. The pain should be over. It seems to have >> gone pretty smoothly from the problems log, but let me know if you >> notice anything. I can fix problems for now, but I'd prefer not to >> make changes through the API after we announce that it's live. Feels >> dirty. >> >> https://github.com/scipy/scipy/issues >> >> Incidentally, it would probably be good if someone could take a >> snapshot of the trac attachments from that server just in case. I >> didn't do this. >> > > So maybe the notifications weren't such a great idea. So far I know > that I only spammed a few people from their curt responses, and github > contacted me to let me know that I flooded github's servers with a > backlog of notifications. So let's hold off for at least a few hours > before publicizing the move any more / using the issue tracker and > generating more notifications. > > Skipper This is certainly the first time I've ever checked my email to find 10,000+ new messages. However, I'm glad to see that we've converted over. It'll be nice to have everything in one place. Thanks for talking the time to do this. Eric From josef.pktd at gmail.com Thu Apr 25 19:38:26 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 25 Apr 2013 19:38:26 -0400 Subject: [SciPy-Dev] github membership Message-ID: Now that the issues are on github, it looks like I lost my rights to edit/assign labels and close tickets. I'm not planning on becoming active in merging. Thanks, Josef From josef.pktd at gmail.com Thu Apr 25 19:49:13 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 25 Apr 2013 19:49:13 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: <5179B967.6010702@redtetrahedron.org> References: <5179B967.6010702@redtetrahedron.org> Message-ID: incorrect crosslinks again comments like this are pretty annoying since the create backlinks https://github.com/scipy/scipy/issues/870#issuecomment-17029861 a collection of backlinks https://github.com/scipy/scipy/pull/3 trac didn't have the backlinks, so incorrect links were less of a distraction. Is there anything we can do? or maybe it's not worth it with old tickets. Josef From jsseabold at gmail.com Thu Apr 25 20:10:18 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 20:10:18 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: <5179B967.6010702@redtetrahedron.org> Message-ID: On Thu, Apr 25, 2013 at 7:49 PM, wrote: > incorrect crosslinks again > > comments like this are pretty annoying since the create backlinks > https://github.com/scipy/scipy/issues/870#issuecomment-17029861 > a collection of backlinks > https://github.com/scipy/scipy/pull/3 > > trac didn't have the backlinks, so incorrect links were less of a distraction. > > Is there anything we can do? or maybe it's not worth it with old tickets. > Ugh, I spent an hour fixing the regex for this last night and it happens automatically on github anyway. I just put that in a code block and it goes away, but no there's no way to really do that programmatically. Skipper From josef.pktd at gmail.com Thu Apr 25 20:22:05 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 25 Apr 2013 20:22:05 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: <5179B967.6010702@redtetrahedron.org> Message-ID: On Thu, Apr 25, 2013 at 8:10 PM, Skipper Seabold wrote: > On Thu, Apr 25, 2013 at 7:49 PM, wrote: >> incorrect crosslinks again >> >> comments like this are pretty annoying since the create backlinks >> https://github.com/scipy/scipy/issues/870#issuecomment-17029861 >> a collection of backlinks >> https://github.com/scipy/scipy/pull/3 >> >> trac didn't have the backlinks, so incorrect links were less of a distraction. >> >> Is there anything we can do? or maybe it's not worth it with old tickets. >> > > Ugh, I spent an hour fixing the regex for this last night and it > happens automatically on github anyway. > > I just put that in a code block and it goes away, but no there's no > way to really do that programmatically. Yes, I realized that before, there is no way to recognize this with a regex. I was thinking more about whether we should manually edit the offending comments. At least I would prefer, when I see a wrong backlink in one of the issues that I look at, to just go and edit the linking comment. It would trigger a notification, I assume. Josef > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From jsseabold at gmail.com Thu Apr 25 20:25:43 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 20:25:43 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: <5179B967.6010702@redtetrahedron.org> Message-ID: On Thu, Apr 25, 2013 at 8:22 PM, wrote: > On Thu, Apr 25, 2013 at 8:10 PM, Skipper Seabold wrote: >> On Thu, Apr 25, 2013 at 7:49 PM, wrote: >>> incorrect crosslinks again >>> >>> comments like this are pretty annoying since the create backlinks >>> https://github.com/scipy/scipy/issues/870#issuecomment-17029861 >>> a collection of backlinks >>> https://github.com/scipy/scipy/pull/3 >>> >>> trac didn't have the backlinks, so incorrect links were less of a distraction. >>> >>> Is there anything we can do? or maybe it's not worth it with old tickets. >>> >> >> Ugh, I spent an hour fixing the regex for this last night and it >> happens automatically on github anyway. >> >> I just put that in a code block and it goes away, but no there's no >> way to really do that programmatically. > > Yes, I realized that before, there is no way to recognize this with a regex. Well it doesn't convert it to gh-. That's the regex I control. > > I was thinking more about whether we should manually edit the > offending comments. Sounds fine to me. > > At least I would prefer, when I see a wrong backlink in one of the > issues that I look at, to just go and edit the linking comment. > It would trigger a notification, I assume. I don't think a manual edit would. Doing it with the code deletes the old comments and pushes new ones, so that would. I think we're out of the notification doghouse now though (at least with github...). https://status.github.com/ Skipper From josef.pktd at gmail.com Thu Apr 25 20:33:11 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Thu, 25 Apr 2013 20:33:11 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: <5179B967.6010702@redtetrahedron.org> Message-ID: On Thu, Apr 25, 2013 at 8:25 PM, Skipper Seabold wrote: > On Thu, Apr 25, 2013 at 8:22 PM, wrote: >> On Thu, Apr 25, 2013 at 8:10 PM, Skipper Seabold wrote: >>> On Thu, Apr 25, 2013 at 7:49 PM, wrote: >>>> incorrect crosslinks again >>>> >>>> comments like this are pretty annoying since the create backlinks >>>> https://github.com/scipy/scipy/issues/870#issuecomment-17029861 >>>> a collection of backlinks >>>> https://github.com/scipy/scipy/pull/3 >>>> >>>> trac didn't have the backlinks, so incorrect links were less of a distraction. >>>> >>>> Is there anything we can do? or maybe it's not worth it with old tickets. >>>> >>> >>> Ugh, I spent an hour fixing the regex for this last night and it >>> happens automatically on github anyway. >>> >>> I just put that in a code block and it goes away, but no there's no >>> way to really do that programmatically. >> >> Yes, I realized that before, there is no way to recognize this with a regex. > > Well it doesn't convert it to gh-. That's the regex I control. gdb traces that are not in triple backticks ``` produce a lot of links in the example ``` at ../Objects/abstract.c:1795 #30 0x080b395c in PyEval_CallObjectWithKeywords (func=0xb7903c34, arg=0xb7db502c, kw=0x0) at ../Python/ceval.c:3435 #31 0x080590d0 in PyObject_CallObject (o=0xb7903c34, a=0xb7db502c) at ../Objects/abstract.c:1786 gh-559 0xb7891b0a in init_gobject () from /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so gh-560 0xb77c8aa1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 gh-561 0xb77ca802 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 gh-562 0xb77cd7df in g_main_context_check () from /usr/lib/libglib-2.0.so.0 gh-563 0xb77cdb89 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 gh-564 0xb73ad574 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 gh-565 0xb76bbd90 in init_gtk () from /var/lib/python-support/python2.4/gtk-2.0/gtk/_gtk.so #39 0x080b8ab0 in PyEval_EvalFrame (f=0x818559c) at ../Python/ceval.c:3552 ---Type to continue, or q to quit--- #40 0x080ba4b9 in PyEval_EvalCodeEx (co=0xb7b9e0a0, globals=0xb7c119bc, locals=0x0, args=0x8155a88, argcount=1, kws=0x8155a8c, kwcount=0, defs=0xb7ba8dd8, defcount=2, closure=0x0) at ../Python/ceval.c:2741 ``` > >> >> I was thinking more about whether we should manually edit the >> offending comments. > > Sounds fine to me. > >> >> At least I would prefer, when I see a wrong backlink in one of the >> issues that I look at, to just go and edit the linking comment. >> It would trigger a notification, I assume. > > I don't think a manual edit would. Doing it with the code deletes the > old comments and pushes new ones, so that would. I don't know, I never edited someone elses comments, and I don't get a notification of my edits (still a major shortcoming of the github issue notifications compared to trac.) Josef > > I think we're out of the notification doghouse now though (at least > with github...). > > https://status.github.com/ > > Skipper > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From jsseabold at gmail.com Thu Apr 25 20:37:23 2013 From: jsseabold at gmail.com (Skipper Seabold) Date: Thu, 25 Apr 2013 20:37:23 -0400 Subject: [SciPy-Dev] issues trac migration review In-Reply-To: References: <5179B967.6010702@redtetrahedron.org> Message-ID: On Thu, Apr 25, 2013 at 8:33 PM, wrote: > On Thu, Apr 25, 2013 at 8:25 PM, Skipper Seabold wrote: >> On Thu, Apr 25, 2013 at 8:22 PM, wrote: >>> On Thu, Apr 25, 2013 at 8:10 PM, Skipper Seabold wrote: >>>> On Thu, Apr 25, 2013 at 7:49 PM, wrote: >>>>> incorrect crosslinks again >>>>> >>>>> comments like this are pretty annoying since the create backlinks >>>>> https://github.com/scipy/scipy/issues/870#issuecomment-17029861 >>>>> a collection of backlinks >>>>> https://github.com/scipy/scipy/pull/3 >>>>> >>>>> trac didn't have the backlinks, so incorrect links were less of a distraction. >>>>> >>>>> Is there anything we can do? or maybe it's not worth it with old tickets. >>>>> >>>> >>>> Ugh, I spent an hour fixing the regex for this last night and it >>>> happens automatically on github anyway. >>>> >>>> I just put that in a code block and it goes away, but no there's no >>>> way to really do that programmatically. >>> >>> Yes, I realized that before, there is no way to recognize this with a regex. >> >> Well it doesn't convert it to gh-. That's the regex I control. > > gdb traces that are not in triple backticks ``` produce a lot of links > > in the example > > ``` > at ../Objects/abstract.c:1795 > #30 0x080b395c in PyEval_CallObjectWithKeywords (func=0xb7903c34, > arg=0xb7db502c, kw=0x0) at ../Python/ceval.c:3435 > #31 0x080590d0 in PyObject_CallObject (o=0xb7903c34, a=0xb7db502c) > at ../Objects/abstract.c:1786 > gh-559 0xb7891b0a in init_gobject () > from /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so > gh-560 0xb77c8aa1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 > gh-561 0xb77ca802 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > gh-562 0xb77cd7df in g_main_context_check () from /usr/lib/libglib-2.0.so.0 > gh-563 0xb77cdb89 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 > gh-564 0xb73ad574 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > gh-565 0xb76bbd90 in init_gtk () > from /var/lib/python-support/python2.4/gtk-2.0/gtk/_gtk.so > #39 0x080b8ab0 in PyEval_EvalFrame (f=0x818559c) at ../Python/ceval.c:3552 > ---Type to continue, or q to quit--- > #40 0x080ba4b9 in PyEval_EvalCodeEx (co=0xb7b9e0a0, globals=0xb7c119bc, > locals=0x0, args=0x8155a88, argcount=1, kws=0x8155a8c, kwcount=0, > defs=0xb7ba8dd8, defcount=2, closure=0x0) at ../Python/ceval.c:2741 > > ``` Right, I only had a negative lookahead for 0x0 (was 0x00). Should've just done 0x. > >> >>> >>> I was thinking more about whether we should manually edit the >>> offending comments. >> >> Sounds fine to me. >> >>> >>> At least I would prefer, when I see a wrong backlink in one of the >>> issues that I look at, to just go and edit the linking comment. >>> It would trigger a notification, I assume. >> >> I don't think a manual edit would. Doing it with the code deletes the >> old comments and pushes new ones, so that would. > > I don't know, I never edited someone elses comments, and I don't get a > notification of my edits (still a major shortcoming of the github > issue notifications compared to trac.) > > Josef > >> >> I think we're out of the notification doghouse now though (at least >> with github...). >> >> https://status.github.com/ >> >> Skipper >> _______________________________________________ >> 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 From charlesnwoods at gmail.com Thu Apr 25 20:53:24 2013 From: charlesnwoods at gmail.com (Nathan Woods) Date: Thu, 25 Apr 2013 18:53:24 -0600 Subject: [SciPy-Dev] Request for extension to scipy.integrate Message-ID: <1F2B5A95-7C99-4B0A-AF0D-CFBBCF250147@gmail.com> SciPy's multidimensional integration capabilities are somewhat limited, as mentioned previously: https://github.com/scipy/scipy/issues/2098. Although dblquad and tplquad attempt to address this problem, they do not allow any detailed control over the underlying quad algorithm and there is no option for 4-dimensional integration at all. One obvious instance where this functionality would be desired is in the evaluation of volume integrals in 4-dimensional space-time. Another instance is the integration of discontinuous functions, where access to the "points" option of quad is critical. As it stands, SciPy does not provide any good functionality for either of these situations. I've written a recursive wrapper function for quad that resolves both of these problems, allowing n-dimensional integration with complete specification of options for quad. I've included a test problem that demonstrates the resolution of both of the above problems (just execute the script). I've done my best to document everything, and I've verified the result of the test problem against Mathematica. I would like this code (or equivalent functionality) to be included in the integrate package. I'm open to any feedback or suggestions, particularly with the interface. Nathan Woods """ Recursive integration using SciPy's quad function. Contains the following: class Error - module wrapper for Exception. For future expansion only. function mul_quad - Evaluate multiple integrals using recursive calls to quad. """ from scipy.integrate import quad import numpy class Error(Exception): pass def mul_quad(func,ranges,args=(),opts=(),_depth=0,_int_vars=()): """ Evaluate multiple integrals through recursive calls to scipy.integrate.quad. mul_quad takes care of the programming required to perform nested integration using the 1-dimensional integration routines provided by SciPy's adaptive quadrature function. It extends the capabilities of dblquad and tplquad by allowing for more levels of integration, and allowing the user to specify nearly the full range of options allowed by quad, for each level of integration. Users are cautioned that nested Gaussian integration of this kind is computationally intensive, and may be unsuitable for many nested integrals. Usage: mul_quad(func,ranges,args=(),opts=(),_depth=0,_int_vars=()) Inputs: func - callable, acceptable to SciPy's quad, returning a number. Should accept a float, followed by the contents of _int_vars and args, e.g. if x is a float, args=(1.4,string), and _int_vars = (1,1,3), then func should be of the form func(x,1,1,3,1.4,string). ranges - sequence describing the ranges of integration. Integrals are performed in order, so ranges[0] corresponds to the first argument of func, ranges[1] to the second, and so on. Each element of ranges may be either a constant sequence of length 2 or else a function that returns such a sequence. If a function, then it will be called with all of the integration arguments available to that point. e.g. for func = f(x0,x1,x2,x3), the range of integration for x0 may be defined as either a constant such as (0,1) or as a function range0(x1,x2,x3). The functional range of integration for x1 will be range1(x2,x3), x2 will be range2(x3), and so on. args - optional sequence of arguments. Contains only arguments of func beyond those over which the integration is being performed. opts - optional sequence of options for SciPy's quad. Each element of opts may be specified as either a dictionary or as a function that returns a dictionary similarly to ranges. opts must either be left empty (), or it must be the same length as ranges. Options are passed in the same order as ranges, so opts[0] corresponds to integration over the first argument of func, and so on. The full_output option from quad is not available, due to the difficulty of consolidating the large number of additional outputs. For reference, the default options from quad are: - epsabs = 1.49e-08 - epsrel = 1.49e-08 - limit = 50 - points = None - weight = None - wvar = None - wopts = None (As of Apr 2013) _depth - used to determine level of integration. Should be omitted by the user, except for debugging purposes. _int_vars - contains values of integration variables in inner integration loops. Should not be used manually except for debugging. Returns: out - value of multiple integral in the specified range. abserr - estimate of the absolute error in the result. The maximum value of abserr among all the SciPy quad evaluations. """ global abserr if _depth == 0: abserr = None if not (len(opts) in [0,len(ranges)]): raise Error('opts must be given for all integration levels or none!') total_args = _int_vars+args # Select the range and opts for the given depth of integration. ind = -_depth-1 if callable(ranges[ind]): current_range = ranges[ind](*total_args) else: current_range = ranges[ind] if len(opts) != 0: if callable(opts[ind]): current_opts = opts[ind](*total_args) else: current_opts = opts[ind] else: current_opts = {} try: if current_opts["full_output"] != 0: raise Error('full_output option is disabled!') except(KeyError): pass # Check to make sure that all points lie within the specified range. try: for point in current_opts["points"]: if point < current_range[0] or point > current_range[1]: current_opts["points"].remove(point) except(KeyError): pass if current_range is ranges[0]:# Check to see if down to 1-D integral. func_new = func else: # Define a new integrand. def func_new(*_int_vars): return mul_quad(func,ranges,args=args,opts=opts, _depth=_depth+1,_int_vars=_int_vars) out = quad(func_new,*current_range,args=_int_vars+args,**current_opts) # Track the maximum value of abserr from quad if abserr is None: abserr = out[1] if out[1] > abserr: abserr = out[1] if _depth == 0: return out[0],abserr else: return out[0] if __name__=='__main__': func = lambda x0,x1,x2,x3 : x0**2+x1*x2-x3**3+numpy.sin(x0)+( 1 if (x0-.2*x3-.5-.25*x1>0) else 0) points=[[lambda (x1,x2,x3) : .2*x3+.5+.25*x1],[],[],[]] def opts0(*args,**kwargs): return {'points':[.2*args[2]+.5+.25*args[0]]} print mul_quad(func,[[0,1],[-1,1],[.13,.8],[-.15,1]], opts=[opts0,{},{},{}]) -------------- next part -------------- A non-text attachment was scrubbed... Name: myquad.py Type: text/x-python-script Size: 5736 bytes Desc: not available URL: From suryak at ieee.org Thu Apr 25 21:49:39 2013 From: suryak at ieee.org (Surya Kasturi) Date: Fri, 26 Apr 2013 07:19:39 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> Message-ID: The proposal (draft) is here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html It would be great to hear some comments, suggestions etc. Thanks Surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From pav at iki.fi Fri Apr 26 03:43:35 2013 From: pav at iki.fi (Pauli Virtanen) Date: Fri, 26 Apr 2013 07:43:35 +0000 (UTC) Subject: [SciPy-Dev] github membership References: Message-ID: gmail.com> writes: > Now that the issues are on github, it looks like I lost my rights to > edit/assign labels and close tickets. That should be fixed now. Pauli From josef.pktd at gmail.com Fri Apr 26 06:41:44 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Fri, 26 Apr 2013 06:41:44 -0400 Subject: [SciPy-Dev] github membership In-Reply-To: References: Message-ID: On Fri, Apr 26, 2013 at 3:43 AM, Pauli Virtanen wrote: > gmail.com> writes: >> Now that the issues are on github, it looks like I lost my rights to >> edit/assign labels and close tickets. > > That should be fixed now. I'm in, thank you Josef > > Pauli > > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From sturla at molden.no Fri Apr 26 12:51:11 2013 From: sturla at molden.no (Sturla Molden) Date: Fri, 26 Apr 2013 18:51:11 +0200 Subject: [SciPy-Dev] Thanks Message-ID: <4EAD02FC-39F9-4D92-95FC-E7697D021B56@molden.no> I was watching Scipy on Github, and suddenly my inbox had about 1600 unread messages. Thanks a lot guys ;-) Sturla Sendt fra min iPad From charlesr.harris at gmail.com Fri Apr 26 13:56:02 2013 From: charlesr.harris at gmail.com (Charles R Harris) Date: Fri, 26 Apr 2013 11:56:02 -0600 Subject: [SciPy-Dev] Thanks In-Reply-To: <4EAD02FC-39F9-4D92-95FC-E7697D021B56@molden.no> References: <4EAD02FC-39F9-4D92-95FC-E7697D021B56@molden.no> Message-ID: On Fri, Apr 26, 2013 at 10:51 AM, Sturla Molden wrote: > I was watching Scipy on Github, and suddenly my inbox had about 1600 > unread messages. Thanks a lot guys ;-) > Because we love you. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From blake.a.griffith at gmail.com Fri Apr 26 15:00:32 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Fri, 26 Apr 2013 14:00:32 -0500 Subject: [SciPy-Dev] Thanks In-Reply-To: <4EAD02FC-39F9-4D92-95FC-E7697D021B56@molden.no> References: <4EAD02FC-39F9-4D92-95FC-E7697D021B56@molden.no> Message-ID: Sorry Sturla, that was a side effect of moving issue tracking from trac to GitHub. It should not happen again. On Fri, Apr 26, 2013 at 11:51 AM, Sturla Molden wrote: > I was watching Scipy on Github, and suddenly my inbox had about 1600 > unread messages. Thanks a lot guys ;-) > > Sturla > > Sendt fra min iPad > _______________________________________________ > 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 blake.a.griffith at gmail.com Sat Apr 27 03:17:18 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Sat, 27 Apr 2013 02:17:18 -0500 Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy Message-ID: Seeking feedback, comments, and criticism Link: https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at hilboll.de Sat Apr 27 03:57:27 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 09:57:27 +0200 Subject: [SciPy-Dev] Website Migration: Status and Ideas Message-ID: <517B84E7.80001@hilboll.de> Sparked by a discussion on numpy-discussion, some points about scipy website migration: > I think the major TODO items there are the conversion of the Topical > Software and Cookbook pages. I can give dumps of the current wiki > pages to anyone who wants to help with that. There's also quite a bit of the Topical Software in the new github repo. What's the status here? What are we aiming for? A 'dumb' translation from moin to sphinx, or also some content changes? About the cookbook: How about moving that to IPython Notebooks? Or at least having the examples in notebooks, and linking to these at the bottom of each example? Any ideas on how to automate such a translation? Can you upload a wiki dump to somewhere? Cheers, Andreas. From lists at hilboll.de Sat Apr 27 03:58:41 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 09:58:41 +0200 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B84E7.80001@hilboll.de> References: <517B84E7.80001@hilboll.de> Message-ID: <517B8531.4000301@hilboll.de> > Sparked by a discussion on numpy-discussion, some points about scipy > website migration: > >> I think the major TODO items there are the conversion of the Topical >> Software and Cookbook pages. I can give dumps of the current wiki >> pages to anyone who wants to help with that. > > There's also quite a bit of the Topical Software in the new github repo. > What's the status here? What are we aiming for? A 'dumb' translation > from moin to sphinx, or also some content changes? > > About the cookbook: How about moving that to IPython Notebooks? Or at > least having the examples in notebooks, and linking to these at the > bottom of each example? Any ideas on how to automate such a translation? Or moving the cookbook to Scipy-Central? From lists at hilboll.de Sat Apr 27 04:11:40 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 10:11:40 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> Message-ID: <517B883C.9050403@hilboll.de> Hi Surya, > The proposal (draft) is > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html > It would be great to hear some comments, suggestions etc. Thanks for you proposal! Let me add some comments / ideas here: > 1. Migrating to Django 1.4.5 Is there any specific reason not to go to 1.5.1? If I understand correctly, some modules have not been upgraded for 1.5.x yet, but if we don't need those, we should go with the latest, don't you think? > 2. Integrating with Content Management System While this is nice, I think we should try to focus. What I would think is more important for SPC would be a IPython Notebook integration. Like having a "download notebook" link for each item. > 3. Commenting, Reputation functionality for Submissions Yes, definitely. > 4. Providing caching mechanism using Memcache Does it make sense to do this in a GSoC? If I understand correctly, memcached is installed on the server, and just needs to be switched on in Django config. I don't see much possibility to work on this in a (code-)development environment, without the actual server daemons etc. > 5. RSS, Atom feeds for the site Yes. Maybe add the possibility to subscribe to certain tags only? What I also find important is categories (maybe I'm old-fashioned), or a really good search-by-tag functionality (klicking tag icons to select/deselect this tag, with quickly updating search results). What do you think? Andreas. From pav at iki.fi Sat Apr 27 04:12:52 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 11:12:52 +0300 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B8531.4000301@hilboll.de> References: <517B84E7.80001@hilboll.de> <517B8531.4000301@hilboll.de> Message-ID: 27.04.2013 10:58, Andreas Hilboll kirjoitti:[clip] >> About the cookbook: How about moving that to IPython Notebooks? Or at >> least having the examples in notebooks, and linking to these at the >> bottom of each example? Any ideas on how to automate such a translation? > > Or moving the cookbook to Scipy-Central? I think that would a good idea. The thing that is missing is improving the stability Scipy Central --- currently, I'm getting error 500 for the site, and this is not unusual. I think having a deployment for it where the bus factor of people having access to the site being > 1 would be important. -- Pauli Virtanen From pav at iki.fi Sat Apr 27 04:44:25 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 11:44:25 +0300 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517B883C.9050403@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: 27.04.2013 11:11, Andreas Hilboll kirjoitti: [clip] >> 1. Migrating to Django 1.4.5 > > Is there any specific reason not to go to 1.5.1? If I understand > correctly, some modules have not been upgraded for 1.5.x yet, but if we > don't need those, we should go with the latest, don't you think? I think the holdup is django-registration, which only recently got the support for Django 1.5 in its dev version: https://bitbucket.org/ubernostrum/django-registration/commits/all Development against the dev version seems possible, though. >> 2. Integrating with Content Management System > > While this is nice, I think we should try to focus. What I would think > is more important for SPC would be a IPython Notebook integration. Like > having a "download notebook" link for each item. +1 for Ipython notebook integration. Also, submissions of Ipython notebooks should be accepted (and not just as attachments, but rendered). >> 4. Providing caching mechanism using Memcache > > Does it make sense to do this in a GSoC? If I understand correctly, > memcached is installed on the server, and just needs to be switched on > in Django config. I don't see much possibility to work on this in a > (code-)development environment, without the actual server daemons etc. There are no @cache statements in the code currently, except that the rendered code snippets are cached on disk (or in DB?), I think. This GSoC milestone could be changed to "implement caching (using Django's caching mechanism)". Pauli From lists at hilboll.de Sat Apr 27 04:47:42 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 10:47:42 +0200 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B84E7.80001@hilboll.de> References: <517B84E7.80001@hilboll.de> Message-ID: <517B90AE.30800@hilboll.de> > Sparked by a discussion on numpy-discussion, some points about scipy > website migration: > >> I think the major TODO items there are the conversion of the Topical >> Software and Cookbook pages. I can give dumps of the current wiki >> pages to anyone who wants to help with that. > > There's also quite a bit of the Topical Software in the new github repo. > What's the status here? What are we aiming for? A 'dumb' translation > from moin to sphinx, or also some content changes? Has anyone tried moin2rst? .. http://www.merten-home.de/FreeSoftware/moin2rst/ From suryak at ieee.org Sat Apr 27 06:41:07 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 27 Apr 2013 16:11:07 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 2:14 PM, Pauli Virtanen wrote: > 27.04.2013 11:11, Andreas Hilboll kirjoitti: > [clip] > >> 1. Migrating to Django 1.4.5 > > > > Is there any specific reason not to go to 1.5.1? If I understand > > correctly, some modules have not been upgraded for 1.5.x yet, but if we > > don't need those, we should go with the latest, don't you think? > > I think the holdup is django-registration, which only recently got the > support for Django 1.5 in its dev version: > https://bitbucket.org/ubernostrum/django-registration/commits/all > > Development against the dev version seems possible, though. > > This is one thing. Actually, I am not sure whether (in general) people are preferring 1.5 or 1.4.. The same reason why some choose py2.7 over 3.0! For some reason if we want to integrate a 3rd party app and if they don't support 1.5 yet.. its going to trouble us! >> 2. Integrating with Content Management System > > > > While this is nice, I think we should try to focus. What I would think > > is more important for SPC would be a IPython Notebook integration. Like > > having a "download notebook" link for each item. > > +1 for Ipython notebook integration. Also, submissions of Ipython > notebooks should be accepted (and not just as attachments, but rendered). > Actually I heard of IPython but never looked into it clearly.. Will go through it now. As far as I know its an web-based python console.. with lots of features. So, using it helps us run snippets directly on the site.. is that right? > >> 4. Providing caching mechanism using Memcache > > > > Does it make sense to do this in a GSoC? If I understand correctly, > > memcached is installed on the server, and just needs to be switched on > > in Django config. I don't see much possibility to work on this in a > > (code-)development environment, without the actual server daemons etc. > > There are no @cache statements in the code currently, except that the > rendered code snippets are cached on disk (or in DB?), I think. This > GSoC milestone could be changed to "implement caching (using Django's > caching mechanism)". > Yeah, we will be using django caching framework for it! Since there seems to be lot of other caching mechanisms, I thought to put memcache (most efficient than others) specifically to avoid confusion. that's it.. May be we can take sometime deciding which caching mechanism is good for us!! > > 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 suryak at ieee.org Sat Apr 27 06:50:17 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 27 Apr 2013 16:20:17 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517B883C.9050403@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 1:41 PM, Andreas Hilboll wrote: > Hi Surya, > > > The proposal (draft) is > > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html > > It would be great to hear some comments, suggestions etc. > > Thanks for you proposal! Let me add some comments / ideas here: > > > 1. Migrating to Django 1.4.5 > > Is there any specific reason not to go to 1.5.1? If I understand > correctly, some modules have not been upgraded for 1.5.x yet, but if we > don't need those, we should go with the latest, don't you think? > > > 2. Integrating with Content Management System > > While this is nice, I think we should try to focus. What I would think > is more important for SPC would be a IPython Notebook integration. Like > having a "download notebook" link for each item. > > > 3. Commenting, Reputation functionality for Submissions > > Yes, definitely. > > > 4. Providing caching mechanism using Memcache > > Does it make sense to do this in a GSoC? If I understand correctly, > memcached is installed on the server, and just needs to be switched on > in Django config. I don't see much possibility to work on this in a > (code-)development environment, without the actual server daemons etc. > > Actually, we need to hook this memcache with django caching framework. django.core.cache.backends. > > 5. RSS, Atom feeds for the site > > Yes. Maybe add the possibility to subscribe to certain tags only? > > What I also find important is categories (maybe I'm old-fashioned), or a > really good search-by-tag functionality (klicking tag icons to > select/deselect this tag, with quickly updating search results). > > What do you think? > This features works quite good with spc. "search based on selected tags" is that right? This particular feature needs ajax which I am not quite good at the moment.. may be we can look over some snippets in jQuery site and start building from there --a custom search engine. > Andreas. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Sat Apr 27 07:00:26 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 27 Apr 2013 16:30:26 +0530 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: References: <517B84E7.80001@hilboll.de> <517B8531.4000301@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 1:42 PM, Pauli Virtanen wrote: > 27.04.2013 10:58, Andreas Hilboll kirjoitti:[clip] > >> About the cookbook: How about moving that to IPython Notebooks? Or at > >> least having the examples in notebooks, and linking to these at the > >> bottom of each example? Any ideas on how to automate such a translation? > > > > Or moving the cookbook to Scipy-Central? > > I think that would a good idea. > > cookbook on scipy central looks to be a nice idea! may be we can add a tag like "tutorial/ recipe" for good search too! > The thing that is missing is improving the stability Scipy Central --- > currently, I'm getting error 500 for the site, and this is not unusual. > > A 500 on scipy central? I sometimes find it too. May be production server is not that good and sometime I guess because of code too. Probably, we can look into much scalable platforms like Google App Engine --costly > I think having a deployment for it where the bus factor of people having > access to the site being > 1 would be important. > > -- > Pauli Virtanen > > _______________________________________________ > 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 lists at hilboll.de Sat Apr 27 07:13:36 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 13:13:36 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: <517BB2E0.8040300@hilboll.de> > >> 2. Integrating with Content Management System > > > > While this is nice, I think we should try to focus. What I would think > > is more important for SPC would be a IPython Notebook integration. > Like > > having a "download notebook" link for each item. > > +1 for Ipython notebook integration. Also, submissions of Ipython > notebooks should be accepted (and not just as attachments, but > rendered). > > Actually I heard of IPython but never looked into it clearly.. Will go > through it now. As far as I know its an web-based python console.. with > lots of features. So, using it helps us run snippets directly on the > site.. is that right? Not necessarily. IPython is an interactive Python shell. The Notebook is a web-based frontend for this, with the possibility to do inline plotting etc. What I meant in the scope of SPC is just providing support for the Notebook fileformat. This means that a) It should be possible to submit Notebook files as new entries (as suggested by Pauli) b) It could be possible to view items as rendered Notebook (as suggested by Pauli). I personally don't think this is so important; it might be enough to provide a link to the rendered Notebook on nbviewer.ipython.org. c) It should be possible to download an item in Notebook format. d) I'm strictly against actually running IPython Notebook on the SPC server, so that means im in favor of no snippet-running on the server. Cheers, Andreas. From pav at iki.fi Sat Apr 27 07:23:17 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 14:23:17 +0300 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: Hi, 27.04.2013 13:41, Surya Kasturi kirjoitti: [clip] > Actually I heard of IPython but never looked into it clearly.. Will go > through it now. As far as I know its an web-based python console.. with > lots of features. So, using it helps us run snippets directly on the > site.. is that right? Especially look at this: http://nbviewer.ipython.org/ https://github.com/ipython/nbviewer It's clear that good Ipython interaction is a must have for SPC. The implementation of nbviewer is simple, since there is no need for database etc. (all data stored on Github), which allows it to be run more easily on a 3rd party hosting solution --- which then outsources the maintenance issues. 27.04.2013 14:00, Surya Kasturi kirjoitti:[clip] > A 500 on scipy central? I sometimes find it too. May be production > server is not that good and sometime I guess because of code too. > Probably, we can look into much scalable platforms like Google App > Engine --costly I think the present rate of 500 (e.g. the site is currently down) makes the site unfortunately very much less useful than it should be, also in its current form. This problem is definitely solvable, but it needs someone to work on it. 3rd party hosting solutions such as App Engine / Heroku / etc. do have continuous costs, but on the other hand outsource the server maintenance. The use of static on-disk files for storage in SPC also makes it less easy to use these solutions. -- Pauli Virtanen From pav at iki.fi Sat Apr 27 07:25:11 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 14:25:11 +0300 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B90AE.30800@hilboll.de> References: <517B84E7.80001@hilboll.de> <517B90AE.30800@hilboll.de> Message-ID: 27.04.2013 11:47, Andreas Hilboll kirjoitti: [clip] > Has anyone tried moin2rst? > > .. http://www.merten-home.de/FreeSoftware/moin2rst/ The contents of the wiki were converted to RST several years ago: https://github.com/dwf/rescued-scipy-wiki I don't think the cookbook has changed a lot since that. -- Pauli Virtanen From lists at hilboll.de Sat Apr 27 07:34:51 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 13:34:51 +0200 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: References: <517B84E7.80001@hilboll.de> <517B90AE.30800@hilboll.de> Message-ID: <517BB7DB.5000300@hilboll.de> >> Has anyone tried moin2rst? >> >> .. http://www.merten-home.de/FreeSoftware/moin2rst/ > > The contents of the wiki were converted to RST several years ago: > > https://github.com/dwf/rescued-scipy-wiki > > I don't think the cookbook has changed a lot since that. so basically, the cookbook pages could be copied from there to the new scipy homepage, right? of course, after cleaning them up a bit ... From pav at iki.fi Sat Apr 27 07:30:09 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 14:30:09 +0300 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517BB2E0.8040300@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517BB2E0.8040300@hilboll.de> Message-ID: 27.04.2013 14:13, Andreas Hilboll kirjoitti: [clip] > d) I'm strictly against actually running IPython Notebook on the SPC > server, so that means im in favor of no snippet-running on the server. Yes, the site shouldn't run any of the user-submitted code. However, the notebooks can probably be rendered quite easily without running code, so doing what nbviewer.ipython.org does wouldn't be too difficult. Pauli From lists at hilboll.de Sat Apr 27 07:43:27 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 13:43:27 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> Message-ID: <517BB9DF.4060503@hilboll.de> > The proposal (draft) is > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html > It would be great to hear some comments, suggestions etc. Just as a side note: Each item should have module versions in the metadata, as in "works with numpy1.6, scipy0.10, pandas0.9". Also, it should be possible t? flag items as "doesn't work" or "doesn't work with current (which?) modules".(This might be a good example for where hierarchical tags would be useful). - Andreas. From pav at iki.fi Sat Apr 27 07:43:32 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sat, 27 Apr 2013 14:43:32 +0300 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517BB7DB.5000300@hilboll.de> References: <517B84E7.80001@hilboll.de> <517B90AE.30800@hilboll.de> <517BB7DB.5000300@hilboll.de> Message-ID: 27.04.2013 14:34, Andreas Hilboll kirjoitti: [clip] > so basically, the cookbook pages could be copied from there to the new > scipy homepage, right? of course, after cleaning them up a bit ... As a temporary measure, yes. Temporary solutions have a bad habit of becoming permanent, though. Btw, I have a Sphinx theme based on Surya's new layout: https://github.com/pv/scipy-sphinx-theme Could probably be easily adapted for use in the main scipy.org website. Pauli From warren.weckesser at gmail.com Sat Apr 27 08:34:49 2013 From: warren.weckesser at gmail.com (Warren Weckesser) Date: Sat, 27 Apr 2013 08:34:49 -0400 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: References: <517B84E7.80001@hilboll.de> <517B90AE.30800@hilboll.de> Message-ID: On 4/27/13, Pauli Virtanen wrote: > 27.04.2013 11:47, Andreas Hilboll kirjoitti: > [clip] >> Has anyone tried moin2rst? >> >> .. http://www.merten-home.de/FreeSoftware/moin2rst/ > > The contents of the wiki were converted to RST several years ago: > > https://github.com/dwf/rescued-scipy-wiki > > I don't think the cookbook has changed a lot since that. The dates there say it was converted four years ago. There have been quite a few changes to the Cookbook since then. Warren > > -- > Pauli Virtanen > > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev > From suryak at ieee.org Sat Apr 27 11:10:58 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sat, 27 Apr 2013 20:40:58 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517BB9DF.4060503@hilboll.de> References: <517016F3.30408@hilboll.de> <517BB9DF.4060503@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 5:13 PM, Andreas Hilboll wrote: > > The proposal (draft) is > > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html > > It would be great to hear some comments, suggestions etc. > > Just as a side note: Each item should have module versions in the > metadata, as in "works with numpy1.6, scipy0.10, pandas0.9". Also, it > should be possible t? flag items as "doesn't work" or "doesn't work with > current (which?) modules".(This might be a good example for where > hierarchical tags would be useful). > > - Andreas. > > This helps a lot for users.. the below are the couple of ideas I got in mind 1. users should be strictly directed to add these details in the snippet documentation (not all might do) 2. we need to detect the modules used in the snippets, ask them to provide versions for them during submission 3. (instead of 2): we can ask them to attach "requirements.txt". this should be quite good and simple way to handle things.. *Detecting the modules* in the snippets, adding them as tags for improving search is one of the possible feature I mentioned in proposal (at the bottom of the page) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.kern at gmail.com Sat Apr 27 11:17:33 2013 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 27 Apr 2013 16:17:33 +0100 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B84E7.80001@hilboll.de> References: <517B84E7.80001@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 8:57 AM, Andreas Hilboll wrote: > Sparked by a discussion on numpy-discussion, some points about scipy > website migration: > >> I think the major TODO items there are the conversion of the Topical >> Software and Cookbook pages. I can give dumps of the current wiki >> pages to anyone who wants to help with that. > > There's also quite a bit of the Topical Software in the new github repo. > What's the status here? What are we aiming for? A 'dumb' translation > from moin to sphinx, or also some content changes? > > About the cookbook: How about moving that to IPython Notebooks? Or at > least having the examples in notebooks, and linking to these at the > bottom of each example? Any ideas on how to automate such a translation? > > Can you upload a wiki dump to somewhere? I am preparing one now. -- Robert Kern From lists at hilboll.de Sat Apr 27 12:04:58 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sat, 27 Apr 2013 18:04:58 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517BB9DF.4060503@hilboll.de> Message-ID: <517BF72A.1080804@hilboll.de> > > The proposal (draft) is > > here http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html > > It would be great to hear some comments, suggestions etc. > > Just as a side note: Each item should have module versions in the > metadata, as in "works with numpy1.6, scipy0.10, pandas0.9". Also, it > should be possible t? flag items as "doesn't work" or "doesn't work with > current (which?) modules".(This might be a good example for where > hierarchical tags would be useful). > > - Andreas. > > > This helps a lot for users.. the below are the couple of ideas I got in mind > > 1. users should be strictly directed to add these details in the snippet > documentation (not all might do) > 2. we need to detect the modules used in the snippets, ask them to > provide versions for them during submission > 3. (instead of 2): we can ask them to attach "requirements.txt". this > should be quite good and simple way to handle things.. > > /Detecting the modules/ in the snippets, adding them as tags for > improving search is one of the possible feature I mentioned in proposal > (at the bottom of the page) I think this is a whole sub-project in its own; I can identify the following parts: a) Figure out the data model / workflow to use b) Implement simple input form for the submission/revision c) Add module auto-detection and use the results in the display of b. As for a), I can envision several ways to deal with this: 1. The author enters the requirements 2. Users have the possibility to add information like "works/doesn't work with thisandthat module versions" The nice thing about 2. is that even if something breaks due to API changes in the used modules, a user would have the possibility to flag the item as "doesn't work as-is", making it easy for other users to check out such issues. So here, we need to decide on which way we want SPC to work. Then, this workflow can be put into the data model. In the beginning, it would be enough to have b) because it would allow using this feature. c) is definitely a nice-to-have, but it's essentially useless if a) and b) isn't implemented correctly. -- Andreas. From robert.kern at gmail.com Sat Apr 27 13:06:56 2013 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 27 Apr 2013 18:06:56 +0100 Subject: [SciPy-Dev] Website Migration: Status and Ideas In-Reply-To: <517B84E7.80001@hilboll.de> References: <517B84E7.80001@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 8:57 AM, Andreas Hilboll wrote: > Can you upload a wiki dump to somewhere? Here are the spam-free wiki pages. I do not know if this is an appropriate format for any particular conversion tools that may be out there. Please let me know if anything is missing. https://www.dropbox.com/s/0rg0a1mcs1cynjj/wiki-export.tar.bz2 -- Robert Kern From andyfaff at gmail.com Sat Apr 27 13:15:42 2013 From: andyfaff at gmail.com (Andrew Nelson) Date: Sat, 27 Apr 2013 13:15:42 -0400 Subject: [SciPy-Dev] Adding startiter keyword to scipy.integrate.quadrature In-Reply-To: References: Message-ID: Dear dev list, please forgive any glaring faux pas I might make. This is my first time contributing to scipy development. I am proposing to add the 'startiter' keyword to scipy.integrate.quadrature. At the moment the adaptive quadrature starts from a Gaussian quadrature order of 1 and finishes when maxiter iterations are reached (unless the termination criteria are met). For the problem I deal with I know that I have to start iteration from approx. order 15 onwards. Which means that orders 1 through 14 are wasted. This would correspond to 105 calculations of the function to be integrated (1+2+3+4...+14). Adding the startiter keyword enables one to start at an arbitrary order, saving a reasonable amount of calculation time. Would such this addition be suitable for inclusion into scipy? If so, I can prepare a pull request. regards, Andrew. On 24 April 2013 13:13, Andrew Nelson wrote: > Dear dev list, > please forgive any glaring faux pas I might make. This is my first > time contributing to scipy development. > > I am proposing to add the 'startiter' keyword to scipy.integrate.quadrature. > > At the moment the adaptive quadrature starts from a Gaussian > quadrature order of 1 and finishes when maxiter iterations are reached > (unless the termination criteria are met). > > For the problem I deal with I know that I have to start iteration from > approx. order 15 onwards. Which means that orders 1 through 14 are > wasted. This would correspond to 105 calculations of the function to > be integrated (1+2+3+4...+14). > > Adding the startiter keyword enables one to start at an arbitrary > order, saving a reasonable amount of calculation time. > > Would such this addition be suitable for inclusion into scipy? If so, > I can prepare a pull request. > > regards, > Andrew. > > > > -- > _____________________________________ > Dr. Andrew Nelson > > > _____________________________________ -- _____________________________________ Dr. Andrew Nelson _____________________________________ From suryak at ieee.org Sat Apr 27 23:22:55 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sun, 28 Apr 2013 08:52:55 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517BB2E0.8040300@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517BB2E0.8040300@hilboll.de> Message-ID: On Sat, Apr 27, 2013 at 4:43 PM, Andreas Hilboll wrote: > > >> 2. Integrating with Content Management System > > > > > > While this is nice, I think we should try to focus. What I would > think > > > is more important for SPC would be a IPython Notebook integration. > > Like > > > having a "download notebook" link for each item. > > > > +1 for Ipython notebook integration. Also, submissions of Ipython > > notebooks should be accepted (and not just as attachments, but > > rendered). > > > > Actually I heard of IPython but never looked into it clearly.. Will go > > through it now. As far as I know its an web-based python console.. with > > lots of features. So, using it helps us run snippets directly on the > > site.. is that right? > > Not necessarily. IPython is an interactive Python shell. The Notebook is > a web-based frontend for this, with the possibility to do inline > plotting etc. > > What I meant in the scope of SPC is just providing support for the > Notebook fileformat. This means that > > a) It should be possible to submit Notebook files as new entries (as > suggested by Pauli) > > b) It could be possible to view items as rendered Notebook (as suggested > by Pauli). I personally don't think this is so important; it might be > enough to provide a link to the rendered Notebook on nbviewer.ipython.org. > > c) It should be possible to download an item in Notebook format. > > d) I'm strictly against actually running IPython Notebook on the SPC > server, so that means im in favor of no snippet-running on the server. > > Cheers, Andreas. > I just had a look into IPython notebook.. My first impressions 1. Its great if someone is writing tutorials and want to share (SciPy cookbook can be migrated to it) 2. since all the data is just in 1 single file.. maintenance is quite low but readability is also quite low. The below are the possible ways I think we can support .ipynb files in spc 1. users can upload them on some X hosted environment (gists for example) and submit the url in spc. Now, 1.a) we can direct them to nbviewer with this url 1.b) we should provide ipynb rendering 2. we should be able to host .ipynb file like .py (snippets), 2.a) render them on the site as 1.b) 2.b) provide users a url for files which can be rendered on nbviewer my choice would be a mix of the above two!.. support both of them. We can build a submission form and ask users to provide either url to .ipynb files or submit the file itself. In either cases, we can render it on our site (the question is how to. Do we have any standardization IPython provides? -- I see some ipython API but don't understand it as for now) Or else, we can direct them to nbviewer in case if we don't want to support rendering! cheers, surya -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at hilboll.de Sun Apr 28 03:36:19 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sun, 28 Apr 2013 09:36:19 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517BB2E0.8040300@hilboll.de> Message-ID: <517CD173.7010901@hilboll.de> > > >> 2. Integrating with Content Management System > > > > > > While this is nice, I think we should try to focus. What I > would think > > > is more important for SPC would be a IPython Notebook > integration. > > Like > > > having a "download notebook" link for each item. > > > > +1 for Ipython notebook integration. Also, submissions of Ipython > > notebooks should be accepted (and not just as attachments, but > > rendered). > > > > Actually I heard of IPython but never looked into it clearly.. Will go > > through it now. As far as I know its an web-based python console.. > with > > lots of features. So, using it helps us run snippets directly on the > > site.. is that right? > > Not necessarily. IPython is an interactive Python shell. The Notebook is > a web-based frontend for this, with the possibility to do inline > plotting etc. > > What I meant in the scope of SPC is just providing support for the > Notebook fileformat. This means that > > a) It should be possible to submit Notebook files as new entries (as > suggested by Pauli) > > b) It could be possible to view items as rendered Notebook (as suggested > by Pauli). I personally don't think this is so important; it might be > enough to provide a link to the rendered Notebook on > nbviewer.ipython.org . > > c) It should be possible to download an item in Notebook format. > > d) I'm strictly against actually running IPython Notebook on the SPC > server, so that means im in favor of no snippet-running on the server. > > Cheers, Andreas. > > > I just had a look into IPython notebook.. My first impressions > > 1. Its great if someone is writing tutorials and want to share (SciPy > cookbook can be migrated to it) > 2. since all the data is just in 1 single file.. maintenance is quite > low but readability is also quite low. > > The below are the possible ways I think we can support .ipynb files in spc > > 1. users can upload them on some X hosted environment (gists for > example) and submit the url in spc. Now, > 1.a) we can direct them to nbviewer with this url > 1.b) we should provide ipynb rendering > > 2. we should be able to host .ipynb file like .py (snippets), > 2.a) render them on the site as 1.b) > 2.b) provide users a url for files which can be rendered on nbviewer > > my choice would be a mix of the above two!.. support both of them. For a starter, I prefer 2., and think it is more important. > We can build a submission form and ask users to provide either url to > .ipynb files or submit the file itself. > > In either cases, we can render it on our site (the question is how to. > Do we have any standardization IPython provides? -- I see some ipython > API but don't understand it as for now) There's nbviewer: https://github.com/ipython/nbconvert to convert to and from .ipynb files. You should be able to use this for rendering. -- -- Andreas. From lists at hilboll.de Sun Apr 28 03:49:38 2013 From: lists at hilboll.de (Andreas Hilboll) Date: Sun, 28 Apr 2013 09:49:38 +0200 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517B883C.9050403@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> Message-ID: <517CD492.7050109@hilboll.de> >> 2. Integrating with Content Management System > > While this is nice, I think we should try to focus. What I would think > is more important for SPC would be a IPython Notebook integration. Like > having a "download notebook" link for each item. I think we need to try and figure out the data model for submissions. I'll use the term "item" for submissions. Some questions: 1. What is an item? 2. Are there different categories of items? -> code snippets, links, ? a. What are the characteristics of the category? 3. Do we want SPC to be a sort-of "catalog" of the scientific Python world? So that there could be entries (maybe realized as 'link') for all the great modules out there. 4. Do we want every user to be able to modify an item? This is where using a CMS as base might be helpful. a. every component of an item (including code)? b. only parts (e.g. tagging, but no code)? 5. How do comments fit in? This list is by no means complete, but some parts of it are important for the GSoC project. For example, we need to know how an item looks like before you can implement notebook conversion / rendering. To summarize, I am in favor of having a clear picture of what we want SPC to be before we actually start too far down a road which might lead to a dead end. Any ideas are welcome! BTW: Is this discussion annoying to the developers of "real" SciPy? Should we move somewhere else? -- -- Andreas. From josef.pktd at gmail.com Sun Apr 28 07:04:11 2013 From: josef.pktd at gmail.com (josef.pktd at gmail.com) Date: Sun, 28 Apr 2013 07:04:11 -0400 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: <517CD492.7050109@hilboll.de> References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517CD492.7050109@hilboll.de> Message-ID: On Sun, Apr 28, 2013 at 3:49 AM, Andreas Hilboll wrote: >>> 2. Integrating with Content Management System >> >> While this is nice, I think we should try to focus. What I would think >> is more important for SPC would be a IPython Notebook integration. Like >> having a "download notebook" link for each item. > > I think we need to try and figure out the data model for submissions. > I'll use the term "item" for submissions. Some questions: > > 1. What is an item? > 2. Are there different categories of items? -> code snippets, links, ? > a. What are the characteristics of the category? > 3. Do we want SPC to be a sort-of "catalog" of the scientific Python > world? So that there could be entries (maybe realized as 'link') for > all the great modules out there. > 4. Do we want every user to be able to modify an item? This is where > using a CMS as base might be helpful. > a. every component of an item (including code)? > b. only parts (e.g. tagging, but no code)? > 5. How do comments fit in? > > This list is by no means complete, but some parts of it are important > for the GSoC project. For example, we need to know how an item looks > like before you can implement notebook conversion / rendering. > > To summarize, I am in favor of having a clear picture of what we want > SPC to be before we actually start too far down a road which might lead > to a dead end. > > Any ideas are welcome! One question that needs to be addressed in some form are "administrators" for the content. How do we flag and remove spam, advertising, ... I guess it will need at least some community support in keeping scipy-central "clean" > > BTW: Is this discussion annoying to the developers of "real" SciPy? > Should we move somewhere else? I think it's fine to keep the discussion here for now, it will be a scipy GSOC project after all. Josef > > -- > -- Andreas. > _______________________________________________ > SciPy-Dev mailing list > SciPy-Dev at scipy.org > http://mail.scipy.org/mailman/listinfo/scipy-dev From suryak at ieee.org Sun Apr 28 07:50:50 2013 From: suryak at ieee.org (Surya Kasturi) Date: Sun, 28 Apr 2013 17:20:50 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517CD492.7050109@hilboll.de> Message-ID: On Sun, Apr 28, 2013 at 4:34 PM, wrote: > On Sun, Apr 28, 2013 at 3:49 AM, Andreas Hilboll wrote: > >>> 2. Integrating with Content Management System > >> > >> While this is nice, I think we should try to focus. What I would think > >> is more important for SPC would be a IPython Notebook integration. Like > >> having a "download notebook" link for each item. > > > > I think we need to try and figure out the data model for submissions. > > I'll use the term "item" for submissions. Some questions: > > > > 1. What is an item? > > 2. Are there different categories of items? -> code snippets, links, ? > > a. What are the characteristics of the category? > > 3. Do we want SPC to be a sort-of "catalog" of the scientific Python > > world? So that there could be entries (maybe realized as 'link') for > > all the great modules out there. > > 4. Do we want every user to be able to modify an item? This is where > > using a CMS as base might be helpful. > > a. every component of an item (including code)? > > b. only parts (e.g. tagging, but no code)? > > 5. How do comments fit in? > > > > This list is by no means complete, but some parts of it are important > > for the GSoC project. For example, we need to know how an item looks > > like before you can implement notebook conversion / rendering. > > > > To summarize, I am in favor of having a clear picture of what we want > > SPC to be before we actually start too far down a road which might lead > > to a dead end. > > > > Any ideas are welcome! > > One question that needs to be addressed in some form are > "administrators" for the content. > How do we flag and remove spam, advertising, ... > > There is already "is displayed" field in Revisions/ Submissions.. which can be used to manage spc submissions. All we got to do is provide some admin rights to access that particular model to people who are willing to monitor. > I guess it will need at least some community support in keeping > scipy-central "clean" > > > > > BTW: Is this discussion annoying to the developers of "real" SciPy? > > Should we move somewhere else? > > I think it's fine to keep the discussion here for now, it will be a > scipy GSOC project after all. > > Actually, I think there is a lot to do in SPC.. and is the reason why many suggestions, comments have come up.. I have quite noted few points from this thread which I wish to implement later on! Josef > > > > > -- > > -- Andreas. > > _______________________________________________ > > 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 pav at iki.fi Sun Apr 28 11:50:29 2013 From: pav at iki.fi (Pauli Virtanen) Date: Sun, 28 Apr 2013 18:50:29 +0300 Subject: [SciPy-Dev] Adding startiter keyword to scipy.integrate.quadrature In-Reply-To: References: Message-ID: Hi, 27.04.2013 20:15, Andrew Nelson kirjoitti: > I am proposing to add the 'startiter' keyword to > scipy.integrate.quadrature. I don't see problems in adding this, so go ahead. Note that new keyword arguments go at the end of the argument list, for backwards compatibility reasons. Best, -- Pauli Virtanen From blake.a.griffith at gmail.com Tue Apr 30 00:43:30 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Mon, 29 Apr 2013 23:43:30 -0500 Subject: [SciPy-Dev] GSoC proposal -- Help! Message-ID: Hello, sorry to send this out again, but no one responded last time. I'm proposing to work on scipy sparse for this GSoC. My proposal is titled: Improvements to the sparse package of Scipy: support for bool dtype and better interaction with NumPy Please let me know if you think there is anything I can do to improve it! Link: https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown -------------- next part -------------- An HTML attachment was scrubbed... URL: From suryak at ieee.org Tue Apr 30 05:23:47 2013 From: suryak at ieee.org (Surya Kasturi) Date: Tue, 30 Apr 2013 14:53:47 +0530 Subject: [SciPy-Dev] SciPy Central in GSoC 2013 In-Reply-To: References: <517016F3.30408@hilboll.de> <517B883C.9050403@hilboll.de> <517CD492.7050109@hilboll.de> Message-ID: On Sun, Apr 28, 2013 at 5:20 PM, Surya Kasturi wrote: > > > > On Sun, Apr 28, 2013 at 4:34 PM, wrote: > >> On Sun, Apr 28, 2013 at 3:49 AM, Andreas Hilboll >> wrote: >> >>> 2. Integrating with Content Management System >> >> >> >> While this is nice, I think we should try to focus. What I would think >> >> is more important for SPC would be a IPython Notebook integration. Like >> >> having a "download notebook" link for each item. >> > >> > I think we need to try and figure out the data model for submissions. >> > I'll use the term "item" for submissions. Some questions: >> > >> > 1. What is an item? >> > 2. Are there different categories of items? -> code snippets, links, ? >> > a. What are the characteristics of the category? >> > 3. Do we want SPC to be a sort-of "catalog" of the scientific Python >> > world? So that there could be entries (maybe realized as 'link') for >> > all the great modules out there. >> > 4. Do we want every user to be able to modify an item? This is where >> > using a CMS as base might be helpful. >> > a. every component of an item (including code)? >> > b. only parts (e.g. tagging, but no code)? >> > 5. How do comments fit in? >> > >> > This list is by no means complete, but some parts of it are important >> > for the GSoC project. For example, we need to know how an item looks >> > like before you can implement notebook conversion / rendering. >> > >> > To summarize, I am in favor of having a clear picture of what we want >> > SPC to be before we actually start too far down a road which might lead >> > to a dead end. >> > >> > Any ideas are welcome! >> >> One question that needs to be addressed in some form are >> "administrators" for the content. >> How do we flag and remove spam, advertising, ... >> >> There is already "is displayed" field in Revisions/ Submissions.. which > can be used to manage spc submissions. All we got to do is provide some > admin rights to access that particular model to people who are willing to > monitor. > > >> I guess it will need at least some community support in keeping >> scipy-central "clean" >> >> > >> > BTW: Is this discussion annoying to the developers of "real" SciPy? >> > Should we move somewhere else? >> >> I think it's fine to keep the discussion here for now, it will be a >> scipy GSOC project after all. >> >> Actually, I think there is a lot to do in SPC.. and is the reason why > many suggestions, comments have come up.. I have quite noted few points > from this thread which I wish to implement later on! > > Josef >> >> > >> > -- >> > -- Andreas. >> > _______________________________________________ >> > 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 >> > > I have edited the existing proposal and added Ipython notebook implementation to it.. and removed "CMS integration" http://surya-gsoc2013.blogspot.in/2013/04/the-proposal.html Also submitted in google-melange.com. Please take a look into it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Tue Apr 30 10:15:52 2013 From: charlesr.harris at gmail.com (Charles R Harris) Date: Tue, 30 Apr 2013 08:15:52 -0600 Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy In-Reply-To: References: Message-ID: On Sat, Apr 27, 2013 at 1:17 AM, Blake Griffith wrote: > Seeking feedback, comments, and criticism > > Link: > > https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown > > > Do any of the sparse folks have some feedback here? Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From smith.daniel.br at gmail.com Tue Apr 30 13:36:59 2013 From: smith.daniel.br at gmail.com (Daniel Smith) Date: Tue, 30 Apr 2013 13:36:59 -0400 Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy Message-ID: >> Seeking feedback, comments, and criticism >> >> Link: >> >> https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown >> >> >> > Do any of the sparse folks have some feedback here? > > Chuck I don't know much about the details/scope of the GSoC or their proposal process, but I can give some thoughts about the proposed changes. Adding the bool data type to would be cool. I think pv has already discussed some of the issues with that on here. For the ufuncs improvements, I would just recommend that you be careful about potential ndarray/matrix incompatibilities. The SciPy sparse class has a bunch of backends and an unpleasant amount of repeated code to implement those interfaces. Consolidating interface code while adding the ufunc functionality would be very helpful. Even if you only consolidate some CSC/CSR repeated code, that could make longer term upkeep a lot easier. NumPy has moved towards the matrix class being a wrapper that simply changes the interface to the existing ndarray functionality. It seems that they are also trying to deprecate the use of matrices. Moving the sparse class closer to a universal ndarray interface would be an excellent goal, but just adding another interface could cause more problems than help. Daniel From smith.daniel.br at gmail.com Tue Apr 30 13:45:17 2013 From: smith.daniel.br at gmail.com (Daniel Smith) Date: Tue, 30 Apr 2013 17:45:17 +0000 (UTC) Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy References: Message-ID: Daniel Smith gmail.com> writes: > > > For the ufuncs improvements, I would just recommend that you be > careful about potential ndarray/matrix incompatibilities. The SciPy > sparse class has a bunch of backends and an unpleasant amount of > repeated code to implement those interfaces. Consolidating interface > code while adding the ufunc functionality would be very helpful. Even > if you only consolidate some CSC/CSR repeated code, that could make > longer term upkeep a lot easier. > > Daniel > Looking over things again, repeated code between CSR/CSC is less of an issue than I thought. But the point stands for CSC/CSR and LIL. Daniel From blake.a.griffith at gmail.com Tue Apr 30 14:28:42 2013 From: blake.a.griffith at gmail.com (Blake Griffith) Date: Tue, 30 Apr 2013 13:28:42 -0500 Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy In-Reply-To: References: Message-ID: Thank you Daniel, I should mention pv is the mentor for this proposal. We have been discussing what improving numpy ndarray interaction would involve. Maybe you can tell but the way I'm proposing to do this will be done is not exactly well defined. The way it will probably work: 1. The numpy ufunc class will recognize it is operating on a sparse matrix, so it will dispatch the operation and args to a 'magic function' in the sparse package. 2. The magic function will look at the operation and type of args (sparse/dense, sparse/sparse, sparse, etc.) then call the correct sparse function/method. (Currently most of these are methods, but should probably be functions, this would eliminate a lot of repeated code and help consolidate the interface... I think.) 3. The function will do the operation and handle the guess work of whether a sparse or dense matrix should be returned. (A lot of these functions do not exist. e.g divide, add, etc.) CSR/CSC matrices are the first priority. Since it is better to have them %100 working than all sparse types be %80 working. About ndarray/matrix incompatibilities, I should probably just change the language of the proposal like "numpy arrays and matrices -> ndarray types". On Tue, Apr 30, 2013 at 12:45 PM, Daniel Smith wrote: > Daniel Smith gmail.com> writes: > > > > > > > For the ufuncs improvements, I would just recommend that you be > > careful about potential ndarray/matrix incompatibilities. The SciPy > > sparse class has a bunch of backends and an unpleasant amount of > > repeated code to implement those interfaces. Consolidating interface > > code while adding the ufunc functionality would be very helpful. Even > > if you only consolidate some CSC/CSR repeated code, that could make > > longer term upkeep a lot easier. > > > > > Daniel > > > > Looking over things again, repeated code between CSR/CSC is less of an > issue than I thought. But the point stands for CSC/CSR and LIL. > > Daniel > > > _______________________________________________ > 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 pav at iki.fi Tue Apr 30 15:02:26 2013 From: pav at iki.fi (Pauli Virtanen) Date: Tue, 30 Apr 2013 22:02:26 +0300 Subject: [SciPy-Dev] GSoC Proposal draft -- Improvements to the sparse package of Scipy: support for bool dtype and better interaction with Numpy In-Reply-To: References: Message-ID: Hi, 27.04.2013 10:17, Blake Griffith kirjoitti: [clip] > https://github.com/cowlicks/GSoC-proposal/blob/master/proposal.markdown Comments: - The second point in the abstract can probably be rephrased to be easier to understand. "allow use of XXX" -> "make XXX work with sparse matrices" - "adding new functions/methods" --- these would for a large part not be new user-visible methods, right? __add__, __minus__, multiply, etc. are already there, although their functionality is at the moment more restricted than it should be, which is to be fixed. - The schedule for the second project in the text says 2+5+3+1 weeks, but the headline 7. I think you want 7 here in total. Is the part "Modify and add binary operation ..." leftover from previous edits? - The schedule looks good to me, and the details written in the plan make sense. - As Daniel notes, the second part may also involve some refactoring of the scipy.sparse code base, so that the same logic is not repeated in several places in the code. Looking for instance at CSR multiply() method: Doing this special casing for each binop can be a bit inefficient --- there may be a better way to write it in a generic form (and maybe on the C++ level). - You may want to ping also the Numpy discussion list on this, as the proposal partly concerns Numpy. -- Pauli Virtanen