[Numpy-discussion] Implementing Levenberg-Marquardt with additional feature
Hello Everyone !! I am Sudheer singh , an information technology student at IIIT - ALLAHABAD. I'm interested in contributing to Numpy.I was going through Idea page and I found Implementing Levenberg-Marquardt with additional feature like inequality constraints and sparse Jacobian matrix. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Implementing Levenberg-Marquardt with additional feature
Sudheer Singh sudheer.ii...@gmail.com wrote: Hello Everyone !! I am Sudheer singh , an information technology student at IIIT - ALLAHABAD. I'm interested in contributing to Numpy.I was going through Idea page and I found Implementing Levenberg-Marquardt with additional feature like inequality constraints and sparse Jacobian matrix. You should rather post this on the SciPy lists :) Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Adding weights to cov and corrcoef
Hi all, in Pull Request https://github.com/numpy/numpy/pull/3864 Neol Dawe suggested adding new parameters to our `cov` and `corrcoef` functions to implement weights, which already exists for `average` (the PR still needs to be adapted). The idea right now would be to add a `weights` and a `frequencies` keyword arguments to these functions. In more detail: The situation is a bit more complex for `cov` and `corrcoef` than `average`, because there are different types of weights. The current plan would be to add two new keyword arguments: * weights: Uncertainty weights which causes `N` to be recalculated accordingly (This is R's `cov.wt` default I believe). * frequencies: When given, `N = sum(frequencies)` and the values are weighted by their frequency. Because it appeared that the uncertainty type of weights are not obvious, while other types of weights should be pretty easily implemented by scaling `frequencies` (i.e. one may want `sum(frequencies) == len(data)`). However, we may have missed something obvious, or maybe it is already getting too statistical for NumPy, or the keyword argument might be better `uncertainties` and `frequencies`. So comments and insights are very welcome :). Regards, Sebastian ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] GSoC 2014 NumPy
On Tue, Mar 4, 2014 at 5:42 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: It's possible to come up with an interesting proposal in this area I think. An issue may be that the FFT code in numpy and scipy isn't very actively worked on at the moment, so finding a suitable mentor could be tricky. So should I choose another topic? Actually, I just read the thread numpy gsoc topic idea and I found that the idea vector math library integration really interests me! And I have a qeustion: how can I find a suitable mentor? Currently I'm digging into the source of numpy and trying to make a small pull request. Also I keep thinking how to write a proper proposal. Are these enough? Can I do more for now? I will be grateful for any advice. Thanks in advance. Regards, Leo Mao ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Adding weights to cov and corrcoef (Sebastian Berg)
Date: Wed, 05 Mar 2014 17:45:47 +0100 From: Sebastian Berg sebast...@sipsolutions.net Subject: [Numpy-discussion] Adding weights to cov and corrcoef To: numpy-discussion@scipy.org Message-ID: 1394037947.21356.20.camel@sebastian-t440 Content-Type: text/plain; charset=UTF-8 Hi all, in Pull Request https://github.com/numpy/numpy/pull/3864 Neol Dawe suggested adding new parameters to our `cov` and `corrcoef` functions to implement weights, which already exists for `average` (the PR still needs to be adapted). Do you mean adopted? However, we may have missed something obvious, or maybe it is already getting too statistical for NumPy, or the keyword argument might be better `uncertainties` and `frequencies`. So comments and insights are very welcome :). +1 for it being too baroque for NumPy--should go in SciPy (if it isn't already there): IMHO, NumPy should be kept as lean and mean as possible, embellishments are what SciPy is for. (Again, IMO.) DG ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] EuroSciPy 2014 Call for Abstracts
Dear all, EuroSciPy 2014, the Seventh Annual Conference on Python in Science, takes place in Cambridge, UK on 27 - 30 August 2013. The conference features two days of tutorials followed by two days of scientific talks. The day after the main conference, developer sprints will be organized on projects of interest to attendees. The topics presented at EuroSciPy are very diverse, with a focus on advanced software engineering and original uses of Python and its scientific libraries, either in theoretical or experimental research, from both academia and the industry. The program includes keynotes, contributed talks and posters. Submissions for talks and posters are welcome on our website (http://www. euroscipy.org/2014/). In your abstract, please provide details on what Python tools are being employed, and how. The deadline for submission is 14 April 2013. Also until 14 April 2014, you can apply for a sprint session on 31 August 2014. See https://www.euroscipy.org/2014/calls/sprints/ for details. Important dates: April 14th: Presentation abstracts, poster, tutorial submission deadline. Application for sponsorship deadline. May 17th: Speakers selected May 22nd: Sponsorship acceptance deadline June 1st: Speaker schedule announced June 6th, or 150 registrants: Early-bird registration ends August 27-31st: 2 days of tutorials, 2 days of conference, 1 day of sprints We look forward to an exciting conference and hope to see you in Cambridge in August! The EuroSciPy 2014 Team http://www.euroscipy.org/2014/ Conference Chairs -- Mark Hayes, Cambridge University, UK Didrik Pinte, Enthought Europe, UK Tutorial Chair --- David Cournapeau, Enthought Europe, UK Program Chair Ralf Gommers, ASML, The Netherlands Program Committee - Tiziano Zito, Humboldt-Universität zu Berlin, Germany Pierre de Buyl, Université libre de Bruxelles, Belgium Emmanuelle Gouillart, Joint Unit CNRS/Saint-Gobain, France Konrad Hinsen, Centre National de la Recherche Scientifique (CNRS), France Raphael Ritz, Garching Computing Centre of the Max Planck Society, Germany Stéfan van der Walt, Applied Mathematics, Stellenbosch University, South Africa Gaël Varoquaux, INRIA Parietal, Saclay, France Nelle Varoquaux, Mines ParisTech, France Pauli Virtanen, Aalto University, Finland Evgeni Burovski, Lancaster University, UK Robert Cimrman, New Technologies Research Centre, University of West Bohemia, Czech Republic Almar Klein, Cybermind, The Netherlands Organizing Committee -- Simon Jagoe, Enthought Europe, UK Pierre de Buyl, Université libre de Bruxelles, Belgium ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] EuroSciPy 2014 Call for Abstracts
Hi Ralf, EuroSciPy 2014, the Seventh Annual Conference on Python in Science, takes place in Cambridge, UK on 27 - 30 August 2013. The conference features two days of tutorials followed by two days of scientific talks. The day after the main conference, developer sprints will be organized on projects of interest to attendees. The topics presented at EuroSciPy are very diverse, with a focus on advanced software engineering and original uses of Python and its scientific libraries, either in theoretical or experimental research, from both academia and the industry. The program includes keynotes, contributed talks and posters. Submissions for talks and posters are welcome on our website (http://www.euroscipy.org/2014/). In your abstract, please provide details on what Python tools are being employed, and how. The deadline for submission is 14 April 2013. Some dates refer to 2013… Cheers, JB ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] EuroSciPy 2014 Call for Abstracts
On Wed, Mar 5, 2014 at 8:39 PM, Jean-Baptiste Marquette marqu...@iap.frwrote: Hi Ralf, EuroSciPy 2014, the Seventh Annual Conference on Python in Science, takes place in Cambridge, UK on 27 - 30 August 2013. The conference features two days of tutorials followed by two days of scientific talks. The day after the main conference, developer sprints will be organized on projects of interest to attendees. The topics presented at EuroSciPy are very diverse, with a focus on advanced software engineering and original uses of Python and its scientific libraries, either in theoretical or experimental research, from both academia and the industry. The program includes keynotes, contributed talks and posters. Submissions for talks and posters are welcome on our website (http://www. euroscipy.org/2014/). In your abstract, please provide details on what Python tools are being employed, and how. The deadline for submission is 14 April 2013. Some dates refer to 2013... Hmm, that's why one shouldn't send emails like these at the end of a long day. Dates are correct except for 2013--2014. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] EuroSciPy 2014 Call for Abstracts
Le 5 mars 2014 à 20:43, Ralf Gommers ralf.gomm...@gmail.com a écrit : Hmm, that's why one shouldn't send emails like these at the end of a long day. Dates are correct except for 2013--2014. « It's only those who do nothing that make no mistakes, I suppose. » Joseph Conrad (An Outcast of the Islands, 1896, pt. 3, chap. 2)___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] GSoC 2014 NumPy
On Wed, Mar 5, 2014 at 5:52 PM, Leo Mao lmao20...@gmail.com wrote: On Tue, Mar 4, 2014 at 5:42 AM, Ralf Gommers ralf.gomm...@gmail.comwrote: It's possible to come up with an interesting proposal in this area I think. An issue may be that the FFT code in numpy and scipy isn't very actively worked on at the moment, so finding a suitable mentor could be tricky. So should I choose another topic? I suspect that that may be better. Actually, I just read the thread numpy gsoc topic idea and I found that the idea vector math library integration really interests me! If it's interesting, I suggest to dive in. It's Julian's idea, so probably he's interested to (co-)mentor a project on this topic. Julian? And I have a qeustion: how can I find a suitable mentor? That's a nontrivial question. Let me send a separate email to the list about that. Currently I'm digging into the source of numpy and trying to make a small pull request. Also I keep thinking how to write a proper proposal. Are these enough? Can I do more for now? Keep in mind that your proposal will need to go through a few rounds of feedback and rework before it's solid enough that you can submit it. The same usually goes for pull requests. Cheers, Ralf I will be grateful for any advice. Thanks in advance. Regards, Leo Mao ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] GSoC: ideas finding mentors
Hi students, There is quite a bit of interest in GSoC ideas for Scipy and Numpy, which is great to see. The official application period to submit proposals opens next week and closes on the 21st, which is in two weeks and a bit. So now is the time to start discussing draft proposals on the list. There have been a few ideas posted on the list which haven't gotten enough feedback yet (FFTs, cluster, ODEs). This may reflect the lack of an active maintainer of those modules, so it will be harder to find a suitable mentor. I want to point out that this is also a chicken-and-egg problem: if you're actively posting and improving your draft and sending some pull requests to fix some small issues, it shows both your willingness to work with the community and how you work with core devs to get your PRs merged, which helps find an interested mentor. To tackle the student-mentor matchmaking from another angle, I've added on https://github.com/scipy/scipy/wiki/GSoC-project-ideas a potential mentors field to the idea I know the names for (Stefan and me, for wavelets). If other potential mentors could do the same for other ideas, that would be very helpful. I can take some guesses (Pauli, Evgeni for splines? Chuck, Chris Barker for datetime?) but I haven't added any names. So please do add your name, keeping in mind that this is to get the process going and not yet a full commitment. Final note: you don't necessarily have to be a core developer to be a co-mentor. If you're an expert on a topic that a student is interested in and would like to see that project happen, please indicate you're willing to help. Cheers, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy gsoc ideas (was: numpy gsoc topic idea: configurable algorithm precision and vector math library integration)
On Mon, Mar 3, 2014 at 7:20 PM, Julian Taylor jtaylor.deb...@googlemail.com wrote: hi, as the numpy gsoc topic page is a little short on options I was thinking about adding two topics for interested students. But as I have no experience with gsoc or mentoring and the ideas are not very fleshed out yet I'd like to ask if it might make sense at all: 1. configurable algorithm precision [...] with np.precmode(default=fast): np.abs(complex_array) or fast everything except sum and hypot with np.precmode(default=fast, sum=kahan, hypot=standard): np.sum(d) [...] Not a big fan of this one -- it seems like the biggest bulk of the effort would be in figuring out a non-horrible API for exposing these things and getting consensus around it, which is not a good fit to the SoC structure. I'm pretty nervous about the datetime proposal that's currently on the wiki, for similar reasons -- I'm not sure it's actually doable in the SoC context. 2. vector math library integration This is a great suggestion -- clear scope, clear benefit. Two more ideas: 3. Using Cython in the numpy core The numpy core contains tons of complicated C code implementing elaborate operations like indexing, casting, ufunc dispatch, etc. It would be really nice if we could use Cython to write some of these things. However, there is a practical problem: Cython assumes that each .pyx file generates a single compiled module with its own Cython-defined API. Numpy, however, contains a large number of .c files which are all compiled together into a single module, with its own home-brewed system for defining the public API. And we can't rewrite the whole thing. So for this to be viable, we would need some way to compile a bunch of .c *and .pyx* files together into a single module, and allow the .c and .pyx files to call each other. This might involve changes to Cython, some sort of clever post-processing or glue code to get existing cython-generated source code to play nicely with the rest of numpy, or something else. So this project would have the following goals, depending on how practical this turns out to be: (1) produce a hacky proof-of-concept system for doing the above, (2) turn the hacky proof-of-concept into something actually viable for use in real life (possibly this would require getting changes upstream into Cython, etc.), (3) use this system to actually port some interesting numpy code into cython. 4. Pythonic dtypes The current dtype system is klugey. It basically defines its own class system, in parallel to Python's, and unsurprisingly, this new class system is not as good. In particular, it has limitations around the storage of instance-specific data which rule out a large variety of interesting user-defined dtypes, and causes us to need some truly nasty hacks to support the built-in dtypes we do have. And it makes defining a new dtype much more complicated than defining a new Python class. This project would be to implement a new dtype system for numpy, in which np.dtype becomes a near-empty base class, different dtypes (e.g., float64, float32) are simply different subclasses of np.dtype, and dtype objects are simply instances of these classes. Further enhancements would be to make it possible to define new dtypes in pure Python by subclassing np.dtype and implementing special methods for the various dtype operations, and to make it possible for ufunc loops to see the dtype objects. This project would provide the key enabling piece for a wide variety of interesting new features: missing value support, better handling of strings and categorical data, unit handling, automatic differentiation, and probably a bunch more I'm forgetting right now. If we get someone who's up to handling the dtype thing then I can mentor or co-mentor. What do y'all think? (I don't think I have access to update that wiki page -- or maybe I'm just not clever enough to figure out how -- so it would be helpful if someone who can, could?) -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8.1rc1 on sourceforge.
Hi, I built (and tested) some numpy wheels for the rc1: http://nipy.bic.berkeley.edu/numpy-dist/ Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.8.1rc1 on sourceforge.
Hi, On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, I built (and tested) some numpy wheels for the rc1: http://nipy.bic.berkeley.edu/numpy-dist/ Now building, installing, testing, uploading wheels nightly on OSX 10.9: http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7 http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3 and downloading, testing built wheels on OSX 10.6: http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-2.7-downloaded http://nipy.bic.berkeley.edu/builders/numpy-bdist-whl-osx-3.3-downloaded Chuck - are you release manager for this cycle? Would you mind sending me your public ssh key so I can give you access to the buildbots for custom builds and so on? Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy gsoc ideas (was: numpy gsoc topic idea: configurable algorithm precision and vector math library integration)
Nathaniel Smith n...@pobox.com wrote: 3. Using Cython in the numpy core The numpy core contains tons of complicated C code implementing elaborate operations like indexing, casting, ufunc dispatch, etc. It would be really nice if we could use Cython to write some of these things. So the idea of having a NumPy as a pure C library in the core is abandoned? However, there is a practical problem: Cython assumes that each .pyx file generates a single compiled module with its own Cython-defined API. Numpy, however, contains a large number of .c files which are all compiled together into a single module, with its own home-brewed system for defining the public API. And we can't rewrite the whole thing. So for this to be viable, we would need some way to compile a bunch of .c *and .pyx* files together into a single module, and allow the .c and .pyx files to call each other. Cython takes care of that already. http://docs.cython.org/src/userguide/sharing_declarations.html#cimport http://docs.cython.org/src/userguide/external_C_code.html#using-cython-declarations-from-c Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
