Re: [matplotlib-devel] Test
David Moore wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Ryan May wrote: >> Test. Please disregard. >> >> Ryan >> >> -- >> Ryan May >> Graduate Research Assistant >> School of Meteorology >> University of Oklahoma >> > Hi Ryan, > > Gmail never shows you your own emails. Your emails are getting to the list. > Ok, thanks for the info. What's weird is that I also made sure to check the mailing list archive, which showed some of my other replies, but not the most recent post. Must be a heck of a delay Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Skew-T
Ryan May wrote: > (Sorry if this is a duplicate) > > Hi, > > I'm trying to make a Skew-T LogP plot, an important plot in meteorology, > using matplotlib (mainly to help convert people away from much more > horrible solutions). You can see one here: > http://www.rap.ucar.edu/weather/upper/oun.gif > > and more cartoonish: > http://www.srh.noaa.gov/oun/images/figure6.gif > > > (Pay attention only to the lower part with the bold red and green > lines). I'm pretty sure matplotlib can't currently do this, but it > shouldn't be too hard. The crux of the plot is that you plot > temperature as a function of pressure, with pressure reversed and > logarithmically spaced on the Y-axis (ie. high pressure at the bottom) > and temperature plotted skewed along the X axis. That is, the lines of > constant temperature intersect the bottom at 45 degree angles. I know > matplotlib can do log axes, so how hard would it be for me to create a > transform that can handle the 45 degree skew of the temperature? > > Thanks, > > Ryan > > Ryan: I'm sure you could do it, and it would be a nice contribution to the community. There's some IDL code here http://cimss.ssec.wisc.edu/camex3/archive/quicklooks/ you could work from. There's also NCL code (couldn't find it on the web, but the source code comes with NCL). I'd suggest working from those. I don't think you need transforms (although they might make it easier), since neither of those languages has them. HTH, -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/PSD1FAX : (303)497-6449 325 BroadwayBoulder, CO, USA 80305-3328 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Consist Symbols/Sizes between Plot/Scatter
John Hunter wrote: > On Thu, Jun 12, 2008 at 8:56 PM, T J <[EMAIL PROTECTED]> wrote: >> I am making a scatter plot and want the legend to display the symbols. >> This functionality doesn't seem to exist, so I have followed the >> workaround outlined here: >> >> http://www.nabble.com/Legend-for-a-scatter-plot-based-on-symbols-td17554839.html#a17554839 >> >> Are there any plans to make the symbols which are available in plot() >> the same as those available for scatter()? If not, can we at least >> get the diamond symbol the same? I want to pass the same symbol to >> plot() and scatter() and get the same symbol---as it is, I must use >> 'd' in scatter and 'D' in plot. > > I think this is worth fixing -- could you file a bug on the > sourceforge site and note any symbols you are aware of that don't > agree between plot and scatter. Hi John, this is something that came up some time ago already. http://www.nabble.com/forum/ViewPost.jtp?post=16054211&framed=y Paul Novak had planed to work on scatter legend and I am also interested in this, so we came up with a code fragment, but it doesn't do the job well. I think a legend for scatter is something that is really needed for matplotlib. The main problem is, that I got lost in all those transform things - finally I felt like crazy ;-) >> Also, how are the markersizes scaled? For example, in scatter(), I am >> using s=30...but if I do plot(...,markersize=30), then the markers are >> not the same size as the markers from the scatter plot. I can go back >> and forth until the scale is right, but is there a better way? > > Note sure if this is a bug or a feature, but it is a consequence of > emulating the matlab approach. In scatter, the size often is used to > convey information, and the size parameter give thes area of the > circle that circumscribes the marker. In plot, he marker size is not > generally intended to convey information, only that something happened > here, and the size choice is usually one of aesthetics. In any case, > in plot the size is radius of the circle, the side of the square or > diamond. For most markers, you should be able to square the > markersize to get approximate correspondence between plot and scatter. I think that's something that is also a bit "unfortunate" in matplotlib. Basically, there are two different routines to draw markers: one is plot(), and on is scatter(). Both do nearly the same thing, but use different code bases. It might be worth to think about reorganizing this ??? Having one function that creates markers, and incorporating them from both, scatter() and plot(), sounds like a good idea to me !? Manuel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'FigureCanvasWxAgg' object has no attribute 'SetInitialSize'
I can't explain why this changed in numpy or why PyArray_FromDims works
and PyArray_SimplyNewFromData doesn't, but...
In _backend_agg.cpp, I just used a npy_intp array for dimensions
everywhere. I think the difference may only matter on 64 platforms
where sizeof(int) != sizeof(void*), such as x86_64. npy_intp is a
typedef for Py_intptr_t which is defined thusly (in pyport.h):
*/* uintptr_t is the C9X name for an unsigned integral type such that a
* legitimate void* can be cast to uintptr_t and then back to void* again
* without loss of information. Similarly for intptr_t, wrt a signed
* integral type.
*/
*
Cheers,
Mike
John Hunter wrote:
>> On Thu, Jun 12, 2008 at 2:54 PM, Nils Wagner
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>> src/ft2font.cpp: In member function 'Py::Object FT2Image::py_as_array(const
>>> Py::Tuple&)':
>>> src/ft2font.cpp:273: error: cannot convert 'int*' to 'npy_intp*' in argument
>>> passing
>>> error: command 'gcc' failed with exit status 1
>>>
>
> Hmm, I had tried to use PyArray_SimpleNewFromData with an 'int
> dimensions[2]' array, which worked on numpy 1.1 but apparently breaks
> in the latest numpy svn. Since I am unsure what is the most portable
> thing to do here, I reverted to a pattern that we've used elsewhere
> that appears robust across numpy versions (included below). If any
> numpy god wants to tell me the right way to create and array from an
> existing buffer, let me know.
>
> Fixed in svn 5495
>
>
> int dimensions[2];
> dimensions[0] = get_height(); //numrows
> dimensions[1] = get_width(); //numcols
>
> //this is breaking with numpy svn, which wants a npy_intp*
> //PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNewFromData(2,
> dimensions, PyArray_UBYTE, _buffer);
>
>
> PS: please keep all replies on list.
> PyArrayObject *A = (PyArrayObject *) PyArray_FromDims(2, dimensions,
> PyArray_UBYTE);
>
>
> unsigned char *src= _buffer;
> unsigned char *src_end= src + (dimensions[0] * dimensions[1]);
> unsigned char *dst= (unsigned char *)A->data;
>
> while (src != src_end) {
>*dst++ = *src++;
> }
>
>
> PS: please keep all replies on list
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch proposal: labels location in pie chart
Thanks. This has been committed to the SVN trunk r5502. Cheers, Mike Michael Droettboom wrote: > Looks like a nice solution to me. I don't use pie charts much myself, > so I'll give it some time to see if there are any dissenters. If none, > I'll go ahead and commit this to SVN. > > Thanks! > Mike > > Benoit Hirbec wrote: > >> Hello, >> >> Pie charts are very useful, but when wedges labels are too long, the >> label text overlaps the pie wedge, resulting in a poor readability >> (see the attached file 'before_patch.pdf'). >> >> I propose to modify the file 'axes.py' in method 'pie' by replacing: >> >> xt = x + labeldistance*radius*math.cos(thetam) >> yt = y + labeldistance*radius*math.sin(thetam) >> >> t = self.text(xt, yt, label, >>size=rcParams['xtick.labelsize'], >>horizontalalignment='center', >>verticalalignment='center') >> >> texts.append(t) >> >> By: >> >> xt = x + labeldistance*radius*math.cos(thetam) >> yt = y + labeldistance*radius*math.sin(thetam) >> label_alignment = xt > 0 and 'left' or 'right' >> >> t = self.text(xt, yt, label, >>size=rcParams['xtick.labelsize'], >>horizontalalignment=label_alignment, >>verticalalignment='center') >> >> texts.append(t) >> >> Only 2 lines changed ;-) >> >> This way, labels are right aligned when placed at the left of the pie, >> and left aligned when placed on the right of the pie (instead of being >> always centered). See the attached file 'after_patch.pdf' for an >> example. >> I also give an example in the example.py file. >> >> Do you agree to commit that to the trunk? >> >> Thanks for making matplotlib, >> >> Benoit Hirbec >> Garden >> >> >> >> >> >> >> >> >> >> - >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Requiring docutils 0.5
How much pain would it cause if we required docutils 0.5 to build the docs? In working on this "use pngs if in html, pdfs if in latex" functionality, the solutions has actually been fairly involved. It's probably doable in docutils-0.4, but I'd prefer not to have write and maintain two fairly different code paths as the directive API has changed from 0.4 to 0.5. If we go this way, we can add a nice test to make.py to require docutils 0.5 so it's less surprising when things don't work... Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Requiring docutils 0.5
Ignore this. It's not as bad as I thought. Mike Michael Droettboom wrote: > How much pain would it cause if we required docutils 0.5 to build the docs? > > In working on this "use pngs if in html, pdfs if in latex" > functionality, the solutions has actually been fairly involved. It's > probably doable in docutils-0.4, but I'd prefer not to have write and > maintain two fairly different code paths as the directive API has > changed from 0.4 to 0.5. > > If we go this way, we can add a nice test to make.py to require docutils > 0.5 so it's less surprising when things don't work... > > Cheers, > Mike > > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Consist Symbols/Sizes between Plot/Scatter
On Fri, Jun 13, 2008 at 7:40 AM, Manuel Metz <[EMAIL PROTECTED]> wrote: > Paul Novak had planed to work on scatter legend and I am also interested in > this, so we came up with a code fragment, but it doesn't do the job well. I > think a legend for scatter is something that is really needed for > matplotlib. The main problem is, that I got lost in all those transform > things - finally I felt like crazy ;-) > I think that's something that is also a bit "unfortunate" in matplotlib. > Basically, there are two different routines to draw markers: one is plot(), > and on is scatter(). Both do nearly the same thing, but use different code > bases. > It might be worth to think about reorganizing this ??? Having one function > that creates markers, and incorporating them from both, scatter() and > plot(), sounds like a good idea to me !? This is how I see it -- plot draws homogeneous markers. Knowing they are homogeneous allows us to do optimizations in the backend, like cacheing the rasterized marker and blitting it many places. This can radically speed up plots where there are many markers. scatter, on the hand, exists to draw heterogeneous markers, which vary either in size or in color or both. This is why I have always been lukewarm in adding auto-legend support -- which of the heterogeneous scatter symbols gets the legend entry? I n cases where you only vary the color or only vary the size, one could use the first polygon as a proxy for auto-legending. This wouldn't work all the time, but it might be good enough for folks who want auto-legends and others would still have the option of doing the legend polygon proxy trick. One way to make this easier would be for the polygon collections to provide a polygon_proxy method which returns a unit area patches.Polygon instance with properties set to correspond to the first polygon in the collection -- then the legend implementer could use it w/o worrying about all the different types of polygon collections and the odd sizing that may occur by simply taking the first element. But yes, to the extent that we can centralize the marker symbol -> path creation and reuse that between the line2d and poly collection code, that would be a good thing. One could then scale and translate the canonical polygons as needed for their respective uses. On the size as area usage in scatter -- I have found this counter-intuitive from day 1, and I wrote the damned thing, but as I noted we inherited this from matlab and a lot of code is built around it, so we are probably stuck with it. If you think it is sufficiently irksome, you can add a kwarg to scatter along the lines of def scatter(..., sizearea=True) where if sizearea is False we treat the size as a linear dimension. This could also be an rc param so people could set the defaults to behave in a more intuitive way w/o breaking the old code. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'module' object has no attribute 'GraphicsContext'
"John Hunter" <[EMAIL PROTECTED]> writes: > On Thu, Jun 12, 2008 at 3:38 PM, Ken McIvor <[EMAIL PROTECTED]> wrote: > > On Jun 12, 2008, at 3:22 PM, John Hunter wrote: > >> > >> If some wx guru sees an easy fix here, by all means add it. > > > > Not to imply that I'm a guru, but I'll try to look into it this evening. > > Well, you are a guru to us :-) > > >> Otherwise, we should decide on a minimum wxpython version for the > >> trunk and raise an exception. > > > > I'm always in favor of ensuring that MPL can run on Debian Stable without > > too much pain and suffering. Doing so would entail supporting wxPython 2.6. > > It looks like debian stable is now packaging numpy 1.01. Am I reading > this right? > > http://packages.debian.org/search?keywords=python-numpy Yes, that's right. 1.1 is likely to be in the next debian release. > > I think it is reasonable for folks who want the latest mpl to be > willing to get the latest numpy. For the GUI toolkits, given how hard > they are to build, your suggestion of targeting debian stable may be > more reasonable, but supporting multiple GUI versions has always been > a pain since we definitely want to support the most recent. > > wxpython is on 2.8.7 and stable is still 2.6? pygtk is at 2.10 and > debian stable is at 2.6. matplotlib is at 0.98 and debian stable is > at 0.87 (Oct 2006 release). September is the target date for the next release of debian according to the release schedule at: http://lists.debian.org/debian-devel-announce/2008/06/msg0.html The packages currently in debian are: Distribution(codename) Package StableTesting Unstable (etch)(lenny) (sid) python-matplotlib 0.87.7-0.30.91.2-20.91.2-2 python-wxversion 2.6.3.2.1.5 2.6.3.2.2-2 2.6.3.2.2-2 python-gtk2 2.8.6-8 2.12.1-12.12.1-6 python-numpy 1:1.0.1-1 1:1.0.4-8 1:1.1.0-1 python2.4.4-2 2.5.2-1 2.5.2-1 There is also python-wxversion (2.8.7.1-0.1) in experimental. Packages are uploaded to unstable. If after a period of time (usually 10 days) there are no major bugs found, and their dependencies can be met by packages in testing, they migrate to testing. For more details http://www.debian.org/releases/testing/ and http://www.debian.org/devel/testing Thus packages in "testing" will be in the next stable release (barring show stopping bugs), packages in "unstable" will probably be in the next stable release, and packages in "experimental" may or may not be in the next stable release. Thus I'd expect python-numpy 1.1.0 to make the next release, but python-wxversion (2.8.7.1) is looking a bit marginal. > So if we want to support stable, *and* > the latest releases, we've got a lot of ongoing compatibility work to > do. For backend maintainers willing to do it, I think that will be > good. But I am hesitant to target such a slow moving repository as a > requirement. Would the next debian release (lenny) be a better target for development versions of matplotlib? What version of matplotlib do you want to go into the next debian release? Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Backend names in matplotlibrc
Greetings. It seems that the list of backends in the matplotlibrc.template file is out-of-sync with the available backend names. In particular, "Qt4Agg", "CocoaAgg", and "emf" are missing, and "GD" and "Paint" are present but not available. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Documentation: New plot directive
I have added a new "plot" directive to our doc infrastructure that does: """ A special directive for including a matplotlib plot. Given a path to a .py file: - On HTML, will include a .png with a link to a high-res .png. - On LaTeX, will include a .pdf This directive supports all of the options of the `image` directive, except for `target` (since plot will add its own target). Additionally, if the :include-source: option is provided, the literal source will be included inline, as well as a link to the source. """ This task took a lot longer than I expected, so I'm going to have to pause for a while. But here's a couple of notes for improvement if anyone wants to take it on: 1) Clicking on the image in HTML currently goes to a high-res PNG. It could instead go to a PDF, which personally I think is preferable, but I know some people are adamantly opposed to installing a PDF plugin in their browser. 2) This only works if the .py files live in users/figures. A more general solution might be to move the actual rendering of .png and .pdf plots (which currently occurs in users/figures/make.py) to the plot directive itself, and have them rendered even more on-the-fly than they are already. Then it could pull .py's from anywhere (such as mpl-examples) and put the resulting images in the correct place for sphinx to find them and add them to the build. 3) The CSS could be tweaked so the images don't get a thick border in HTML. Putting a magnifying glass in the corner would be cool if there's any CSS wizards out there. But that's an aesthetic consideration. People may like the border. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'module' object has no attribute 'GraphicsContext'
On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker <[EMAIL PROTECTED]> wrote: >> So if we want to support stable, *and* >> the latest releases, we've got a lot of ongoing compatibility work to >> do. For backend maintainers willing to do it, I think that will be >> good. But I am hesitant to target such a slow moving repository as a >> requirement. > > Would the next debian release (lenny) be a better target for > development versions of matplotlib? > > What version of matplotlib do you want to go into the next debian release? Hi Chris -- thanks for all the information. Since 0.98 requires numpy 1.1, 0.98.1 (a bugfix release slated for next week or the week after) should be in unstable and 0.91.4 (again a bugfix scheduled for next week or the week after) should be in testing and 0.91.2 should be in stable. I find this a bit conservative, since I think numpy 1.1 should be in testing along with matplotlib 0.98.1, but that is apparently how debian does it. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Backend names in matplotlibrc
On Fri, Jun 13, 2008 at 9:39 AM, Stan West <[EMAIL PROTECTED]> wrote: > Greetings. It seems that the list of backends in the matplotlibrc.template > file is out-of-sync with the available backend names. In particular, > "Qt4Agg", "CocoaAgg", and "emf" are missing, and "GD" and "Paint" are > present but not available. Thanks -- I updated this in svn. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Documentation: New plot directive
On Fri, Jun 13, 2008 at 9:40 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > This task took a lot longer than I expected, so I'm going to have to > pause for a while. But here's a couple of notes for improvement if > anyone wants to take it on: > > 1) Clicking on the image in HTML currently goes to a high-res PNG. It > could instead go to a PDF, which personally I think is preferable, but I > know some people are adamantly opposed to installing a PDF plugin in > their browser. > > 2) This only works if the .py files live in users/figures. A more > general solution might be to move the actual rendering of .png and .pdf > plots (which currently occurs in users/figures/make.py) to the plot > directive itself, and have them rendered even more on-the-fly than they > are already. Then it could pull .py's from anywhere (such as > mpl-examples) and put the resulting images in the correct place for > sphinx to find them and add them to the build. > > 3) The CSS could be tweaked so the images don't get a thick border in > HTML. Putting a magnifying glass in the corner would be cool if there's > any CSS wizards out there. But that's an aesthetic consideration. > People may like the border. I've committed some changes that should address all three of these issues. The plot_directive now assumes you are giving it a pyplot python file (stored in doc/pyplots) and will generate the savefigs at doc build time. The paths are a bit hairy in these rest directives so I decided it was easiest to force all the python files to live in this dir, and we can revisit this later. I am not convinced it is a good idea to point to external files anyway for the image generation (like examples/something.py) since someone may unwittingly change this w/o begin aware the docs are relying on it. I addressed 1 and 3 by not making the image clickable, but rather putting links to the high res png and pdf below it, and along with the src there too. For now I am including a link to the src even if the src is not included, but if there is a reason not to we can easily remove this. There are a few TODOs in there where the code could be cleaner or I am having some unexplained problems. I also updated Darren's section in the devel guide. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] AttributeError: 'module' object has no attribute 'GraphicsContext'
"John Hunter" <[EMAIL PROTECTED]> writes: > On Fri, Jun 13, 2008 at 9:25 AM, Chris Walker > <[EMAIL PROTECTED]> wrote: > > >> So if we want to support stable, *and* > >> the latest releases, we've got a lot of ongoing compatibility work to > >> do. For backend maintainers willing to do it, I think that will be > >> good. But I am hesitant to target such a slow moving repository as a > >> requirement. > > > > Would the next debian release (lenny) be a better target for > > development versions of matplotlib? > > > > What version of matplotlib do you want to go into the next debian release? > > Hi Chris -- thanks for all the information. Pleasure, Hope it was useful, but please note I don't speak for the Debian Matplotlib maintainers. There are some things I need to clarify though. > Since 0.98 requires numpy > 1.1, 0.98.1 (a bugfix release slated for next week or the week after) > should be in unstable and 0.91.4 (again a bugfix scheduled for next > week or the week after) should be in testing Ah, I think you may have misunderstood how debian stable/testing/unstable works. A grossly oversimplified view[1] is as follows. 1) A new version of the package is uploaded to sid (unstable) 2) When the package has been in sid (unstable) for 10 days, it is a candidate for moving to lenny (testing). when they can do so without breaking other packages lenny (testing). 3) Eventually, lenny is released as the stable distribution, and you are stuck with it for a year or two (except security or dataloss bugs). so it sounds like 0.98.x should be what is uploaded to unstable (from where it will migrate to testing). > and 0.91.2 should be in > stable. The version in etch (stable) is only likely to be upgraded (from 0.87.7-0.3) if there are major bugs (such as security problems or data loss issues). See http://www.debian.org/security/ > I find this a bit conservative, since I think numpy 1.1 > should be in testing It was only uploaded 3 days ago, so in theory could migrate in 7 days time. > along with matplotlib 0.98.1, http://packages.qa.debian.org/m/matplotlib.html gives debian package information on matplotlib - including which versions are in stable,testing and unstable. Hopefully 0.98.0 or 0.98.1 packages will be uploaded soon. If not, then giving the maintainers a push to ensure they are in the next debian stable would be a good idea. > but that is > apparently how debian does it. > Hopefully that is now slightly clearer. Chris [1] Packages can migrate more quickly if they contain urgent bug fixes http://www.debian.org/ and specifically http://www.debian.org/devel/testing contains more accurate information. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] polar title and related questions
Mike, John's mention of an upcoming bugfix release brought to mind a glitch in 0.98: the default position of the polar plot title is too low (as is the default position of the title on an ordinary plot with tick_top()). It looks like you were working on this with your autoLayout option, but when I try enabling that, I get (last part of traceback only, and for the Cartesian axes case): /usr/local/lib/python2.5/site-packages/matplotlib/axes.pyc in update_layout(self, renderer) 1421 x0, y0, x1, y1 = self.get_position(True).extents 1422 # Adjust the title -> 1423 self.titleOffsetTrans.clear().translate( 1424 0, original_t_text + pad_pixels * 2.0) 1425 AttributeError: 'ScaledTranslation' object has no attribute 'clear' It looks like this would be prevented if ScaledTranslation were reformulated to inherit from Affine2D instead of Affine2DBase. Is this the right solution? Regardless of the status of the autoLayout code, I thought it would be nice to improve the default title behavior of the polar_demo, at least. Please let me know if you would like to do it, or if you would prefer that I continue looking into it. Thanks. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Consist Symbols/Sizes between Plot/Scatter
John Hunter wrote: > On Fri, Jun 13, 2008 at 7:40 AM, Manuel Metz <[EMAIL PROTECTED]> wrote: > >> Paul Novak had planed to work on scatter legend and I am also interested in >> this, so we came up with a code fragment, but it doesn't do the job well. I >> think a legend for scatter is something that is really needed for >> matplotlib. The main problem is, that I got lost in all those transform >> things - finally I felt like crazy ;-) > >> I think that's something that is also a bit "unfortunate" in matplotlib. >> Basically, there are two different routines to draw markers: one is plot(), >> and on is scatter(). Both do nearly the same thing, but use different code >> bases. >> It might be worth to think about reorganizing this ??? Having one function >> that creates markers, and incorporating them from both, scatter() and >> plot(), sounds like a good idea to me !? > > This is how I see it -- plot draws homogeneous markers. Knowing they > are homogeneous allows us to do optimizations in the backend, like > cacheing the rasterized marker and blitting it many places. This can > radically speed up plots where there are many markers. !!! > scatter, on > the hand, exists to draw heterogeneous markers, which vary either in > size or in color or both. Well, I personally (sometimes) prefer scatter over plot, because scatter has a much greater flexibility to produce different markers (star symbols; custom symbols) ... That could be overcome if both, plot and scatter, use the same code basis to create the markers. That would also make clear that plot should in general be used for homogeneous data and scatter for heterogeneous. > This is why I have always been lukewarm in > adding auto-legend support -- which of the heterogeneous scatter > symbols gets the legend entry? I > > n cases where you only vary the color or only vary the size, one could > use the first polygon as a proxy for auto-legending. This wouldn't > work all the time, but it might be good enough for folks who want > auto-legends and others would still have the option of doing the > legend polygon proxy trick. One way to make this easier would be for > the polygon collections to provide a polygon_proxy method which > returns a unit area patches.Polygon instance with properties set to > correspond to the first polygon in the collection -- then the legend > implementer could use it w/o worrying about all the different types of > polygon collections and the odd sizing that may occur by simply taking > the first element. Something like this might be _very_ useful. I think that would be the most common case (vary only colours / only sizes), especially if one produces figures for print media. As soon as you start to vary colors/sizes/markers over-the-top, you probably don't won't to have a legend any more - it starts to get too crowded. If you have, however, say a data-set with x ~ 3 kinds of different data and only vary few properties (like the sizes only) -- and there is this legend option as you outlined above -- than there is a pretty easy way to produce a meaningful legend. Split the data into x arrays, and call scatter x-times. I personally wouldn't worry too much about the size of a marker in the legend - it should be approximately the size of the text. If I have marked one data-set with squares and one with circles, most likely everyone will understand the legend. > But yes, to the extent that we can centralize the marker symbol -> > path creation and reuse that between the line2d and poly collection > code, that would be a good thing. One could then scale and translate > the canonical polygons as needed for their respective uses. > > On the size as area usage in scatter -- I have found this > counter-intuitive from day 1, and I wrote the damned thing, but as I > noted we inherited this from matlab and a lot of code is built around > it, so we are probably stuck with it. If you think it is sufficiently > irksome, you can add a kwarg to scatter along the lines of > >def scatter(..., sizearea=True) > > where if sizearea is False we treat the size as a linear dimension. > This could also be an rc param so people could set the defaults to > behave in a more intuitive way w/o breaking the old code. > > JDH Manuel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib 0.98.0 error messages when releasing the mouse button
Hi, I got the following messages after clicking with mouse in my application: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/matplotlib-0.98.0-py2.4-linux-i686.egg/matplotlib/backends/backend_gtk.py", line 201, in button_release_event FigureCanvasBase.button_release_event (self, x, y, event.button) File "/usr/lib/python2.4/site-packages/matplotlib-0.98.0-py2.4-linux-i686.egg/matplotlib/backend_bases.py", line 926, in button_release_event self.callbacks.process(s, event) File "/usr/lib/python2.4/site-packages/matplotlib-0.98.0-py2.4-linux-i686.egg/matplotlib/cbook.py", line 152, in process func(*args, **kwargs) File "/usr/lib/python2.4/site-packages/matplotlib-0.98.0-py2.4-linux-i686.egg/matplotlib/backend_bases.py", line 1496, in release_pan for a, ind in self._xypress: TypeError: iteration over non-sequence Mátyás János - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib 0.98.0 colors problem LineCollection
Hi, setting colors with transparency no longer works for me in 0.98.0, but worked before in 0.91.3: c = matplotlib.collections.LineCollection(lines, colors = lineColors) This shows the lines only with the base colors without transparency. However, if I modify the code to the following, the colors shows properly with transparency: c = matplotlib.collections.LineCollection(lines) c.set_color(lineColors) Mátyás János - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Documentation: New plot directive
On Friday 13 June 2008 01:22:24 pm John Hunter wrote: > On Fri, Jun 13, 2008 at 9:40 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > This task took a lot longer than I expected, so I'm going to have to > > pause for a while. But here's a couple of notes for improvement if > > anyone wants to take it on: > > > > 1) Clicking on the image in HTML currently goes to a high-res PNG. It > > could instead go to a PDF, which personally I think is preferable, but I > > know some people are adamantly opposed to installing a PDF plugin in > > their browser. Its too bad internet explorer requires a plugin to handle SVG, we could do svg for html and pdf for latex. Now that I think of it, maybe we should be generating svg files, they can be an additional link, but the pngs are the ones that get rendered on the main page. It will help advertise our diverse output formats, and many users get a scalable format without having to load up Adobe. > > 2) This only works if the .py files live in users/figures. A more > > general solution might be to move the actual rendering of .png and .pdf > > plots (which currently occurs in users/figures/make.py) to the plot > > directive itself, and have them rendered even more on-the-fly than they > > are already. Then it could pull .py's from anywhere (such as > > mpl-examples) and put the resulting images in the correct place for > > sphinx to find them and add them to the build. > > > > 3) The CSS could be tweaked so the images don't get a thick border in > > HTML. Putting a magnifying glass in the corner would be cool if there's > > any CSS wizards out there. But that's an aesthetic consideration. > > People may like the border. > > I've committed some changes that should address all three of these > issues. The plot_directive now assumes you are giving it a pyplot > python file (stored in doc/pyplots) and will generate the savefigs at > doc build time. The paths are a bit hairy in these rest directives so > I decided it was easiest to force all the python files to live in this > dir, and we can revisit this later. I am not convinced it is a good > idea to point to external files anyway for the image generation (like > examples/something.py) since someone may unwittingly change this w/o > begin aware the docs are relying on it. I addressed 1 and 3 by not > making the image clickable, but rather putting links to the high res > png and pdf below it, and along with the src there too. For now I am > including a link to the src even if the src is not included, but if > there is a reason not to we can easily remove this. I just deleted the static_figs directory from svn, and moved the contents into pyplots. The generated figures were committed to svn as well, so they should not be auto-generated. This way we can consistently use the nice plot directive to include all of our figures. I think there should be no problems with this transition, but if you see one, please let me know. I updated the documentation guide to reflect the change. Darren - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Skew-T
Jeff Whitaker wrote: > Ryan May wrote: >> (Sorry if this is a duplicate) >> >> Hi, >> >> I'm trying to make a Skew-T LogP plot, an important plot in >> meteorology, using matplotlib (mainly to help convert people away from >> much more horrible solutions). You can see one here: >> http://www.rap.ucar.edu/weather/upper/oun.gif >> >> and more cartoonish: >> http://www.srh.noaa.gov/oun/images/figure6.gif >> >> >> (Pay attention only to the lower part with the bold red and green >> lines). I'm pretty sure matplotlib can't currently do this, but it >> shouldn't be too hard. The crux of the plot is that you plot >> temperature as a function of pressure, with pressure reversed and >> logarithmically spaced on the Y-axis (ie. high pressure at the bottom) >> and temperature plotted skewed along the X axis. That is, the lines >> of constant temperature intersect the bottom at 45 degree angles. I >> know matplotlib can do log axes, so how hard would it be for me to >> create a transform that can handle the 45 degree skew of the temperature? >> >> Thanks, >> >> Ryan >> >> > Ryan: I'm sure you could do it, and it would be a nice contribution to > the community. There's some IDL code here > > http://cimss.ssec.wisc.edu/camex3/archive/quicklooks/ > > you could work from. There's also NCL code (couldn't find it on the > web, but the source code comes with NCL). I'd suggest working from > those. I don't think you need transforms (although they might make it > easier), since neither of those languages has them. > HTH, > > -Jeff > (Sending to the list this time. Oops) Thanks. I also managed to find a matlab implementation, which was straightforward to port over. I'm working on fleshing out the full Skew-T look right now. As far as using the transforms, here's the question: Does anyone besides the meteorologists have a need for a plot with a skewed axis? If so, it might pay to make this general. Otherwise, this could stay as a specific Skew-T LogP plot. If the latter is the case, does it make sense to include such a method anywhere in Matplotlib? I guess if nothing else it could go in as an example. Opinions? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Documentation: New plot directive
I love working with people who know what they are doing. Thanks guys, for the htmlonly directive. I was able to use it to clean up a few annoyances in the pdf document, like some badly formatted content at the beginning of each part, and the hyperlink on the main page to download the pdf document (see the sixth page (page 1) of http://matplotlib.sourceforge.net/doc/Matplotlib.pdf, and compare with the one in your build/latex after your next update). Darren On Friday 13 June 2008 04:20:38 pm Darren Dale wrote: > On Friday 13 June 2008 01:22:24 pm John Hunter wrote: > > On Fri, Jun 13, 2008 at 9:40 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > > This task took a lot longer than I expected, so I'm going to have to > > > pause for a while. But here's a couple of notes for improvement if > > > anyone wants to take it on: > > > > > > 1) Clicking on the image in HTML currently goes to a high-res PNG. It > > > could instead go to a PDF, which personally I think is preferable, but > > > I know some people are adamantly opposed to installing a PDF plugin in > > > their browser. > > Its too bad internet explorer requires a plugin to handle SVG, we could do > svg for html and pdf for latex. Now that I think of it, maybe we should be > generating svg files, they can be an additional link, but the pngs are the > ones that get rendered on the main page. It will help advertise our diverse > output formats, and many users get a scalable format without having to load > up Adobe. > > > > 2) This only works if the .py files live in users/figures. A more > > > general solution might be to move the actual rendering of .png and .pdf > > > plots (which currently occurs in users/figures/make.py) to the plot > > > directive itself, and have them rendered even more on-the-fly than they > > > are already. Then it could pull .py's from anywhere (such as > > > mpl-examples) and put the resulting images in the correct place for > > > sphinx to find them and add them to the build. > > > > > > 3) The CSS could be tweaked so the images don't get a thick border in > > > HTML. Putting a magnifying glass in the corner would be cool if > > > there's any CSS wizards out there. But that's an aesthetic > > > consideration. People may like the border. > > > > I've committed some changes that should address all three of these > > issues. The plot_directive now assumes you are giving it a pyplot > > python file (stored in doc/pyplots) and will generate the savefigs at > > doc build time. The paths are a bit hairy in these rest directives so > > I decided it was easiest to force all the python files to live in this > > dir, and we can revisit this later. I am not convinced it is a good > > idea to point to external files anyway for the image generation (like > > examples/something.py) since someone may unwittingly change this w/o > > begin aware the docs are relying on it. I addressed 1 and 3 by not > > making the image clickable, but rather putting links to the high res > > png and pdf below it, and along with the src there too. For now I am > > including a link to the src even if the src is not included, but if > > there is a reason not to we can easily remove this. > > I just deleted the static_figs directory from svn, and moved the contents > into pyplots. The generated figures were committed to svn as well, so they > should not be auto-generated. This way we can consistently use the nice > plot directive to include all of our figures. I think there should be no > problems with this transition, but if you see one, please let me know. > > I updated the documentation guide to reflect the change. > > Darren > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Darren S. Dale, Ph.D. Staff Scientist Cornell High Energy Synchrotron Source Cornell University 275 Wilson Lab Rt. 366 & Pine Tree Road Ithaca, NY 14853 [EMAIL PROTECTED] office: (607) 255-3819 fax: (607) 255-9001 http://www.chess.cornell.edu - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Skew-T
Ryan May wrote: > Thanks. I also managed to find a matlab implementation, which was > straightforward to port over. I'm working on fleshing out the full > Skew-T look right now. As far as using the transforms, here's the > question: Does anyone besides the meteorologists have a need for a plot > with a skewed axis? If so, it might pay to make this general. > Otherwise, this could stay as a specific Skew-T LogP plot. If the > latter is the case, does it make sense to include such a method anywhere > in Matplotlib? I guess if nothing else it could go in as an example. Ryan, I think that it would make the most sense as an example; it seems too specialized to be suitable as an axes method, and I tend to think we already have too many of those as it is. It would be especially valuable if you can do it using the transforms machinery, as a new projection, but this would require more work on your part; it would be less of a direct translation of code from other languages. If you have not already done so, look at examples/api/custom_projection_example.py in svn. Eric - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Skew-T
Eric Firing wrote: > Ryan May wrote: > >> Thanks. I also managed to find a matlab implementation, which was >> straightforward to port over. I'm working on fleshing out the full >> Skew-T look right now. As far as using the transforms, here's the >> question: Does anyone besides the meteorologists have a need for a >> plot with a skewed axis? If so, it might pay to make this general. >> Otherwise, this could stay as a specific Skew-T LogP plot. If the >> latter is the case, does it make sense to include such a method >> anywhere in Matplotlib? I guess if nothing else it could go in as an >> example. > > Ryan, > > I think that it would make the most sense as an example; it seems too > specialized to be suitable as an axes method, and I tend to think we > already have too many of those as it is. > > It would be especially valuable if you can do it using the transforms > machinery, as a new projection, but this would require more work on your > part; it would be less of a direct translation of code from other > languages. If you have not already done so, look at > examples/api/custom_projection_example.py in svn. Yeah, the projection approach is what I'm planning on using. Unfortunately, I can't use any of that immediately because Gentoo is stuck on Matplotlib 0.91.2 and Numpy 1.0.4. Once, Numpy 1.1 is in the tree, I can move to the latest matplotlib (even SVN), and then move over too it. In the meanwhile, I've at least looked over that code, and it looks promising. Half the problem has been figuring out the bizarre nature of the Skew-T LogP. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Documentation: New plot directive
On Fri, Jun 13, 2008 at 3:20 PM, Darren Dale <[EMAIL PROTECTED]> wrote: > I just deleted the static_figs directory from svn, and moved the contents into > pyplots. The generated figures were committed to svn as well, so they should > not be auto-generated. This way we can consistently use the nice plot > directive to include all of our figures. I think there should be no problems > with this transition, but if you see one, please let me know. I think we can make it work, but there are some minor hurdles. It is a little brittle in my view to include auto-generated PNGs alongside svn pngs because it makes cleaning hard (we currently have the same problem in the _static dir with the mathtext pngs). The other problem is that when I went to implement your svg suggestion, which is a good one (ditto for ps links), I bumped into some not implemented errors since we don't have draw_tex for svg and some latex runtime problems when I tried to build the ps since I don't have the right fonts. All of this can be worked around, but it will take a little work. I have to run now... We could have a little extra meta data stored, tagging certain files that should not be auto-generated for certain extensions Perhaps we should introduce a new plot directive option, much like include-source, which could be used to suppress auto-gen, or exclude certain targets. .. plot:: tex_unicode_demo.py :include-source: :no-autogen: .. plot:: tex_unicode_demo.py :include-source: :exclude-backends: svg, gdk I'll ponder this over the weekend. JDH - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
