Re: [matplotlib-devel] Tutorial topics for SciPy'09 Conference
Hi, On Mon, Jun 1, 2009 at 10:20 PM, Fernando Perez wrote: > The time for the Scipy'09 conference is rapidly approaching, and we > would like to both announce the plan for tutorials and solicit > feedback from everyone on topics of interest. rather than rehash much here, where it's not easy to paste a table, I've posted a note with the poll results here: http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html The short and plain-text-friendly version is the final topic ranking: 1 Advanced topics in matplotlib use 2 Advanced numpy 3 Designing scientific interfaces with Traits 4 Mayavi/TVTK 5 Cython 6 Symbolic computing with sympy 7 Statistics with Scipy 8 Using GPUs with PyCUDA 9 Testing strategies for scientific codes 10 Parallel computing in Python and mpi4py 11 Sparse Linear Algebra with Scipy 12 Structured and record arrays in numpy 13 Design patterns for efficient iterator-based scientific codes 14 Sage 15 The TimeSeries scikit 16 Hermes: high order Finite Element Methods 17 Graph theory with NetworkX We're currently contacting speakers, and we'll let you know once a final list is made with confirmed speakers. Cheers, f -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] scipy conference
After a two year hiatus where I inadvertently scheduled my travel plans to overlap scipy, I will finally be able to make it to the scipy conference this year, and plan to make up for lost time by coming early to lead a tutorial on advanced mpl usage, stay through the conference, and if any of you are interested, do a sprint. There are lots of interesting things we can work on: refactoring the ticks to work nicely with the new spines, pushing forward on the documentation, optimizing stuff that is too slow or memory intensive, improving the animation API and backend support, gradients, Anyone interested? And if so, feel free to suggest topics or weigh in on some I listed. Also, if any of you will be there early for the tutorials, it would be great to have some help from floaters, people who walk around the room and help people who get stuck during the hands-on examples or teachers, people who lead part of the tutorial. In particular, Michael could do a segment on transforms and paths, JJ could do a segment on all his fancy arrows, boxes, annotations, etc, Andrew on his spines, Reinier on mplot3d, etc... I will probably cover all of these even if you can't attend or don't want to teach, but it is best ot hear from the experts. And if anyone not mentioned wants to contribute a segment, that would be great -- just let me know what it is. The tutorial is 2 hours and focuses on advanced mpl usage so I want to avoid the everyday stuff and focus on transforms, paths, event handling, animation, the newer features (spines, fancy*, mplot3d) and everything else I am currently forgetting. Also, we have raised a few hundred dollars in donations, so we could either fly a worthy person out who might not otherwise be able to attend, or pay for sprint registration for someone not getting institutional support. Or at least provide coffee, doughnuts, pizza and beer as fuel for participants. Fernando has also informed me there may be some travel and conference money from other sources for student developers so please email me us list if you are interested. JDH -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] scipy conference
John Hunter wrote: > Also, we have raised a few hundred dollars in donations, so we could > either fly a worthy person out who might not otherwise be able to > attend, or pay for sprint registration for someone not getting > institutional support. Or at least provide coffee, doughnuts, pizza > and beer as fuel for participants. Fernando has also informed me > there may be some travel and conference money from other sources for > student developers so please email me us list if you are interested. > One small correction: sprints are free to attend. The only registration costs are for the tutorials and conference itself. -- Dave -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] crazy ideas for MPL (was: scipy conference)
On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote: > Anyone interested? And if so, feel free to suggest topics or weigh in > on some I listed. Actually, I have something I would like to discuss, but never really could pull myself together to do it. I don't have time right now, but I am still going to jot down the ideas. The axes and figure paradigm inherited from matlab works well for simple things, but when I want to more complex layouts, I actually end up struggling with calls to axes with numerical parameters to adjust. In addition, if I have a function that creates a plot with multiple axes, like the figure on: http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html I may want to reuse that function to create more complex figures, stacking several of these views, with possibly other plots. It seems to me having a level of granularity between the figure, and the axes would help me a lot achieving these goals. I haven't had time to hash out an API, or even solid concepts. For people who know LaTeX well, let me draw an analogy: the figure is the page, the axis is the character, what we are lacking in a 'minipage'. I would like a container that can be stacked into a figure, and that can either hold axes, or similar containers. That way, I could specify subplot, or axis relative to this container, rather than relative to the whole figure, and it makes it really easy for me to insert figures in larger figures. One possible API would be 'subfigure', which would have a signature similar to 'axes', but of course things would need to be thought a bit more in detail: do we want clf to erase the figure and not the subfigure? I believe so. Do we want subplot to divide the subfigure, rather than the figure? I believe so too. How do we go back to full figure without erasing the subfigures it contains? I think subfigure(None) might work. How do I select a subfigure I already created? Maybe by passing it a subfigure instance, like the way axes work. Also, Chaco has the notion of containers, in which you can stack plots or other containers. They have an additional feature which is that they enable you to stack plot (these would be axes, in matplotlib terms) and do an automatic layout of the plots. Very handy to have an extensible canvas to display information on. Some sparse documentation: http://code.enthought.com/projects/chaco/docs/html/api/containers.html I have been trying to find time to think about this for more than a year, and haven't. This is why I am sending unfinished thoughts. I do believe more thinking has to be done, and the subfigure proposition may not hold at all. Also, I fear I do not have time to implement this. My 2 cents, Gaël -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] crazy ideas for MPL
Gael Varoquaux wrote: > On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote: > >> Anyone interested? And if so, feel free to suggest topics or weigh in >> on some I listed. >> > > Actually, I have something I would like to discuss, but never really > could pull myself together to do it. I don't have time right now, but I > am still going to jot down the ideas. > > The axes and figure paradigm inherited from matlab works well for simple > things, but when I want to more complex layouts, I actually end up > struggling with calls to axes with numerical parameters to adjust. In > addition, if I have a function that creates a plot with multiple axes, > like the figure on: > http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html > I may want to reuse that function to create more complex figures, > stacking several of these views, with possibly other plots. > > It seems to me having a level of granularity between the figure, and the > axes would help me a lot achieving these goals. I haven't had time to > hash out an API, or even solid concepts. For people who know LaTeX well, > let me draw an analogy: the figure is the page, the axis is the > character, what we are lacking in a 'minipage'. I would like a container > that can be stacked into a figure, and that can either hold axes, or > similar containers. That way, I could specify subplot, or axis relative > to this container, rather than relative to the whole figure, and it makes > it really easy for me to insert figures in larger figures. > > One possible API would be 'subfigure', which would have a signature > similar to 'axes', but of course things would need to be thought a bit > more in detail: do we want clf to erase the figure and not the subfigure? > I believe so. Do we want subplot to divide the subfigure, rather than the > figure? I believe so too. How do we go back to full figure without > erasing the subfigures it contains? I think subfigure(None) might work. > How do I select a subfigure I already created? Maybe by passing it a > subfigure instance, like the way axes work. > > Also, Chaco has the notion of containers, in which you can stack plots or > other containers. They have an additional feature which is that they > enable you to stack plot (these would be axes, in matplotlib terms) and > do an automatic layout of the plots. Very handy to have an extensible > canvas to display information on. Some sparse documentation: > http://code.enthought.com/projects/chaco/docs/html/api/containers.html > > I have been trying to find time to think about this for more than a year, > and haven't. This is why I am sending unfinished thoughts. I do believe > more thinking has to be done, and the subfigure proposition may not hold > at all. Also, I fear I do not have time to implement this. > I also have some not very fleshed out thoughts: my main feeling about MPL is that there's just too much layout happening to keep using the non-systematic delegation/notification "system" currently in place while allowing the devs to maintain their sanity and day jobs. I don't mean to disparage MPL -- it is quite a fantastic piece of code -- but there is a lack of abstraction of layout hierarchies and layout dependencies that makes development difficult. Therefore, I'd suggest that before adding on too many more nice features, we revisit the core layout and delegation system -- in the end it will make everything much easier. So, perhaps a useful thing would be for as many MPL devs as possible to sit together and discuss how we could do this. My thought right now would be to investigate the use of traits to codify the layout abstractions. Any effort like this will also obviously benefit from having an extensive test suite. I think all that's needed to get the tests at http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone checks in new images made with the current MPL. I'd like to do this, but I'm really short on time at the moment. So, please, someone -- beat me to it -- it won't be hard! Those are my 2 cents. Hope to see you all at SciPy 2009! -Andrew -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
