Mailman 3 March 2014 - NumPy-Discussion

ANN: Bokeh 0.4.2
by Bryan Van de Ven 10 Mar '14

10 Mar '14

I am happy to announce the release of Bokeh version 0.4.2! Bokeh is a Python library for visualizing large and realtime datasets on the web. Its goal is to provide elegant, concise construction of novel graphics in the style of Protovis/D3, while delivering high-performance interactivity to thin clients. Bokeh includes its own Javascript library (BokehJS) that implements a reactive scenegraph representation of the plot, and renders efficiently to HTML5 Canvas. Bokeh works well with IPython Notebook, but can generate standalone graphics that embed into regular HTML. Check out the full documentation, interactive gallery, and tutorial at http://bokeh.pydata.org If you are using Anaconda, you can install with conda: conda install bokeh Alternatively, you can install with pip: pip install bokeh Some of the new features in this release include: * Additional Matplotlib and Seaborn compatibility (PolyCollection) * Extensive tutorial with exercises and solutions added to docs * new %bokeh magic for improved IPython notebook integration * Windows support for bokeh-server with two new storage backends (in-memory and shelve) Also, we've fixed lots of little bugs - see the CHANGELOG for full details. BokehJS is also available by CDN for use in standalone javascript applications: http://cdn.pydata.org/bokeh-0.4.2.js http://cdn.pydata.org/bokeh-0.4.2.css http://cdn.pydata.org/bokeh-0.4.2.min.js http://cdn.pydata.org/bokeh-0.4.2.min.css Some examples of BokehJS use can be found on the Bokeh JSFiddle page: http://jsfiddle.net/user/bokeh/fiddles/ The release of Bokeh 0.5 is planned for late March. Some notable features we plan to include are: * Abstract Rendering for semantically meaningful downsampling of large datasets * Better grid-based layout system, using Cassowary.js * More MPL/Seaborn/ggplot.py compatibility and examples * Additional tools, improved interactions, and better plot frame * Touch support Issues, enhancement requests, and pull requests can be made on the Bokeh Github page: https://github.com/continuumio/bokeh Questions can be directed to the Bokeh mailing list: bokeh(a)continuum.io Special thanks to recent contributors: Melissa Gymrek, Amy Troschinetz, Ben Zaitlen, Damian Avila, and Terry Jones Regards, Bryan Van de Ven Continuum Analytics http://continuum.io

1 0

SVG Logo of NumPy
by Christophe Bal 10 Mar '14

10 Mar '14

Hello, is there a SVG version of the NumPy logo ? This would be to be used on my website. Christophe BAL

2 2

numpy gsoc ideas (was: numpy gsoc topic idea: configurable algorithm precision and vector math library integration)
by Nathaniel Smith 07 Mar '14

07 Mar '14

On Mon, Mar 3, 2014 at 7:20 PM, Julian Taylor <jtaylor.debian(a)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

5 7

numpy apply_along_axis named arguments
by Albert Jornet Puig 07 Mar '14

07 Mar '14

Hi All, I am working with *apply_along_axis* method and I would like to apply a method that requires to pass named arguments (scipy.stats.mstats.mquantiles with prob[]). But currently, it is not possible with *apply_along_axis*. I wonder if it would make sense to add the possibility to pass named arguments. I am also aware that It could be implement using other ways (a loop for each row). That's why I would like to ask whether it makes sense or not to ask for this. Even though, I managed to modify the code, which is simple. http://pastebin.com/pBn0TbgK

2 2

Adding weights to cov and corrcoef
by Sebastian Berg 07 Mar '14

07 Mar '14

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

4 5

Re: [Numpy-discussion] Adding weights to cov and corrcoef (Sebastian Berg)
by David Goldsmith 06 Mar '14

06 Mar '14

Date: Wed, 05 Mar 2014 17:45:47 +0100 > From: Sebastian Berg <sebastian(a)sipsolutions.net> > Subject: [Numpy-discussion] Adding weights to cov and corrcoef > To: numpy-discussion(a)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

5 8

Re: [Numpy-discussion] Adding weights to cov and corrcoef
by David Goldsmith 06 Mar '14

06 Mar '14

