On Mon, Sep 28, 2009 at 16:53, Jae-Joon Lee <lee.j.j...@gmail.com> wrote: > I personally think that a box, whose height has a physical meaning (in > data coordinate) while its width does not, is not a good > representation of your data. A vertical line or something like > errorbar seems to be more suitable to me.
I agree, and if you're a fan of Edward Tufte, then you definitely agree. In his book, he takes the simple Tukey-style boxplot and turns it into a 1-dimension object, in line with the type of data it's representing. However, I still want to implement something that's a bit more traditional, which is why I wanted to pick an arbitrary width for the boxes that stay invariant regardless of the scale that I use. > As Mike has explained, the transform trick (blended or not) won't > work. The width and y-center will be always transformed with the same > transform, which is not what you want. I think you need to create a > custom patch class for this to work. One option seems to subclass the > Rectangle class and overide the _update_patch_transform method. The > patch transform is used to transform a unit rectangle to a rectangle > in data coordinate (or whatever coordinate the patch uses), i.e., you > need to calculate the coordinate of the box in the data coordinate(or > whatever coordinate the patch uses). Could you possibly explain exactly what is going on and how this structurally differs from the approach that Mike posted? In Mike's code, he uses BboxTransformTo using the box he created in display coords. So this takes a unit square and spits out the box that I specify when I instantiate the custom patch (using data coords for x and y and axes coords for w). What is called to actually draw the box (i.e., when I execute plt.draw())? Is that get_path()? So basically, whenever MPL wants to draw a patch, does it always call get_path() and then runs it through whatever is returned from get_transform() to get the final shape in display coords? So how does this relate to the strategy that you are advocating? Is _update_patch_transform somehow a synonym for what I described in the paragraph above? I don't know where that fits into the picture. It may be useful to add something to the "Working With Tranformations" section or the "Transformation Tutorial" about what is minimally necessary to override for a custom patch. I have been playing around with MPL for some time now (albeit I don't have much computer visualization/graphics experience) and still have only a fuzzy idea of what order things are called in and what the overall strategy/structure of the system is like. Uri > > -JJ > >> Uri >> >>> >>> Mike >>> >>> Eric Firing wrote: >>>> >>>> Uri Laserson wrote: >>>> >>>>> >>>>> Is it possible to specify a path object that will use different >>>>> transforms for different vertices? >>>>> >>>>> This is again related to plotting a box whose height is specified by >>>>> data coords, but whose width is a constant in axes coords regardless >>>>> of scale (so linear and log x-scales would produce a box of the same >>>>> width). >>>>> >>>>> Ideally, I would draw a path like this: >>>>> 1. the center of the box would be located at x and bottom and top >>>>> would be y1, y2, all in data coords >>>>> 2. I would move to (x,y1) at the bottom-center of the box. >>>>> 3. The x value would now need to be converted to Axes coords, possibly >>>>> by applying transData + transAxes.inverted >>>>> 4. I would want to draw a line to (x-0.1, y1) where x is now in axes >>>>> coords and y is still in data coords. Then up, then right, then down, >>>>> and then close the polygon. >>>>> >>>>> How do I implement this? >>>>> >>>> >>>> I must be missing something, because I still don't see why you can't do >>>> all this very simply by using a PolyCollection, with the vertices in axes >>>> coordinates and the offset in data coordinates. >>>> >>>> Eric >>>> >>>> >>>>> >>>>> As I mentioned before, a blended transform would allow me to make the >>>>> moves i am interested in. However, a change of scale would change the >>>>> correspondence between data and axes coords, so the axes transform >>>>> part of the blended axes would have to be recomputed everytime the >>>>> scale changes based on where the (x,y1) point lands in the axes. Is >>>>> this correct? >>>>> >>>>> Any suggestions are welcome...thanks! >>>>> >>>>> Uri >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and stay >>>> ahead of the curve. Join us from November 9-12, 2009. Register now! >>>> http://p.sf.net/sfu/devconf >>>> _______________________________________________ >>>> Matplotlib-users mailing list >>>> Matplotlib-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>>> >>> >>> -- >>> Michael Droettboom >>> Science Software Branch >>> Operations and Engineering Division >>> Space Telescope Science Institute >>> Operated by AURA for NASA >>> >>> >> >> >> >> -- >> Uri Laserson >> PhD Candidate, Biomedical Engineering >> Harvard Medical School (Genetics) >> Massachusetts Institute of Technology (Mathematics) >> phone +1 917 742 8019 >> laser...@mit.edu >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Matplotlib-users mailing list >> Matplotlib-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > -- Uri Laserson PhD Candidate, Biomedical Engineering Harvard Medical School (Genetics) Massachusetts Institute of Technology (Mathematics) phone +1 917 742 8019 laser...@mit.edu ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
