Re: [matplotlib-devel] mkpg on OSX
I did the following and now matplotlib 0.99.0 rc2 runs fine on my home computer: - I reverted my site-packages to its state before running the matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg installer (I had saved a zip file just in case anything went wrong) - I found I had numpy 1.2.1 installed, so I upgraded to 1.3.0 - I found I had some version of pytz and dateutil installed, so I deleted them (in case there was a conflict with the versions matplotlib wanted to use) - I ran the matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg again (from a dmg that I'd created) Now it all works! I hope that numpy was too old, since I don't see how the other changes could possibly be relevant. By the way: the ReadMe in the matplotlib Mac binary installer is for the source distro, and so not very relevant to the Mac installer. If and when you have time I suggest writing one for the Mac. Relevant info includes: - which back ends are supported in this build - minimum required versions for wxPython (if using wxAgg), numpy, Tcl/ Tk, GTK (if relevant), etc. I will send you the file I used to use when I built a matplotlib installer. bdist_mpkg has a --readme flag or you can just copy it manually, overwriting whatever it put in there. Please feel free to do as you like with the file; I have no proprietary feelings about it. Thank you very, very much for making the installer and being willing to work on the Tcl/Tk crash. It's great that you have figured out an automated way to build it that works and supports Tcl/Tk. My process was manual and rather a pain (copying object libraries into /usr/local/ lib, bdist_mpkg, removing the libraries again...). Regards, -- Russell On Aug 5, 2009, at 3:27 AM, John Hunter wrote: On Tue, Aug 4, 2009 at 11:04 PM, Russell Owen wrote: Thank you very much. Unfortunately it doesn't work for me. Trying to import pylab results in a bus error (I appended the log in case it has anything useful in it). My configuration: - Intel Mac - MacOS X 10.5.7 - Python 2.5.2 (in /Library/Frameworks... from python.org) - Tcl/Tk 8.4.19 (in /Library/Frameworks... from ActiveState) - this occurs with or without a ~/.matplotlib/matplotlibrc file (that uses TkAgg) and with or without a ~/.matplotlib directory at all I have confirmed that Tkinter works fine.\ Can you create a small test script that creates an mpl figure and saves it with savefig, and run it with python myscript.py -dTkAgg python myscript.py -dWXAgg python myscript.py -dAgg python myscript.py -dmacosx and let me know if all segfault, and if not, which ones do? JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] problem with draw method in svn version?
On Tue, Aug 4, 2009 at 5:33 AM, Jonathan Demaeyer wrote: > Hello, > > Thank you for your answer. When I explicitly give None as renderer argument, > everything work well. > Now I guess the question is why the default value is not used by the method? > The Axes.draw is the only the "draw" method that has a default value for renderer argument. Well, we'd better have a separate decoratorfor Axes.draw. > By the way, rasterization support wasn't introduced earlier than the 0.98.3 > version? Yes, the rasterization support was there for a while. I was talking about the support for rasterization "per aritst" by decorating the draw methods of individual artists. -JJ > > Regards, > > Jonathan > > > Jae-Joon Lee a écrit : >> I guess this is related with the decorator introduced by rasterization >> support. >> While most of the artist seems to explicitly require the renderer >> instance as the second argument of the draw method, the draw method in >> the Axes class have default value of None. >> The easiest fix seems to let the decorator returns the method with >> renderer=None as in the Axes. >> >> By the way, Jonathan, I guess the easiest workaround for you is to >> modify your code so that it explicitly gives the renderer argument. As >> you see the default value for renderer is None. Just call it as >> draw(None). >> >> Regards, >> >> -JJ >> > > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
Ok, I forgot my attachments would be stripped. Links: Output of surface3d_demo.py (should explain why I want this patch) http://static.ryanjwagner.com/mpl_patches/lightSource.png Example code http://static.ryanjwagner.com/mpl_patches/surface3d_demo.py Edited mpl source... just proof of concept... still has to be cleaned up. http://static.ryanjwagner.com/mpl_patches/axes3d.py Also, upon looking at colors.LightSource, I think this doesn't really need to be changed for 3D except it would only work for regularly spaced data... might be a nice enhancement to supply the X and Y arrays as well as Z so it can calculate gradients for irregularly spaced grids. -Ryan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner wrote: > Hi, > I'd like to propose adding a SHADES keyword to the mplot3D routines where > you can supply your own The other thing that would be really nice is to have smooth interpolation along each face. Michael, do you have a sense how hard it would be in agg (and other backends) to do a linear gradient interpolation over a quadrilateral with one RGBA at each vertex? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] bug in imshow for PDF, EPS output
I've added this to the sourceforge bug tracker, ID 2832896. Mike On Aug 5, 2009, at 3:32 PM, Michael Fitzgerald wrote: > > Hi all, > > I've come across an apparent bug in imshow when outputting to PDF > and EPS files. (I haven't tested other vector formats.) It > manifests as a small scaling error between the raster image and the > axes coordinates. > > I have attached a test script to illustrate the problem. The > (correct) PNG output file shows a green 'X' at the common point > between four pixels near the center of the raster image. The > extent is chosen such that the coordinates refer to pixel centers. > The PDF and EPS output files show a misalignment between the X and > the pixel boundaries -- zoom in to see it clearly. Also, the > topmost row and rightmost column appear truncated. > > I am using svn r7395. > > Thanks for the attention, > Mike > > -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] complex path problem
Mike,
When I eliminate the cuts from filled contour paths, I do find
pathological cases where the filling works correctly with the cuts in
place, but not without them. Attached are a data file and a script to
plot it, illustrating the problem. Is this due to a known limitation of
filled paths? In the example, the top two holes are connected to the
lower hole, instead of being connected directly to the outer boundary of
the filled region. Is this illegal? If so, I think we are stuck,
because rearranging the paths that cntr makes to eliminate this type of
case would likely be very difficult.
Eric
badpath.npz
Description: Binary data
import numpy as np
import matplotlib.path as mpath
import matplotlib.patches as mpatches
import matplotlib.pyplot as plt
# Badpath was generated by the contour algorithm on random data.
d = np.load('badpath.npz')
verts = d['verts']
codes = d['codes']
# Simplify it, while still showing the problem.
mask = np.ones(codes.shape, bool)
mask[45:55] = False
mask[32:38] = False
mask[40:42] = False
verts = verts.compress(mask, axis=0)
codes = codes.compress(mask)
fig = plt.figure()
ax1 = fig.add_subplot(1,2,1)
path = mpath.Path(verts, codes)
patch = mpatches.PathPatch(path, facecolor='g', edgecolor='k')
ax1.add_patch(patch)
ax1.axis(xmin=-1, xmax=6, ymin=-1, ymax=6)
ax1.set_title('With MOVETO')
ax2 = fig.add_subplot(1,2,2)
codes = codes.copy()
codes[1:] = 2
path = mpath.Path(verts, codes)
patch = mpatches.PathPatch(path, facecolor='g', edgecolor='k', alpha=0.5)
ax2.add_patch(patch)
ax2.axis(xmin=-1, xmax=6, ymin=-1, ymax=6)
ax2.set_title('With LINETO')
npts = len(codes)
mid1 = npts//3
mid2 = mid1 * 2
lslice = slice(None, mid1)
mslice = slice(mid1, mid2)
rslice = slice(mid2, None)
c = np.arange(npts, dtype=float)
imove = codes == 1
iline = codes == 2
# Mark the starting oint with a black asterisk, endpoint with red +
plt.plot(verts[0,0], verts[0,1], 'k*', markersize=15, zorder=5)
plt.plot(verts[-1,0], verts[-1,1], 'r+', markersize=20, zorder=6)
# mark the path divided into thirds.
plt.plot(verts[lslice,0], verts[lslice,1], 'k')
plt.plot(verts[mslice,0], verts[mslice,1], 'c')
plt.plot(verts[rslice,0], verts[rslice,1], 'r')
# Use size and colors to show order of points.
# This doesn't work as well as desired; in particular, the
# slit downstrokes still obliterate the slit upstrokes.
sz = 120*(codes-0.5) * (1 - 0.7 * c/npts)
plt.scatter(verts[:,0], verts[:,1], s=sz, c=c, edgecolor='none', alpha=0.5)
plt.spectral()
plt.colorbar()
plt.show()
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New spines capabilities question
Hi, Congrats on the latest matplotlib release. Looks like there are some *really* impressive new things in there. I was just looking at the spines docs: http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html And I noticed that on spines that are range limited (to the data) in the y direction, the blueish line of the graph is actually cut off near the limit. It is not obvious, but one you see it, you notice it in all the examples (look at the peaks and troughs of the sin curve). Is this a known issue or can this be prevented? Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
I looked into this a while ago wrt 2D quad meshes, and it didn't look like there was anything built-in to do something like that. All the gradients are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table of colors). There's nothing to do a 4-way blend like this. So it would have to be from scratch, at least for the colored part -- we can still use Agg to render the quad shapes themselves. Mike John Hunter wrote: > On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner wrote: > >> Hi, >> I'd like to propose adding a SHADES keyword to the mplot3D routines where >> you can supply your own >> > > The other thing that would be really nice is to have smooth > interpolation along each face. Michael, do you have a sense how hard > it would be in agg (and other backends) to do a linear gradient > interpolation over a quadrilateral with one RGBA at each vertex? > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > 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 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New spines capabilities question
On Thu, Aug 6, 2009 at 1:01 PM, Brian Granger wrote: > Hi, > > Congrats on the latest matplotlib release. Looks like there are some > *really* impressive new things in there. I was just looking at the spines > docs: > > http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html > > And I noticed that on spines that are range limited (to the data) in the y > direction, the blueish line of the graph is actually cut off near the > limit. It is not obvious, but one you see it, you notice it in all the > examples (look at the peaks and troughs of the sin curve). > > Is this a known issue or can this be prevented? I think this happens in all mpl graphs, you just don't see it. The axis limits are set to -2..2, and the sine is draw from -2..2. The linewidth extends beyond 2, so it is clipped by the axes clipping to the bounding rectangle. Normally you don't see this, because visually it is under the surrounding axes black edge. You can either set the ylimits wider: ax.set_ylim(-2.1, 2.1) or turn clipping off ax.plot(x,y, clip_on=False) JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom wrote: > I looked into this a while ago wrt 2D quad meshes, and it didn't look like > there was anything built-in to do something like that. All the gradients > are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table > of colors). There's nothing to do a 4-way blend like this. So it would > have to be from scratch, at least for the colored part -- we can still use > Agg to render the quad shapes themselves. What about for other backends (PS, PDF, SVG)? If there was support in the gradient spec for these, it might be worth it to try and write a custom gradient function in agg, as suggested by Maxim at the end of this tutorial: http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
Shouldn't colorbar_doc name be hidden from users? It doesn't look like the rest other function documentation in pyplot.py file. In [10]: color colorbar colorbar_doc colormaps colors at rev 7405. In [10]: colorbar_doc Out[10]: "\n\nAdd a colorbar to a plot.\n\nFunction signatures for the :mod:`~matplotlib.pyplot` interface; all\nbut the first are also method signatures for the\n:meth:`~matplotlib.figure.Figure.colorbar` method::\n\n colorbar(**kwargs)\n colorbar(mappable, **kwargs)\n colorbar(mappable, cax=cax, **kwargs)\n colorbar(mappable, ax=ax, **kwargs)\n\narguments:\n\n *mappable*\nthe :class:`~matplotlib.image.Image`,\n :class:`~matplotlib.contour.ContourSet`, etc. to\nwhich the colorbar applies; this argument is mandatory for the\n :meth:`~matplotlib.figure.Figure.colorbar` method but optional for the\n :func:`~matplotlib.pyplot.colorbar` function, which sets the\ndefault to the current image.\n\nkeyword arguments:\n\n *cax*\nNone | axes object into which the colorbar will be drawn\n *ax*\nNone | parent axes object from which space for a new\ncolorbar axes will be stolen\n\n\nAdditional keyword arguments are of two kinds:\n\n axes properties:\n\n\n = \n Property Description\n= \n*orientation* vertical or horizontal\n*fraction*0.15; fraction of original axes to use for colorbar\n*pad* 0.05 if vertical, 0.15 if horizontal; fraction\n of original axes between colorbar and new image axes\n*shrink* 1.0; fraction by which to shrink the colorbar\n *aspect* 20; ratio of long to short dimensions\n= \n\n\n colorbar properties:\n\n\n=== \nProperty Description\n=== \n*extend* [ 'neither' | 'both' | 'min' | 'max' ]\n If not 'neither', make pointed end(s) for out-of-\n range values. These are set for a given colormap\n using the colormap set_under and set_over methods.\n*spacing* [ 'uniform' | 'proportional' ]\n Uniform spacing gives each discrete color the same\n space; proportional makes the space proportional to\n the data interval.\n*ticks* [ None | list of ticks | Locator object ]\n If None, ticks are determined automatically from the\n input.\n*format* [ None | format string | Formatter object ]\n If None, the\n :class:`~matplotlib.ticker.ScalarFormatter` is used.\n If a format string is given, e.g. '%.3f', that is\n used. An alternative\n :class:`~matplotlib.ticker.Formatter` object may be\n given instead.\n*drawedges* [ False | True ] If true, draw lines at color\n boundaries.\n=== \n\nThe following will probably be useful only in the context of\nindexed colors (that is, when the mappable has norm=NoNorm()),\nor other unusual circumstances.\n\n ===\nProperty Description\n ===\n*boundaries* None or a sequence\n*values* None or a sequence which must be of length 1 less\n than the sequence of *boundaries*. For each region\n delimited by adjacent entries in *boundaries*, the\n color mapped to the corresponding value in values\n will be used.\n ===\n\n\n\nIf *mappable* is a :class:`~matplotlib.contours.ContourSet`, its *extend*\nkwarg is included automatically.\n\nNote that the *shrink* kwarg provides a simple way to keep a vertical\ncolorbar, for example, from being taller than the axes of the mappable\nto which the colorbar is attached; but it is a manual method requiring\nsome trial and error. If the colorbar is too tall (or a horizontal\ncolorbar is too wide) use a smaller value of *shrink*.\n\nFor more precise control, you can manually specify the positions of\nthe axes objects in which the mappable and the colorbar are drawn. In\nthis case, do not use any of the axes properties kwargs.\n\nreturns:\n :class:`~matplotlib.colorbar.Colorbar` instance; see also its base class,\n:class:`~matplotlib.colorbar.ColorbarBase`. Call the\n :meth:`~matplotlib.colorbar.ColorbarBase.set_label` method\nto label the colorbar.\n\n" -- Gökhan -- Let Crystal Reports handle the rep
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever wrote: > Shouldn't colorbar_doc name be hidden from users? It doesn't look like the > rest other function documentation in pyplot.py file. > > In [10]: color > colorbar colorbar_doc colormaps colors Good catch. Fixed in 7406. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, OK, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever wrote: > Shouldn't colorbar_doc name be hidden from users? It doesn't look like the > rest other function documentation in pyplot.py file. > > In [10]: color > colorbar colorbar_doc colormaps colors > > at rev 7405. We are not very good about using the __all__ designation in our modules. I will change this to from matplotlib.colorbar import colorbar_doc as _colorbar_doc in pyplot so it doesn't show up in normal tab completions, etc. JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
John Hunter wrote: > On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom wrote: > >> I looked into this a while ago wrt 2D quad meshes, and it didn't look like >> there was anything built-in to do something like that. All the gradients >> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table >> of colors). There's nothing to do a 4-way blend like this. So it would >> have to be from scratch, at least for the colored part -- we can still use >> Agg to render the quad shapes themselves. >> > > What about for other backends (PS, PDF, SVG)? If there was support in > the gradient spec for these, it might be worth it to try and write a > custom gradient function in agg, as suggested by Maxim at the end of > this tutorial: > > http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html > Even with this, the gradient infrastructure in Agg assumes a one-dimensional map, and here we need to at least interpolate between the three points of a triangle. It's not impossible, as it's easy enough to make a custom shader, it's just that the gradient code won't help us. A possible workaround is suggested by this paper: http://www.svgopen.org/2005/papers/Converting3DFaceToSVG/index.html That is, rather than doing a single Gourad triangle interpolation, just overlap three linear gradient patches with alpha blending. At the very least it presents a way to support this in SVG which doesn't currently have Gourad interpolation. PDF and PS support Gourad triangles directly, though supporting it looks -- um -- "fun". Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: > > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever wrote: >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the >> rest other function documentation in pyplot.py file. >> >> In [10]: color >> colorbar colorbar_doc colormaps colors > > Good catch. Fixed in 7406. Just reading this, it looks like you missed the import matplotlib.colorbar part, no? Or am I missing something? When possible, could you make bugfixes to the branch and merge to the trunk? I know this is a bit of a hassle, but we often live on a release branch for several bug fix release cycles, so it is nice to put the simple fixes there http://matplotlib.sourceforge.net/devel/coding_guide.html JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:55 PM, John Hunter wrote: > On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: > > > > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever > wrote: > >> > >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like > the > >> rest other function documentation in pyplot.py file. > >> > >> In [10]: color > >> colorbar colorbar_doc colormaps colors > > > > Good catch. Fixed in 7406. > > Just reading this, it looks like you missed the import > matplotlib.colorbar part, no? Or am I missing something? On my machine, the import didn't seem to be necessary. matplotlib.colorbar is available just with: import matplotlib Would it be better to explicitly import matplotlib.colorbar anyways? > When possible, could you make bugfixes to the branch and merge to the > trunk? I know this is a bit of a hassle, but we often live on a > release branch for several bug fix release cycles, so it is nice to > put the simple fixes there > > http://matplotlib.sourceforge.net/devel/coding_guide.html > Yeah, my bad. I just remembered after committing to trunk and was working on checking out the new branch and applying there when you made your fix. So what n ow? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 1:59 PM, Ryan May wrote: > On Thu, Aug 6, 2009 at 1:55 PM, John Hunter wrote: >> >> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: >> > >> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever >> > wrote: >> >> >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like >> >> the >> >> rest other function documentation in pyplot.py file. >> >> >> >> In [10]: color >> >> colorbar colorbar_doc colormaps colors >> > >> > Good catch. Fixed in 7406. >> >> Just reading this, it looks like you missed the import >> matplotlib.colorbar part, no? Or am I missing something? > > On my machine, the import didn't seem to be necessary. matplotlib.colorbar > is available just with: > > import matplotlib Strange... j> python Python 2.4.5 (#4, Apr 12 2008, 09:09:16) [GCC 3.4.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import matplotlib >>> matplotlib.colorbar Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'colorbar' >>> matplotlib.__version__ '1.0.svn' > Would it be better to explicitly import matplotlib.colorbar anyways? Yes >> When possible, could you make bugfixes to the branch and merge to the >> trunk? I know this is a bit of a hassle, but we often live on a >> release branch for several bug fix release cycles, so it is nice to >> put the simple fixes there >> >> http://matplotlib.sourceforge.net/devel/coding_guide.html > > Yeah, my bad. I just remembered after committing to trunk and was working > on checking out the new branch and applying there when you made your fix. > So what n ow? Ahh, now the pain begins. I believe the easiest path is to put the change in the branch, svn commit, go over to the trunk, svnmerge, resolve any conflicts and commit. Now wasn't that easy? JDH -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] colorbar_doc is visible as a function name with Ipython --pylab import
On Thu, Aug 6, 2009 at 2:03 PM, John Hunter wrote: > On Thu, Aug 6, 2009 at 1:59 PM, Ryan May wrote: > > On Thu, Aug 6, 2009 at 1:55 PM, John Hunter wrote: > >> > >> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May wrote: > >> > > >> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever > >> > wrote: > >> >> > >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look > like > >> >> the > >> >> rest other function documentation in pyplot.py file. > >> >> > >> >> In [10]: color > >> >> colorbar colorbar_doc colormaps colors > >> > > >> > Good catch. Fixed in 7406. > >> > >> Just reading this, it looks like you missed the import > >> matplotlib.colorbar part, no? Or am I missing something? > > > > On my machine, the import didn't seem to be necessary. > matplotlib.colorbar > > is available just with: > > > > import matplotlib > > Strange... > > j> python > Python 2.4.5 (#4, Apr 12 2008, 09:09:16) > [GCC 3.4.1] on sunos5 > Type "help", "copyright", "credits" or "license" for more information. > >>> import matplotlib > >>> matplotlib.colorbar > Traceback (most recent call last): >File "", line 1, in ? > AttributeError: 'module' object has no attribute 'colorbar' > >>> matplotlib.__version__ > '1.0.svn' > Stranger still (or it is to me): Python 2.6.2 (r262:71600, Aug 3 2009, 10:34:14) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import matplotlib >>> matplotlib.colorbar Traceback (most recent call last): File "", line 1, in AttributeError: 'module' object has no attribute 'colorbar' >>> from matplotlib import pyplot >>> matplotlib.colorbar > > > Would it be better to explicitly import matplotlib.colorbar anyways? > > Yes > Clearly. >> When possible, could you make bugfixes to the branch and merge to the >> trunk? I know this is a bit of a hassle, but we often live on a >> release branch for several bug fix release cycles, so it is nice to >> put the simple fixes there >> >> http://matplotlib.sourceforge.net/devel/coding_guide.html > > Yeah, my bad. I just remembered after committing to trunk and was working > on checking out the new branch and applying there when you made your fix. > So what n ow? Ahh, now the pain begins. I believe the easiest path is to put the > change in the branch, svn commit, go over to the trunk, svnmerge, > resolve any conflicts and commit. Now wasn't that easy? I remember doing this before now. I don't think there will be any problems with making the changes outside of svnmerge. The alternative is to change trunk back and use svnmerge. I don't mind doing either. Got a preference on which way to handle colorbar_doc? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma Sent from Norman, Oklahoma, United States -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] New spines capabilities question
> I think this happens in all mpl graphs, you just don't see it. The > axis limits are set to -2..2, and the sine is draw from -2..2. The > linewidth extends beyond 2, so it is clipped by the axes clipping to > the bounding rectangle. Normally you don't see this, because visually > it is under the surrounding axes black edge. Yes, I saw that it looks like it happens under the axes clipping. > You can either set the > ylimits wider: > ax.set_ylim(-2.1, 2.1) > But would this also make the spine have the larger limits? Basically, I want know if the spines can be used to create Tufte-style range-frames. Am I correct in thinking that these spines provide that? Or is there another way to get a range-frame? > or turn clipping off > > ax.plot(x,y, clip_on=False) > This looks hopeful and I will give it a shot. Cheers, Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
Hi Mike and John, I've got a question about the functionality about axes3d.plot_surface: When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this: http://static.ryanjwagner.com/mpl_patches/lw0.png I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this: http://static.ryanjwagner.com/mpl_patches/lw0_fix.png Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword? WRT to the previous conversation about the gradients, I have been wishing for that for a while myself, but I understand the difficulty in doing the interpolations. In my own work I end up interpolating the data much finer and it looks better since the polygons are so small you can't notice the single colored polys: http://static.ryanjwagner.com/mpl_patches/animation.gif But I think this looks even better now that I'm able to do it without the visible wiremesh. -Ryan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner wrote: > When I set the linewidths to 0 (in the patch I'm working on) I get an image > looking like this: > > http://static.ryanjwagner.com/mpl_patches/lw0.png > > I don't think this looks correct to me, as I can still see the grid. I have a > workaround in place so if linewidth=0 then the image looks like this: > > http://static.ryanjwagner.com/mpl_patches/lw0_fix.png > > Would you agree that this should be the expected functionality or should I > leave this alone, or should it be a new keyword? Perhaps leaving it as it is today for lw=0, but having your behavior be the result for lw=None? I can see people wanting the very fine grid that lw=0 gives today, and lw=None to me seems to be very explicitly saying 'no lines'. Just an idea... Cheers, f ps - Congrats to all on the release! You've all done an absolutely terriffic job, and the benefits are already becoming obvious with these new ideas and contributions. We'll have to celebrate at scipy :) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
Fernando Perez wrote: > On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner wrote: >> When I set the linewidths to 0 (in the patch I'm working on) I get an image >> looking like this: >> >> http://static.ryanjwagner.com/mpl_patches/lw0.png >> >> I don't think this looks correct to me, as I can still see the grid. I have >> a workaround in place so if linewidth=0 then the image looks like this: >> Does your workaround work for all supported backends, and with alpha less than 1? If so, what is it? >> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png >> >> Would you agree that this should be the expected functionality or should I >> leave this alone, or should it be a new keyword? > > Perhaps leaving it as it is today for lw=0, but having your behavior > be the result for lw=None? I can see people wanting the very fine > grid that lw=0 gives today, and lw=None to me seems to be very > explicitly saying 'no lines'. Except that in typical mpl usage, None means use a default. For colors, 'none' (a string) means no color, so a line should not be drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it seems right to me that it should do the same for 3-D. Eric > > Just an idea... > > Cheers, > > f > > ps - Congrats to all on the release! You've all done an absolutely > terriffic job, and the benefits are already becoming obvious with > these new ideas and contributions. We'll have to celebrate at scipy > :) > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.
> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner wrote: >> When I set the linewidths to 0 (in the patch I'm working on) I get an image >> looking like this: >> >> http://static.ryanjwagner.com/mpl_patches/lw0.png >> >> I don't think this looks correct to me, as I can still see the grid. I have >> a workaround in place so if linewidth=0 then the image looks like this: >> >Does your workaround work for all supported backends, and with alpha >less than 1? If so, what is it? I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far! >> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png >> >> Would you agree that this should be the expected functionality or should I >> leave this alone, or should it be a new keyword? > > Perhaps leaving it as it is today for lw=0, but having your behavior > be the result for lw=None? I can see people wanting the very fine > grid that lw=0 gives today, and lw=None to me seems to be very > explicitly saying 'no lines'. >Except that in typical mpl usage, None means use a default. >For colors, 'none' (a string) means no color, so a line should not be >drawn. Elsewhere in mpl, lw=0 also means "don't draw it at all", so it >seems right to me that it should do the same for 3-D. Seems like we need more discussion about this... anyone else want to chime in? I do like Fernando's idea if only to not break backwards compatability... >Eric > > Just an idea... > > Cheers, > > f > > ps - Congrats to all on the release! You've all done an absolutely > terriffic job, and the benefits are already becoming obvious with > these new ideas and contributions. We'll have to celebrate at scipy > :) > > -- > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