Date: Thu, 06 Mar 2014 13:40:40 +0100 > From: Sebastian Berg <sebastian(a)sipsolutions.net> > Subject: Re: [Numpy-discussion] Adding weights to cov and corrcoef > (Sebastian Berg) > To: numpy-discussion(a)scipy.org > Message-ID: <1394109640.9122.13.camel@sebastian-t440> > Content-Type: text/plain; charset="UTF-8" > > On Mi, 2014-03-05 at 10:21 -0800, David Goldsmith wrote: > > +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.) > > > > Well, on the other hand, scipy does not actually have a `std` function > of its own, I think. Oh, well, in that case forget I said anything. (Though I think it's "interesting" that no one else has chimed in: if you're the only one that needs it (at this time), perhaps it would be best to "roll your own" and then offer to "pass it around." :-)) DG > So if it is quite useful I think this may be an > option (I don't think I ever used weights with std, so I can't argue > strongly for inclusion myself). Unless adding new functions to > `scipy.stats` (or just statsmodels) which implement different types of > weights is the longer term plan, then things might bite... > > > DG > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > > ------------------------------ > > Message: 5 > Date: Thu, 6 Mar 2014 13:45:36 +0000 > From: Nathaniel Smith <njs(a)pobox.com> > Subject: Re: [Numpy-discussion] numpy gsoc ideas (was: numpy gsoc > topic idea: configurable algorithm precision and vector math > library > integration) > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: > <CAPJVwBm=no71WvC9Zjh7DXNaGn0jpAGmvrOyoVvmHK-MW= > R3Fw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 6, 2014 at 5:17 AM, Sturla Molden <sturla.molden(a)gmail.com> > wrote: > > Nathaniel Smith <njs(a)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? > > This question doesn't make sense to me so I think I must be missing > some context. > > Nothing is abandoned: This is one email by one person on one mailing > list suggesting a project to the explore the feasibility of something. > And anyway, Cython is just a C code generator, similar in principle to > (though vastly more sophisticated than) the ones we already use. It's > not like we've ever promised our users we'll keep stable which kind of > code generators we use internally. > > >> 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-decl… > > Linking multiple .c and .pyx files together into a single .so/.dll is > much more complicated than just using 'cimport'. Try it if you don't > believe me :-). > > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org > > > ------------------------------ > > Message: 6 > Date: Thu, 6 Mar 2014 13:59:30 +0000 > From: Nathaniel Smith <njs(a)pobox.com> > Subject: Re: [Numpy-discussion] numpy gsoc ideas (was: numpy gsoc > topic idea: configurable algorithm precision and vector math > library > integration) > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: > <CAPJVwB=PmquKm5j4-oquCkLkcK8G1pipB8XLbq5= > 26izjbJPjg(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Mar 6, 2014 at 9:11 AM, David Cournapeau <cournape(a)gmail.com> > wrote: > > > > On Wed, Mar 5, 2014 at 9:11 PM, Nathaniel Smith <njs(a)pobox.com> wrote: > >> 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. > > > > > > Having to synchronise two projects may be hard for a GSoC, no ? > > Yeah, if someone is interested in this it would be nice to get someone > from Cython involved too. But that's why the primary goal is to > produce a proof-of-concept -- even if all that comes out is that we > learn that this cannot be done in an acceptable manner, then that's > still a succesful (albeit disappointing) result. > > > Otherwise, I am a bit worried about cython being used on the current C > code > > as is, because core and python C API are so interwined (especially > > multiarray). > > I don't understand this objection. The whole advantage of Cython is > that it makes it much, much easier to write code that involves > intertwining complex algorithms and heavy use of the Python C API :-). > There's tons of bug-prone spaghetti in numpy for doing boring things > like refcounting, exception passing, and argument parsing. > > -n > > -- > Nathaniel J. Smith > Postdoctoral researcher - Informatics - University of Edinburgh > http://vorpus.org > > > ------------------------------ > > Message: 7 > Date: Thu, 6 Mar 2014 10:35:15 -0700 > From: Charles R Harris <charlesr.harris(a)gmail.com> > Subject: Re: [Numpy-discussion] 1.8.1rc1 on sourceforge. > To: Discussion of Numerical Python <numpy-discussion(a)scipy.org> > Message-ID: > < > CAB6mnx+btuF3vKxvebfBZKybggp+C6mtnb7zD1ck1bqk9VXV2w(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Wed, Mar 5, 2014 at 7:28 PM, Matthew Brett <matthew.brett(a)gmail.com > >wrote: > > > Hi, > > > > On Wed, Mar 5, 2014 at 3:29 PM, Matthew Brett <matthew.brett(a)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, > > > > > Julian has done most of the work for 1.8.1. I did the 1.8.0 release because > it needed doing, but building releases isn't my strong point and Ralf > actually did the builds for that. So I'll happily send you my ssh, but > either Ralph or Julian might be a better bet for getting the work done :) > > Chuck >

