[Numpy-discussion] A sad day for our community. John Hunter: 1968-2012.
Dear friends and colleagues, [please excuse a possible double-post of this message, in-flight internet glitches] I am terribly saddened to report that yesterday, August 28 2012 at 10am, John D. Hunter died from complications arising from cancer treatment at the University of Chicago hospital, after a brief but intense battle with this terrible illness. John is survived by his wife Miriam, his three daughters Rahel, Ava and Clara, his sisters Layne and Mary, and his mother Sarah. Note: If you decide not to read any further (I know this is a long message), please go to this page for some important information about how you can thank John for everything he gave in a decade of generous contributions to the Python and scientific communities: http://numfocus.org/johnhunter. Just a few weeks ago, John delivered his keynote address at the SciPy 2012 conference in Austin centered around the evolution of matplotlib: http://www.youtube.com/watch?v=e3lTby5RI54 but tragically, shortly after his return home he was diagnosed with advanced colon cancer. This diagnosis was a terrible discovery to us all, but John took it with his usual combination of calm and resolve, and initiated treatment procedures. Unfortunately, the first round of chemotherapy treatments led to severe complications that sent him to the intensive care unit, and despite the best efforts of the University of Chicago medical center staff, he never fully recovered from these. Yesterday morning, he died peacefully at the hospital with his loved ones at his bedside. John fought with grace and courage, enduring every necessary procedure with a smile on his face and a kind word for all of his caretakers and becoming a loved patient of the many teams that ended up involved with his case. This was no surprise for those of us who knew him, but he clearly left a deep and lasting mark even amongst staff hardened by the rigors of oncology floors and intensive care units. I don't need to explain to this community the impact of John's work, but allow me to briefly recap, in case this is read by some who don't know the whole story. In 2002, John was a postdoc at the University of Chicago hospital working on the analysis of epilepsy seizure data in children. Frustrated with the state of the existing proprietary solutions for this class of problems, he started using Python for his work, back when the scientific Python ecosystem was much, much smaller than it is today and this could have been seen as a crazy risk. Furthermore, he found that there were many half-baked solutions for data visualization in Python at the time, but none that truly met his needs. Undeterred, he went on to create matplotlib (http://matplotlib.org) and thus overcome one of the key obstacles for Python to become the best solution for open source scientific and technical computing. Matplotlib is both an amazing technical achievement and a shining example of open source community building, as John not only created its backbone but also fostered the development of a very strong development team, ensuring that the talent of many others could also contribute to this project. The value and importance of this are now painfully clear: despite having lost John, matplotlib continues to thrive thanks to the leadership of Michael Droetboom, the support of Perry Greenfield at the Hubble Telescope Science Institute, and the daily work of the rest of the team. I want to thank Perry and Michael for putting their resources and talent once more behind matplotlib, securing the future of the project. It is difficult to overstate the value and importance of matplotlib, and therefore of John's contributions (which do not end in matplotlib, by the way; but a biography will have to wait for another day...). Python has become a major force in the technical and scientific computing world, leading the open source offers and challenging expensive proprietary platforms with large teams and millions of dollars of resources behind them. But this would be impossible without a solid data visualization tool that would allow both ad-hoc data exploration and the production of complex, fine-tuned figures for papers, reports or websites. John had the vision to make matplotlib easy to use, but powerful and flexible enough to work in graphical user interfaces and as a server-side library, enabling a myriad use cases beyond his personal needs. This means that now, matplotlib powers everything from plots in dissertations and journal articles to custom data analysis projects and websites. And despite having left his academic career a few years ago for a job in industry, he remained engaged enough that as of today, he is still the top committer to matplotlib; this is the git shortlog of those with more than 1000 commits to the project: 2145 John Hunter 2130 Michael Droettboom 1060 Eric Firing All of this was done by a man who had three children to raise and who still always found the time to help those o
Re: [Numpy-discussion] view of recarray issue
Jay, On Mon, Aug 20, 2012 at 12:40 PM, Ondřej Čertík wrote: > On Wed, Jul 25, 2012 at 10:29 AM, Jay Bourque > wrote: >> I'm actively looking at this issue since it was my pull request that broke >> this (https://github.com/numpy/numpy/pull/350). We definitely don't want to >> break this functionality for 1.7. The problem is that even though indexing >> with a subset of fields still returns a copy (for now), it now returns a >> copy of a view of the original array. When you call copy() on a view, it >> copies the entire original structured array with the view dtype. A short >> term fix would be to "manually" create a proper copy to return similar to >> what _index_fields() did before my change, but since the idea is to >> eventually return the view instead of a copy, long term we need a way to do >> a proper copy of a structured array view that doesn't copy the unwanted >> fields. > > This should be fixed for 1.7.0. However, I am going to release beta now, > and then see what we can do about this. What would be the best "short term" fix, so that we can release 1.7.0? I am still trying to understand what exactly the problem with dtype is in _index_fields(). Would you suggest to keep using the view, or somehow revert to the old behavior while still trying to pass all the new tests in your PR 350? If you have any hints, it would save me some time. Thanks, Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] distutils: compiler used by add_library
Hi Matyáš, On Wed, Aug 29, 2012 at 3:20 AM, Matyáš Novák wrote: > Hi, > I wrote extension some numerical extension for python, that requires > compiling > and linking additional fortran sources. I find out, that these libraries > can be easily added > using config.add_library() function, but there is a problem. > The --fcompiler command doesn't propagate to the stage where the > libraries are compiled, > so the default (and in my case wrong) compiler is used. (If I try > compile the files using > add_extension method, they are compiled by desired compiler, but I need > combine more > sources in one extension so I think that I can't use add_extension). > Is there any way how to force python to use the right compiler, or at > least hardcode the > compiler in the setup.py? Maybe somebody can help with your particular question, but I was also struggling with similar issues when mixing Fortran, C and Python and settled on using cmake for compiling and linking Fortran, C and Python extension .so modules, as well as installing the Python .py files. Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] blaze lib announcement
> This looks interesting: > > http://code.google.com/p/blaze-lib/ So maybe you also want to have a look at http://flens.sf.net Just to promote my own baby in this context too ;-) Cheers, Michael___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] config.add_library()
Hi folks, I'm working on a package that will contain a bunch of cython extensions, all of which need to link against a pile of C++ code. What I think I need to do is build that C++ as a dynamic library, so I can link everything against it. It would be nice if I could leverage distutils to build that library for me. Particularly since Windows and OS-X and Linux all seem to need things a little (or q lot) different. It looks like numpy.distuitls' config.add_library might be what I need, but the docs are pretty sprarse: This page: http://docs.scipy.org/doc/numpy-1.5.x/reference/generated/numpy.distutils.misc_util.Configuration.add_library.html confused me a bit: """ Parameters : name : str Name of the extension. """ Is this really building an extension, or is that some docs string brought over from the distutils Extension class? So -- is config.add_lirary() what I'm looking for? If so are there better docs and/or examples you canpoint me to? Thanks, -Chris Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] blaze lib announcement
The Eigen3 project (http://eigen.tuxfamily.org/index.php?title=Main_Page) is more mature, but it's good to see a new contender in the field. A On Wed, Aug 29, 2012 at 1:59 PM, Neal Becker wrote: > This looks interesting: > > http://code.google.com/p/blaze-lib/ > > ___ > 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] blaze lib announcement
This looks interesting: http://code.google.com/p/blaze-lib/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] distutils: compiler used by add_library
Hi, I wrote extension some numerical extension for python, that requires compiling and linking additional fortran sources. I find out, that these libraries can be easily added using config.add_library() function, but there is a problem. The --fcompiler command doesn't propagate to the stage where the libraries are compiled, so the default (and in my case wrong) compiler is used. (If I try compile the files using add_extension method, they are compiled by desired compiler, but I need combine more sources in one extension so I think that I can't use add_extension). Is there any way how to force python to use the right compiler, or at least hardcode the compiler in the setup.py? Thanks a lot for suggestions, Matyas ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
