http://blog.gmane.org/gmane.comp.python.scientific.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.python.scientific.devel/17812 <pre>Hello, SciPy setup in a virtualenv for Python 2.5.2 failed due to not recognizing 'print_function' in many source files: from __future__ import division, print_function, absolute_import Since the import appears to be unused... $ grep -rnI print_function scipy | grep -v import | wc -l 0 ...would it be correct to remove it?: $ find scipy/ -type f -name "*.py" | \ xargs -n 1 sed -i 's/, print_function//g' -alexei </pre> Alexei Colin 2013-05-24T03:12:55 http://comments.gmane.org/gmane.comp.python.scientific.devel/17809 <pre>In scipy.stats.distributions, some of the distribution classes (subclasses of rv_continuous) override, say, the `fit` method. See, for example, gamma_gen or beta_gen. Is there a standard way for the `fit` method of the subclass to use the docstring of the `fit` method in the parent class? In python 2.7, this monkey patching seems to work: beta_gen.fit.__func__.__doc__ = rv_continuous.fit.__doc__ (This is what I did in https://github.com/scipy/scipy/pull/2519) In python 3.3, however, beta_gen.fit does not have the __func__ attribute. Is there a recommended way to do this? The docstring is rather long, and I'd rather not repeat it in the subclass. Warren _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Warren Weckesser 2013-05-23T20:56:41 http://comments.gmane.org/gmane.comp.python.scientific.devel/17808 <pre>I am pleased to announce release 2013.2 of SfePy. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by the finite element method. The code is based on NumPy and SciPy packages. It is distributed under the new BSD license. Home page: http://sfepy.org Downloads, mailing list, wiki: http://code.google.com/p/sfepy/ Git (source) repository, issue tracker: http://github.com/sfepy Highlights of this release -------------------------- - automatic testing of term calls (many terms fixed w.r.t. corner cases) - new elastic contact plane term + example - translated low level base functions from Cython to C for reusability - improved gallery http://docs.sfepy.org/gallery/gallery For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1 (rather long and technical). Best regards, Robert Cimrman and Contributors (*) (*) Contributors to this release (alphabetical order): Vladimír Lukeš, Ankit Mahato, Matyáš Novák _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Robert Cimrman 2013-05-22T13:48:28 http://comments.gmane.org/gmane.comp.python.scientific.devel/17802 <pre>Dear All, I've recently found myself needing some BLAS level 3 functionality, esp syrk/herk (also requested here: https://github.com/scipy/scipy/issues/2135). Which turned to be rather easy to wrap, but being no f2py expert, I'd like to ask for a review of the patch: https://github.com/bburlo/scipy/compare/master...blas3 Best, Evgeni _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Evgeni Burovski 2013-05-19T18:33:42 http://comments.gmane.org/gmane.comp.python.scientific.devel/17782 <pre>Hi, In a class I'm teaching, Dan Bliss (Cc'ed) noticed that he was getting memory errors while running multiple interpolations on large matrices. After a little futzing, it came down to something like this: &lt;try_interpolators.py&gt; import numpy as np import scipy.interpolate as spi N_ITERS = 50 N = 1000 for i in range(N_ITERS): x = np.arange(N) y = np.empty((N, N)) interp = spi.interp1d(x, y) &lt;/try_interpolators.py&gt; Running this through ``time`` for a snapshot of memory usage gives: /usr/bin/time --format='(%DK data %MK max)' python try_interpolators.py (0K data 410088K max) If I add a ``gc.collect()`` as the last line of the loop above I get: [mb312&lt; at &gt;angela ~/tmp/dan_code]$ /usr/bin/time --format='(%DK data %MK max)' python try_interpolators.py (0K data 42396K max) - a ten-fold memory difference. Investigating scipy.interpolate.interp1d, it holds a reference to self, for the function it will call for the interpolation. Thus in the default case: interp = spi.interp1d(x, y) interp._call holds a reference to self via self._call_linear I think (but I'm happy to be corrected) that this is why the interp1d objects are not getting freed without explicit garbage collection. Applying the attached patch to break this cycle results in the original (no garbage collection) script giving: (scipy-dev)[mb312&lt; at &gt;angela ~/tmp/dan_code]$ /usr/bin/time --format='(%DK data %MK max)' python try_interpolators.py (0K data 43648K max) Is this the right analysis? Is this the right patch? Cheers, Matthew _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Matthew Brett 2013-05-18T07:11:09 http://comments.gmane.org/gmane.comp.python.scientific.devel/17780 <pre>Hello SciPy, I've been writing up how I think adding support for boolean operations and the bool dtype should work. You can read the document on my GitHub, here https://github.com/cowlicks/scipy-sparse-boolean-spec/blob/master/spec.rst I'd love some feedback. Thanks! _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Blake Griffith 2013-05-17T04:45:46 http://comments.gmane.org/gmane.comp.python.scientific.devel/17774 <pre>I'm starting to take a look at the bundled libraries in scipy from the Fedora package, starting with arpack and qhull. Are there any mechanisms in place at the moment for building scipy with the system versions of these libraries? I don't see any. I'm attaching my first attempt at a patch to allow this by specifying options in the site.cfg file. But it appears that get_info only works with certain pre-defined strings. Is that right? This seems pretty cumbersome. Can anyone help me with this? Let me know if I'm on the right track or not with this. Thanks! PS - If anyone can think of other libraries bundled with scipy, please let me know. </pre> Orion Poplawski 2013-05-16T03:24:12 http://comments.gmane.org/gmane.comp.python.scientific.devel/17768 <pre>Hi, Perhaps I am just checking an old documentation site... Anyway, on this page: http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.brentq.html#scipy.optimize.brentq the argument rtol is mentioned as an valid argument to brenqt, but it is not explained on the page. Is this a bug? Nicky _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> nicky van foreest 2013-05-11T20:20:27 http://comments.gmane.org/gmane.comp.python.scientific.devel/17767 <pre>Just an observation (too late to do anything about it) Some comments to trac tickets are in a different sequence in github issues https://github.com/scipy/scipy/issues/2108 http://projects.scipy.org/scipy/ticket/1583 But maybe that's a special case, because the trac ticket comments might have been simultaneously edited during a time when trac was very slow. Josef </pre> josef.pktd< at >gmail.com 2013-05-11T12:54:31 http://comments.gmane.org/gmane.comp.python.scientific.devel/17764 <pre>Has anyone else noticed github being very slow this afternoon? Maybe it's the fault of Starbucks' wifi, but other sites don't seem particularly slow. Warren _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Warren Weckesser 2013-05-10T21:25:14 http://comments.gmane.org/gmane.comp.python.scientific.devel/17754 <pre>Dear all, We are working on migrating the front of http://scipy.org away from the wiki to a static site, which also should address the performance problems the site has been encountering recently. Please take a look at what is to come: http://scipy.github.io/ The content currently on the wiki will not go away, of course. If you have any comments, please reply on scipy-dev. Thanks, </pre> Pauli Virtanen 2013-05-10T13:33:24 http://comments.gmane.org/gmane.comp.python.scientific.devel/17750 <pre>Hi All, We've just merged a couple of pull requests which greatly improve the conformance of the scipy code to the pep8 style guidelines: http://www.python.org/dev/peps/pep-0008/ In order to maintain consistency of code, I would like to recommend that before developers commit (or before they submit a PR) they run the "pep8" script over the code to make sure no errors are flagged. The pep8 script can be found here: https://github.com/jcrocholl/pep8 The file tox.ini has been updated to contain a [pep8] section, which contains the current configuration for scipy. In particular, it lists certain error codes which we currently ignore, and automatically generated python files, which we also ignore. NOTE: The latest stable release of pep8 (1.4.5) has a bug which breaks the ignore-file functionality. If you use this version you can expect to see a bunch of errors from the files in sparsetools. The current master branch of pep8 on github has this issue fixed, so it is recommended to use this version. If everything is correctly installed and there are no pep8 errors you should see the following behaviour: ~/src/scipy$ pep8 scipy ~/src/scipy$ Cheers, Tim _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Tim Leslie 2013-05-06T23:50:14 http://comments.gmane.org/gmane.comp.python.scientific.devel/17747 <pre>'0.13.0.dev-024abe7' ====================================================================== FAIL: test_binom_2 (test_basic.TestCephes) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/tests/test_basic.py", line 85, in test_binom_2 atol=1e-10, rtol=1e-10) File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/_testutils.py", line 87, in assert_func_equal fdata.check() File "/home/nils/local/lib64/python2.7/site-packages/scipy/special/_testutils.py", line 292, in check assert_(False, "\n".join(msg)) File "/home/nils/local/lib64/python2.7/site-packages/numpy/testing/utils.py", line 41, in assert_ raise AssertionError(msg) AssertionError: Max |adiff|: 2.14065e+273 Max |rdiff|: 1 Bad results (19 out of 2040) for the following points (in output 0): 5.4555947811685144e+16 19.0 =&gt; 8.220635246624177e+300 != inf (rdiff 0.0) 2.9763514416313132e+32 9.0 =&gt; 5.051203457981723e+286 != inf (rdiff 0.0) 1.6237767391887178e+48 6.0 =&gt; 2.5458065428227896e+286 != inf (rdiff 0.0) 8.858667904100795e+63 4.0 =&gt; 2.5660342127750743e+254 != inf (rdiff 0.0) 4.832930238571653e+79 3.0 =&gt; 1.8813964861410318e+238 != inf (rdiff 0.0) 2.6366508987303447e+95 3.0 =&gt; 3.054967851387346e+285 != inf (rdiff 0.0) 1.4384498882876777e+111 2.0 =&gt; 1.0345690405574163e+222 != inf (rdiff 0.0) 7.847599703514559e+126 2.0 =&gt; 3.07924105533009e+253 != inf (rdiff 0.0) 4.2813323987192907e+142 2.0 =&gt; 9.164903554161738e+284 != inf (rdiff 0.0) 2.3357214690900255e+158 1.0 =&gt; 2.3357214690900255e+158 != inf (rdiff 0.0) 1.2742749857031426e+174 1.0 =&gt; 1.2742749857031426e+174 != inf (rdiff 0.0) 6.951927961775534e+189 1.0 =&gt; 6.951927961775534e+189 != inf (rdiff 0.0) 3.792690190732145e+205 1.0 =&gt; 3.792690190732145e+205 != inf (rdiff 0.0) 2.0691380811148325e+221 1.0 =&gt; 2.0691380811148325e+221 != inf (rdiff 0.0) 1.128837891684693e+237 1.0 =&gt; 1.128837891684693e+237 != inf (rdiff 0.0) 6.158482110660179e+252 1.0 =&gt; 6.158482110660179e+252 != inf (rdiff 0.0) 3.359818286283898e+268 1.0 =&gt; 3.359818286283898e+268 != inf (rdiff 0.0) 1.8329807108323476e+284 1.0 =&gt; 1.8329807108323476e+284 != inf (rdiff 0.0) 1e+300 1.0 =&gt; 1e+300 != inf (rdiff 0.0) ---------------------------------------------------------------------- Ran 6446 tests in 203.406s FAILED (KNOWNFAIL=27, SKIP=158, failures=2) _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Nils Wagner 2013-05-06T18:31:11 http://comments.gmane.org/gmane.comp.python.scientific.devel/17736 <pre>Hi all, I spent some time fixing building with Bento: https://github.com/scipy/scipy/pull/2447. Try it out if you regularly build scipy - for me it's 5x faster than a distutils build, and the difference is even larger when disregarding the Cythonizing step. We still have support for Numscons, although it has been broken for several months. Supporting three build systems is at least one too many, so I propose to remove the numscons support. Any objections? Ralf _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Ralf Gommers 2013-05-05T10:02:02 http://comments.gmane.org/gmane.comp.python.scientific.devel/17732 <pre>Hi all, I wrote a GSoC project proposal. Unfortunately I didn't manage to get through a feedback loop to improve it based on your comments - had some trouble registering for the mailing list before. It is up on Melange as "SciPy: Improving Numerical Integration of Time Series" - probably under this link: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/kermit666/2# My main motivation is that the current way to integrate a time series in Python (due to Pandas using miliseconds as its underlying structure [1]): integrate.simps(ts, ts.index.astype(np.int64) / 10**9) executes with a big overhead (of first having to divide every element to get a 1 integer unit = 1 second representation) and feels somewhat unpythonic. This gist illustrates the performance overhead that's troubling me: http://nbviewer.ipython.org/5512857 I would like to explore ways to rely on the basic timestamp arithmetic in scipy (dynamically, without introducing any dependencies), instead of forcing the user to transform the whole data domain. If there is any time left after this, the usability of scipy.integrate for time series integration could be further improved by adding some new features to Pandas too [2]. Is there perhaps anyone willing to mentor such work? Regards, Dražen Lučanin [1]: http://stackoverflow.com/questions/15203623/convert-pandas-datetimeindex-to-unix-time [2]: https://github.com/pydata/pandas/issues/2704 _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Dražen Lučanin 2013-05-04T11:33:20 http://comments.gmane.org/gmane.comp.python.scientific.devel/17731 <pre>Hi all, I found a (new) test failure. Seems to be an accuracy issue. '0.13.0.dev-ccbdff8' '1.8.0.dev-004ce27' umfpack_info: NOT AVAILABLE atlas_threads_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/nils/local/lib/'] define_macros = [('ATLAS_INFO', '"\\"3.10.1\\""')] language = f77 blas_opt_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/nils/local/lib/'] define_macros = [('ATLAS_INFO', '"\\"3.10.1\\""')] language = c atlas_blas_threads_info: libraries = ['ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/nils/local/lib/'] define_macros = [('ATLAS_INFO', '"\\"3.10.1\\""')] language = c lapack_opt_info: libraries = ['lapack', 'ptf77blas', 'ptcblas', 'atlas'] library_dirs = ['/home/nils/local/lib/'] define_macros = [('ATLAS_INFO', '"\\"3.10.1\\""')] language = f77 lapack_mkl_info: NOT AVAILABLE blas_mkl_info: NOT AVAILABLE mkl_info: NOT AVAILABLE ====================================================================== FAIL: test_qz_complex64 (test_decomp.TestQZ) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/nils/local/lib64/python2.7/site-packages/scipy/linalg/tests/test_decomp.py", line 1765, in test_qz_complex64 assert_array_almost_equal(dot(dot(Q,AA),Z.conjugate().T), A) File "/home/nils/local/lib64/python2.7/site-packages/numpy/testing/utils.py", line 818, in assert_array_almost_equal header=('Arrays are not almost equal to %d decimals' % decimal)) File "/home/nils/local/lib64/python2.7/site-packages/numpy/testing/utils.py", line 651, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 6 decimals (mismatch 4.0%) x: array([[ 0.92961562+0.72968888j, 0.31637603+0.99401349j, 0.18391919+0.67687315j, 0.20456034+0.79082197j, 0.56772506+0.17091417j],... y: array([[ 0.92961609+0.72968906j, 0.31637555+0.99401456j, 0.18391882+0.67687368j, 0.20456028+0.79082251j, 0.56772500+0.17091426j],... ---------------------------------------------------------------------- Ran 6411 tests in 208.475s FAILED (KNOWNFAIL=28, SKIP=158, failures=1) &lt;nose.result.TextTestResult run=6411 errors=0 failures=1&gt; _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Nils Wagner 2013-05-04T08:22:45 http://comments.gmane.org/gmane.comp.python.scientific.devel/17728 <pre>Hi, The amos library for computing special functions is part of scipy.special. If I understand correctly, routines in the library are being used to compute Bessel function values for complex arguments. However, a version of the algorithm is seen to have been published on TOMS ( http://dl.acm.org/citation.cfm?id=214331). According to the ACM software license, the software isn't really "free" since commercial use is not allowed. How does this work with scipy? Any clarification on the license status of the library will be greatly appreciated since I plan to use it in a routine I intend to publish. Thank you Yours Raziman _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Raziman T V 2013-05-03T19:50:27 http://comments.gmane.org/gmane.comp.python.scientific.devel/17727 <pre>we apologize if you receive multiple copies of this message =================================================================== CALL FOR PAPERS 2013 Workshop on Middleware for HPC and Big Data Systems MHPC '13 as part of Euro-Par 2013, Aachen, Germany =================================================================== Date: August 27, 2012 Workshop URL: http://m-hpc.org Springer LNCS SUBMISSION DEADLINE: May 31, 2013 - LNCS Full paper submission (rolling abstract submission) June 28, 2013 - Lightning Talk abstracts SCOPE Extremely large, diverse, and complex data sets are generated from scientific applications, the Internet, social media and other applications. Data may be physically distributed and shared by an ever larger community. Collecting, aggregating, storing and analyzing large data volumes presents major challenges. Processing such amounts of data efficiently has been an issue to scientific discovery and technological advancement. In addition, making the data accessible, understandable and interoperable includes unsolved problems. Novel middleware architectures, algorithms, and application development frameworks are required. In this workshop we are particularly interested in original work at the intersection of HPC and Big Data with regard to middleware handling and optimizations. Scope is existing and proposed middleware for HPC and big data, including analytics libraries and frameworks. The goal of this workshop is to bring together software architects, middleware and framework developers, data-intensive application developers as well as users from the scientific and engineering community to exchange their experience in processing large datasets and to report their scientific achievement and innovative ideas. The workshop also offers a dedicated forum for these researchers to access the state of the art, to discuss problems and requirements, to identify gaps in current and planned designs, and to collaborate in strategies for scalable data-intensive computing. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections. Presentations may be accompanied by interactive demonstrations. TOPICS Topics of interest include, but are not limited to: - Middleware including: Hadoop, Apache Drill, YARN, Spark/Shark, Hive, Pig, Sqoop, HBase, HDFS, S4, CIEL, Oozie, Impala, Storm and Hyrack - Data intensive middleware architecture - Libraries/Frameworks including: Apache Mahout, Giraph, UIMA and GraphLab - NG Databases including Apache Cassandra, MongoDB and CouchDB/Couchbase - Schedulers including Cascading - Middleware for optimized data locality/in-place data processing - Data handling middleware for deployment in virtualized HPC environments - Parallelization and distributed processing architectures at the middleware level - Integration with cloud middleware and application servers - Runtime environments and system level support for data-intensive computing - Skeletons and patterns - Checkpointing - Programming models and languages - Big Data ETL - Stream processing middleware - In-memory databases for HPC - Scalability and interoperability - Large-scale data storage and distributed file systems - Content-centric addressing and networking - Execution engines, languages and environments including CIEL/Skywriting - Performance analysis, evaluation of data-intensive middleware - In-depth analysis and performance optimizations in existing data-handling middleware, focusing on indexing/fast storing or retrieval between compute and storage nodes - Highly scalable middleware optimized for minimum communication - Use cases and experience for popular Big Data middleware - Middleware security, privacy and trust architectures DATES Papers: Rolling abstract submission May 31, 2013 - Full paper submission July 8, 2013 - Acceptance notification October 3, 2013 - Camera-ready version due Lightning Talks: June 28, 2013 - Deadline for lightning talk abstracts July 15, 2013 - Lightning talk notification August 27, 2013 - Workshop Date TPC CHAIR Michael Alexander (chair), TU Wien, Austria Anastassios Nanos (co-chair), NTUA, Greece Jie Tao (co-chair), Karlsruhe Institut of Technology, Germany Lizhe Wang (co-chair), Chinese Academy of Sciences, China Gianluigi Zanetti (co-chair), CRS4, Italy PROGRAM COMMITTEE Amitanand Aiyer, Facebook, USA Costas Bekas, IBM, Switzerland Jakob Blomer, CERN, Switzerland William Gardner, University of Guelph, Canada José Gracia, HPC Center of the University of Stuttgart, Germany Zhenghua Guom, Indiana University, USA Marcus Hardt, Karlsruhe Institute of Technology, Germany Sverre Jarp, CERN, Switzerland Christopher Jung, Karlsruhe Institute of Technology, Germany Andreas Knüpfer - Technische Universität Dresden, Germany Nectarios Koziris, National Technical University of Athens, Greece Yan Ma, Chinese Academy of Sciences, China Martin Schulz - Lawrence Livermore National Laboratory Viral Shah, MIT Julia Group, USA Dimitrios Tsoumakos, Ionian University, Greece Zhifeng Yun, Louisiana State University, USA PAPER PUBLICATION Accepted full papers will be published in the Springer LNCS series. The best papers of the workshop -- after extension and revision -- will be published in a Special Issue of the Springer Journal of Scalable Computing. PAPER SUBMISSION Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, key words, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. The format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Format Guidelines: http://www.springer.de/comp/lncs/authors.html Style template: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Abstract Registration - Submission Link: http://edas.info/newPaper.php?c=14763 LIGHTNING TALKS Talks are strictly limited to 5 minutes. They can be used to gain early feedback on ongoing research, for demonstrations, to present research results, early research ideas, perspectives and positions of interest to the community. Lightning talks should spark discussion with presenters making themselves available following the lightning talk track. DURATION: Workshop Duration is one day. GENERAL INFORMATION The workshop will be held as part of Euro-Par 2013. Euro-Par 2013: http://www.europar2013.org _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> MHPC 2013 2013-05-03T14:26:14 http://comments.gmane.org/gmane.comp.python.scientific.devel/17725 <pre>I spent a little time wrapping some of intel ipp signal processing library and benchmarking against my hand-written c++ code. So far I've tried some of the FIR filtering (single and multi-rate), and correlation. I was surprised to find that the ipp components were 3-10 times the speed of my c++ code. Perhaps others might want to look at using these components. Of course, they are not free - but this is in the same class as building numpy/scipy using MKL. </pre> Neal Becker 2013-05-02T14:32:11 http://comments.gmane.org/gmane.comp.python.scientific.devel/17717 <pre>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 _______________________________________________ SciPy-Dev mailing list SciPy-Dev&lt; at &gt;scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev </pre> Blake Griffith 2013-04-30T04:43:30 http://comments.gmane.org/gmane.comp.python.scientific.devel/17689 <pre>Sparked by a discussion on numpy-discussion, some points about scipy website migration: 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. </pre> Andreas Hilboll 2013-04-27T07:57:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.python.scientific.devel