1 0

1.8.1 release
by Charles R Harris 06 Mar '14

06 Mar '14

Hi All, A lot of fixes have gone into the 1.8.x branch and it looks about time to do a bugfix release. There are a couple of important bugfixes still to backport, but if all goes well next weekend, March 1, looks like a good target date. So give the current 1.8.x branch a try so as to check that it covers your most urgent bugfix needs. Chuck

9 18

numpy gsoc topic idea: configurable algorithm precision and vector math library integration
by Julian Taylor 06 Mar '14

06 Mar '14

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 some functions in numpy could be implemented in different ways depending on requirements on speed and numerical precision. Two examples that come to my mind are hypot and sum hypot (or abs(complex)) use the C99 hypot function which guarantees 1ulp precision but is very slow compared to a simple sqrt(a**2 +b**2). This precision might not be required for all applications, overflow safety might be enough. summation in numpy 1.9 is performed via pairwise summation which has O(log(n)*e) error properties, but only for the fast axis. An alternative O(e) approach would be kahan summation which works for all axis but is 4 time slower than normal summation (a bit can be regained via vectorization thought) My idea is have an option to change the algorithms used in numpy depending on the set requirements. E.g. 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) I have not though much about implementation, it might be tricky to get this threadsafe in the current ufunc model. 2. vector math library integration some operations like powers, sin, cos etc are relatively slow in numpy depending on the c library used. There are now a few free libraries available that make use of modern hardware to speed these operations up, e.g. sleef and yeppp (also mkl but I have no interest in supporting non-free software) It might be interesting to investigate if these libraries can be integrated with numpy. This also somewhat ties in with the configurable precision mode as the vector math libraries often have different options depending on precision and speed requirements. Do those sound like topics we could add to our wiki?

4 3

GSoC: ideas & finding mentors
by Ralf Gommers 05 Mar '14

05 Mar '14

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

1 0

Re: [Numpy-discussion] GSoC 2014 NumPy
by Leo Mao 05 Mar '14

05 Mar '14

Hello Ray, Thanks for your suggestion! I just read the links you provided and I think I can implement it as long as I do further research on zoom fft algorithm. So I wonder if this can be a GSoC project? Maybe I should extend this idea or combine it with other ideas? BTW, just for curiosity, why we need both scipy.linalg and numpy.linalg? Is implementing all functions in numpy a bad idea? Regards, Leo Mao

2 3

EuroSciPy 2014 Call for Abstracts
by Ralf Gommers 05 Mar '14

05 Mar '14

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

2 3

Implementing Levenberg-Marquardt with additional feature
by Sudheer Singh 05 Mar '14

05 Mar '14

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.

2 1

ndarray is not a sequence
by Anthony Scopatz 04 Mar '14

04 Mar '14

Hello All, The semantics of this seem quite insane to me: In [1]: import numpy as np In [2]: import collections In [4]: isinstance(np.arange(5), collections.Sequence) Out[4]: False In [6]: np.version.full_version Out[6]: '1.9.0.dev-eb40f65' Is there any possibility that ndarray could inherit (in the last place) from collections.Sequence? It seems like this would only be a 1 - 5 line fix somewhere. I just spent a few hours tracking down a bug related to this. Thanks for considering! Be Well Anthony

7 10

How security holes happen
by Charles R Harris 03 Mar '14

03 Mar '14

This is from OS X 9 if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; Heh, maybe there is a reason for braces in even the simplest if statements. Chuck

7 8

dtype promotion
by Nicolas Rougier 03 Mar '14

03 Mar '14

Hi all, I'm using numpy 1.8.0 (osx 10.9, python 2.7.6) and I can't understand dtype promotion in the following case: >>> Z = np.zeros((2,2),dtype=np.float32) + 1 >>> print Z.dtype float32 >>> Z = np.zeros((2,2),dtype=np.float32) + (1,1) >>> print Z.dtype float64 Is this the expected behavior ? What it the difference between the two lines ? Nicolas

4 7

GSOC 2014 : "Improve Numpy datetime functionality"
by faisal anees 03 Mar '14

03 Mar '14

Hi , I am Mohammed Faisal Anees , a Computer Science student at IIIT- Hyderabad. I was going though the ideas page and I found "Improve Numpy datetime functionality" really interesting , and it suits my experience as I have a considerable(hopefully !!) amount of experience in C/C++, and Python . Right now I am going through the link suggested by you and the codebase. Thanks

3 2

Installing
by Sze Chai kwok 03 Mar '14

03 Mar '14

> I have this message when installing numpy, any ideas? Thanks > -- > Sze Chai Kwok, D.Phil > Neuroimaging Laboratory > Santa Lucia Foundation > Via Ardeatina 306 > 00179 Rome Italy > Tel: +39 06 5150 1459 -- Sze Chai Kwok, D.Phil Neuroimaging Laboratory Santa Lucia Foundation Via Ardeatina 306 00179 Rome Italy Tel: +39 06 5150 1459

2 1

proper way to test Numpy version in C/C++
by Ghislain Vaillant 03 Mar '14

03 Mar '14

Hi everyone, I have got code for some python wrappers of a scientific library which needs to support both Numpy 1.6 and later versions. The build of the wrapper (using swig) stopped working because of the deprecated API introduced in v1.7. The error only concerns the renaming of some macros from NPY_XXX to NPY_ARRAY_XXX. I was thinking to just check for the Numpy version at build time and add corresponding #define to provide the necessary renaming in case the build is done with Numpy v1.6. How can I robustly test for Numpy's version API in C ? Ghis

1 1

Suggestions for GSoC Projects
by jennifer stone 02 Mar '14

02 Mar '14

With GSoC 2014 being round the corner, I hereby put up few projects for discussion that I would love to pursue as a student. Guidance, suggestions are cordially welcome:- 1. If I am not mistaken, contour integration is not supported by SciPy; in fact even line integrals of real functions is yet to be implemented in SciPy, which is surprising. Though we at present have SymPy for line Integrals, I doubt if there is any open-source python package supporting the calculation of Contour Integrals. With integrate module of SciPy already having been properly developed for definite integration, implementation of line as well as contour integrals, I presume; would not require work from scratch and shall be a challenging but fruitful project. 2. I really have no idea if the purpose of NumPy or SciPy would encompass this but we are yet to have indefinite integration. An implementation of that, though highly challenging, may open doors for innumerable other functions like the ones to calculate the Laplace transform, Hankel transform and many more. 3. As stated earlier, we have spherical harmonic functions (with much scope for dev) we are yet to have elliptical and cylindrical harmonic function, which may be developed. 4. Lastly, we are yet to have Inverse Laplace transforms which as Ralf has rightly pointed out it may be too challenging to implement. 5. Further reading the road-map given by Mr.Ralf, I would like to develop the Bluestein's FFT algorithm. Thanks for reading along till the end. I shall append to this mail as when I am struck with ideas. Please do give your valuable guidance

7 19

Re: [Numpy-discussion] GSoC 2014 NumPy
by RayS 01 Mar '14

01 Mar '14

At 04:42 AM 3/1/2014, you wrote: >Currently I am trying to come up with some ideas about enhancing NumPy. Hello Leo, How about you implement fft.zoom_fft() as a single function? (Not to be confused with chirp-Z) We might be able to lend some ideas, but I've never been satisfied with mine: http://mail.scipy.org/pipermail/numpy-discussion/2007-March/026529.html and Matlab https://www.mathworks.com/matlabcentral/newsreader/view_thread/85241 http://www.numerix-dsp.com/zoomfft.html http://www.ee.ic.ac.uk/hp/staff/dmb/voicebox/doc/voicebox/zoomfft.html - Ray S

1 0

GSoC 2014 NumPy
by Leo Mao 01 Mar '14

01 Mar '14

Hello, I'm a student studying electrical engineering. I am interested in contributing to NumPy and applying GSoC 2014. I have experience of python and C/C++ programming, and I have already seen https://github.com/scipy/scipy/wiki/GSoC-project-ideas. But on that page only the project "Improve Numpy datetime functionality" targets NumPy. Currently I am trying to come up with some ideas about enhancing NumPy. I will be grateful if someone could give me some ideas or guide me as how to do next. BTW, I am looking into the issue list of NumPy on github and trying to make some small bugfixes/enhancement for NumPy. Thanks in advance. Regards: Leo Mao, student in National Taiwan University, Email: lmao20001(a)gmail.com

1 0

2D array indexing
by Gökhan Sever 28 Feb '14

28 Feb '14

Hello, Given this simple 2D array: In [1]: np.arange(9).reshape((3,3)) Out[1]: array([[0, 1, 2], [3, 4, 5], [6, 7, 8]]) In [2]: a = np.arange(9).reshape((3,3)) In [3]: a[:1:] Out[3]: array([[0, 1, 2]]) In [4]: a[:1,:] Out[4]: array([[0, 1, 2]]) Could you tell me why the last two indexing (note the comma!) results in the same array? Thanks. -- Gökhan

2 2