Re: [matplotlib-devel] Wind Barbs
Ryan May wrote: > Ok, > > I've committed my wind barbs stuff in SVN. Anyone interested, go ahead > an hammer on it. Very nice! Comments on the example, barb_demo.py: 1) In your third panel, you put the args after the kwargs. I had no idea this was even legal--it's the first time I have seen it. It's probably better to stick with conventional usage so as not to distract the reader from the point, which is how to use the barb function. 2) In a similar vein, I would suggest sticking with explicit X, Y, U, V arguments. Your (*zip(*data)) is an obfuscation. 3) It would be better to use non-square asymmetric arrays so as to make it clear which point in the data array corresponds to which point on the plot. An example with NxN arrays doesn't help illustrate the relation between the array and the plot locations. Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] is_scalar bug
Hi,
I believe that the cbook.is_scalar function has a bug:
In [19]: cbook.is_scalar('abc')
Out[19]: 1
I believe it should be:
def is_scalar(obj):
'return true if *obj* is not string like and is not iterable'
return not is_string_like(obj) and not iterable(obj)
Cheers,
David
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs
Eric Firing wrote: > Ryan May wrote: >> Ok, >> >> I've committed my wind barbs stuff in SVN. Anyone interested, go >> ahead an hammer on it. > > Very nice! > > Comments on the example, barb_demo.py: > > 1) In your third panel, you put the args after the kwargs. I had no > idea this was even legal--it's the first time I have seen it. It's > probably better to stick with conventional usage so as not to distract > the reader from the point, which is how to use the barb function. Magic! I don't know either. It's one of those things you stick in during development for expediency. > 2) In a similar vein, I would suggest sticking with explicit X, Y, U, V > arguments. Your (*zip(*data)) is an obfuscation. Agreed. > 3) It would be better to use non-square asymmetric arrays so as to make > it clear which point in the data array corresponds to which point on the > plot. An example with NxN arrays doesn't help illustrate the relation > between the array and the plot locations. Sure. I was going to tweak the demo anyways to show off more of the available parameters, so all of this will fit in well with that. I'll try to squeeze that in tonight. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] clabel improvements
Hi, Well, I now know more than I ever wanted to about clabel. I decided to improve a bit on the inlining and ended up rewriting it. For automatic label placement, I basically use the existing algorithm for determining label location, but have replaced existing code for determining the angle of rotation and the amount of the contour to take off for inlining with new code. This new code is based on using pixel-space distances along the contour. This allows one to (1) get nice balanced inlining with the same amount of space on either side of the label, and (2) to vary the amount of space you want around the label. It also should deal better with labels located near contour edges and labels covering the entire contour. Along the way, I renamed all ContourLabeler specific attributes to something like .labelAttribute. This makes the namespace cleaner in my mind, but might break existing user code that does things directly with ContourLabeler attributes. I also added a few new functions to cbook. One does simple linear interpolation (in addition to an existing cbook function that is similar but a bit different). Others do things with vector lengths. I also added a function called isvector that is identical to a Matlab function of the same name. If desired, I can move this to mlab.py, but for the moment it is in cbook.py because most of the is? functions are there. On an aside, I noted that mlab.norm uses cut-and-paste documentation from Matlab. Is this wise? I have tested all the changes against the existing pylab_examples and things work fine. Nonetheless, since lots of things have been changed, I haven't committed them for fear of interfering with the release. Instead, I am attaching the patch set. If I get the green light, I will commit these changes. Related: while I am digging around in there, now is probably the moment for me to integrate Paul Kienzle's comments on start/stop_event_loop in FigureCanvasBase, etc. I am not sure there is a consensus on this. I am currently thinking that the best way to integrate this, while minimizing repeated code, is a mixin plus a couple of new classes, FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would inherit the mixin and the base classes without "GUI". Interactive backends would then inherit these. Non-interactive backends would inherit versions that throw errors from FigureBaseCanvas. Complex, but this assures clean inheritance. Thoughts welcome. Cheers, David -- ** David M. Kaplan Charge de Recherche 1 Institut de Recherche pour le Developpement Centre de Recherche Halieutique Mediterraneenne et Tropicale av. Jean Monnet B.P. 171 34203 Sete cedex France Phone: +33 (0)4 99 57 32 27 Fax: +33 (0)4 99 57 32 95 http://www.ur097.ird.fr/team/dkaplan/index.html ** Index: lib/matplotlib/cbook.py === --- lib/matplotlib/cbook.py (revision 5797) +++ lib/matplotlib/cbook.py (working copy) @@ -287,7 +287,7 @@ def is_scalar(obj): 'return true if *obj* is not string like and is not iterable' -return is_string_like(obj) or not iterable(obj) +return not is_string_like(obj) and not iterable(obj) def is_numlike(obj): 'return true if *obj* looks like a number' @@ -1154,6 +1154,46 @@ return result +def less_simple_linear_interpolation( x, y, xi, extrap=False ): +""" +This function provides simple (but somewhat less so than +simple_linear_interpolation) linear interpolation. This is very +inefficient linear interpolation meant to be used only for a small +number of points in relatively non-intensive use cases. + +Call signature:: + +yi = less_simple_linear_interpolation(x,y,xi) +""" +if is_scalar(xi): xi = [xi] + +x = np.asarray(x) +y = np.asarray(y) +xi = np.asarray(xi) + +s = list(y.shape) +s[0] = len(xi) +yi = np.tile( np.nan, s ) + +for ii,xx in enumerate(xi): +bb = x == xx +if np.any(bb): +jj, = np.nonzero(bb) +yi[ii] = y[jj[0]] +elif xxx[-1]: +if extrap: +yi[ii] = y[-1] +else: +jj, = np.nonzero(x x-xlabel)) & -((yy < y+ylabel) & (yy > y-ylabel))) - -if len(inds) >0: -#if the label happens to be over the beginning of the -#contour, the entire contour is removed, i.e. -#indices to be removed are -#inds= [0,1,2,3,305,306,307] -#should rewrite this in a better way -linds, = np.nonzero(inds[1:]- inds[:-1] != 1) -if inds[0] == 0 and len(linds) != 0: -ii = inds[linds[0]] -lc1 =linecontour[ii+1:inds[ii+1]] -lc2 = [] - -else: -lc1=linecontour[:inds[0]] -lc2= linecontour[inds[-1]+1:] - -else: -lc1=lineco
Re: [matplotlib-devel] is_scalar bug
On Wed, Jul 23, 2008 at 4:04 AM, David Kaplan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I believe that the cbook.is_scalar function has a bug:
>
> In [19]: cbook.is_scalar('abc')
> Out[19]: 1
>
> I believe it should be:
>
> def is_scalar(obj):
>'return true if *obj* is not string like and is not iterable'
>return not is_string_like(obj) and not iterable(obj)
Yep, good catch. I committed this fix to 5822
JDH
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] is_scalar bug
Hi,
Almost:
In [3]: cbook.is_scalar((0,1))
Out[3]: True
That should be an "and" not an "or".
Cheers,
David
On Wed, 2008-07-23 at 08:16 -0500, John Hunter wrote:
> On Wed, Jul 23, 2008 at 4:04 AM, David Kaplan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I believe that the cbook.is_scalar function has a bug:
> >
> > In [19]: cbook.is_scalar('abc')
> > Out[19]: 1
> >
> > I believe it should be:
> >
> > def is_scalar(obj):
> >'return true if *obj* is not string like and is not iterable'
> >return not is_string_like(obj) and not iterable(obj)
>
> Yep, good catch. I committed this fix to 5822
>
> JDH
--
**
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Fri, Jul 18, 2008 at 2:32 PM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > Well, yeah. I think this would mean a lot of the same code in many > backends. I also like the idea of a deeper hierarchy with a > FigureCanvasUserInterface class that inherits FigureCanvasBase but adds > functional start/stop_loop_events because it would allow for a simple > cbook test for a working user interface: > isinstance(mycanvas,FigureCanvasUserInterface) I'm not sure I see where the redundant code is coming in. In envision the base class doing nothing in start_event_loop and stop_event_loop which solves the problem for the non-UI backends, and all the UI backends will have to be specialized to deal with their own event loops. Basically, we would need to provide implementations for gtk, tk, wx and qt (and maybe qt4?) since these are the four backends that are actually maintained. Perhaps I am overly squeamish, but I am uncomfortable with a default UI implementation here anyhow. This is the paradigm we have used for the canvas draw_idle method and it has worked fine. If we get consensus on this, I think we can bang out the four methods quickly. tk requires nothing special and can be based on the current sleep implementation. I can help with gtk if need be. Paul has already done wx. qt anyone? Also, are the names stop_event_loop and stop_event_loop good choices? I find them confusing because I associate them with the UI event loop which will always be running. Something like wait_start and wait_stop is more intuitive to me. > A deeper hierarchy won't help the inheritance problem for GTKAgg though. I believe this will solve the problem, because FigureCanvasGTK is inherited first, so GTKAgg will get the specialized method. According to Guido at http://www.network-theory.co.uk/docs/pytut/MultipleInheritance.html The only rule necessary to explain the semantics is the resolution rule used for class attribute references. This is depth-first, left-to-right. Thus, if an attribute is not found in DerivedClassName, it is searched in Base1, then (recursively) in the base classes of Base1, and only if it is not found there, it is searched in Base2, and so on. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] is_scalar bug
On Wed, Jul 23, 2008 at 8:53 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > That should be an "and" not an "or" OK, I'll leave the final fix to you. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clabel improvements
On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote: > Hi, > > Well, I now know more than I ever wanted to about clabel. I decided to > improve a bit on the inlining and ended up rewriting it. For automatic > label placement, I basically use the existing algorithm for determining > label location, but have replaced existing code for determining the > angle of rotation and the amount of the contour to take off for inlining > with new code. This new code is based on using pixel-space distances > along the contour. This allows one to (1) get nice balanced inlining > with the same amount of space on either side of the label, and (2) to > vary the amount of space you want around the label. It also should deal > better with labels located near contour edges and labels covering the > entire contour. > > Along the way, I renamed all ContourLabeler specific attributes to > something like .labelAttribute. This makes the namespace cleaner in my > mind, but might break existing user code that does things directly with > ContourLabeler attributes. Eric, do you have any sense of whether people would use this directly? Since this is a point release, I want to minimize API breakage, so at least keep the old attrs around for this cycle. Eg, in Axes I recently renamed axesPatch to simply patch as follows: # the patch draws the background of the axes. we want this to # be below the other artists; the axesPatch name is deprecated self.patch = self.axesPatch = self._gen_axes_patch() we don't have an easy way to catch deprecated usage w/o some property or getattr magic. If you want to add getter properties for the deprecated attrs which warn and point to the new, that would be ideal. > I also added a few new functions to cbook. One does simple linear > interpolation (in addition to an existing cbook function that is similar > but a bit different). Others do things with vector lengths. I also > added a function called isvector that is identical to a Matlab function > of the same name. If desired, I can move this to mlab.py, but for the > moment it is in cbook.py because most of the is? functions are there. That's fine. Is this different from "iterable" > On an aside, I noted that mlab.norm uses cut-and-paste documentation > from Matlab. Is this wise? No, please rewrite the docstring. Some of mlab was borrowed form other people's codes, and I was unaware of this. > I have tested all the changes against the existing pylab_examples and > things work fine. Nonetheless, since lots of things have been changed, > I haven't committed them for fear of interfering with the release. > Instead, I am attaching the patch set. If I get the green light, I will > commit these changes. I'll leve the final call on this to Eric, but after this I suggest we implement a feature freeze until after we get the current code tested and out. Friday is a reasonable target if others agree and we have a chance to test this for a couple of days. > Related: while I am digging around in there, now is probably the moment > for me to integrate Paul Kienzle's comments on start/stop_event_loop in > FigureCanvasBase, etc. I am not sure there is a consensus on this. I > am currently thinking that the best way to integrate this, while > minimizing repeated code, is a mixin plus a couple of new classes, > FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would > inherit the mixin and the base classes without "GUI". Interactive > backends would then inherit these. Non-interactive backends would > inherit versions that throw errors from FigureBaseCanvas. Complex, but > this assures clean inheritance. Thoughts welcome. See my response in the original thread. I'm not sure we ever reached a consensus on this one, and I'm still uncomfortable with a more complex hierarchy. I'm willing to be convince if you and Paul and Gael disagree, but I have yet to see why a flat implementation will not work here. JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clabel improvements
John Hunter wrote: > On Wed, Jul 23, 2008 at 6:21 AM, David Kaplan <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Well, I now know more than I ever wanted to about clabel. I decided to >> improve a bit on the inlining and ended up rewriting it. For automatic >> label placement, I basically use the existing algorithm for determining >> label location, but have replaced existing code for determining the >> angle of rotation and the amount of the contour to take off for inlining >> with new code. This new code is based on using pixel-space distances >> along the contour. This allows one to (1) get nice balanced inlining >> with the same amount of space on either side of the label, and (2) to >> vary the amount of space you want around the label. It also should deal >> better with labels located near contour edges and labels covering the >> entire contour. It all sounds like much-needed improvement. >> >> Along the way, I renamed all ContourLabeler specific attributes to >> something like .labelAttribute. This makes the namespace cleaner in my >> mind, but might break existing user code that does things directly with >> ContourLabeler attributes. > > Eric, do you have any sense of whether people would use this directly? I think the probability that anyone is doing this is low, but it would be nice to ask on the users mailing list. > Since this is a point release, I want to minimize API breakage, so at > least keep the old attrs around for this cycle. Eg, in Axes I > recently renamed axesPatch to simply patch as follows: > > # the patch draws the background of the axes. we want this to > # be below the other artists; the axesPatch name is deprecated > self.patch = self.axesPatch = self._gen_axes_patch() > > we don't have an easy way to catch deprecated usage w/o some property > or getattr magic. If you want to add getter properties for the > deprecated attrs which warn and point to the new, that would be ideal. In general, yes, but in this case I think it would be better to go with your simpler method above, of making duplicate names. It reduces the code clutter and the chance of introducing last-minute errors. The mailing list and API_CHANGES can be used to notify users of the upcoming deprecation. If there is an outcry, indicating wide use of the attributes, then properties can be introduced later to smooth the deprecation process. But I predict there will be hardly a peep. > > >> I also added a few new functions to cbook. One does simple linear >> interpolation (in addition to an existing cbook function that is similar >> but a bit different). Others do things with vector lengths. I also Maybe explain in the docstring or a comment why this version is needed? >> added a function called isvector that is identical to a Matlab function Maybe use try/except to return False if the test fails? If the input is a string, or None, for example? Whether to do this depends on what the use case is. >> of the same name. If desired, I can move this to mlab.py, but for the >> moment it is in cbook.py because most of the is? functions are there. > > That's fine. Is this different from "iterable" > >> On an aside, I noted that mlab.norm uses cut-and-paste documentation >> from Matlab. Is this wise? > > No, please rewrite the docstring. Some of mlab was borrowed form > other people's codes, and I was unaware of this. norm is one of the things we should not have at all; ours should be deprecated in favor of numpy.linalg.norm. It would be good to have a linear algebra guru look at this to see whether a straight substitution with deprecation warning would work, or whether there are significant differences. If something close to a substitution will work, then the docstring in mlab can be replaced with a reference to the numpy function. And then in some future release, it will all be deleted. > >> I have tested all the changes against the existing pylab_examples and >> things work fine. Nonetheless, since lots of things have been changed, >> I haven't committed them for fear of interfering with the release. >> Instead, I am attaching the patch set. If I get the green light, I will >> commit these changes. > Given the stated "release early, release often" strategy, go ahead and commit. Eric > I'll leve the final call on this to Eric, but after this I suggest we > implement a feature freeze until after we get the current code tested > and out. Friday is a reasonable target if others agree and we have a > chance to test this for a couple of days. > >> Related: while I am digging around in there, now is probably the moment >> for me to integrate Paul Kienzle's comments on start/stop_event_loop in >> FigureCanvasBase, etc. I am not sure there is a consensus on this. I >> am currently thinking that the best way to integrate this, while >> minimizing repeated code, is a mixin plus a couple of new classes, >> FigureCanvasBaseGUI and FigureCanvasGUIAgg. These
[matplotlib-devel] Gcc, Solaris and putchar() problems
On solaris with gcc-4.3.1, the macro __cplusplus is not defined to 199711L. This is a long-standing issue with solaris. This doesn't much matter on some platforms, but for matplotlib, what is happening to me is that through a series of defines and conditionals, the method putchar, as used here: ./ttconv/ttutil.cpp:void TTStreamWriter::putchar(int val) gets tokenized by the preprocessor into putc by /usr/include/iso/stdio_iso.h, here on line 350: #define putchar(x) putc((x), stdout) This only happens if __cplusplus is < 199711L. I'm avoiding this by building using the studio C compiler, but I thought I'd mention this in case it's possible to detect this during the configuration stage, and perhaps wrap with something like: #ifdef #if __cplusplus <= 199711L #undef putchar #endif #endif However, I haven't tested this yet. Has anyone else thought about this? Thanks, -Peter -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clabel improvements
John Hunter wrote: >> I have tested all the changes against the existing pylab_examples and >> things work fine. Nonetheless, since lots of things have been changed, >> I haven't committed them for fear of interfering with the release. >> Instead, I am attaching the patch set. If I get the green light, I will >> commit these changes. > > I'll leve the final call on this to Eric, but after this I suggest we > implement a feature freeze until after we get the current code tested > and out. Friday is a reasonable target if others agree and we have a > chance to test this for a couple of days. > +1 Are we going to try to get anything out after that for scipy, or is this it? I realize with Friday we're targeting Debian. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Wind Barbs
Eric Firing wrote: > Ryan May wrote: >> Ok, >> >> I've committed my wind barbs stuff in SVN. Anyone interested, go >> ahead an hammer on it. > > Very nice! > > Comments on the example, barb_demo.py: > > 1) In your third panel, you put the args after the kwargs. I had no > idea this was even legal--it's the first time I have seen it. It's > probably better to stick with conventional usage so as not to distract > the reader from the point, which is how to use the barb function. > > 2) In a similar vein, I would suggest sticking with explicit X, Y, U, V > arguments. Your (*zip(*data)) is an obfuscation. > > 3) It would be better to use non-square asymmetric arrays so as to make > it clear which point in the data array corresponds to which point on the > plot. An example with NxN arrays doesn't help illustrate the relation > between the array and the plot locations. > Ok, I checked in some changes that should address all of those, plus provide a more comprehensive demonstration of capabilities. Thanks for the feedback. I also got rid of the windows line endings (sorry). Usually not a problem, but I've had a (temporary) "opportunity" to be using windows for some development. Let me know if you see anything else. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] clabel improvements
On Wed, Jul 23, 2008 at 09:14:46AM -0500, John Hunter wrote: > > Related: while I am digging around in there, now is probably the moment > > for me to integrate Paul Kienzle's comments on start/stop_event_loop in > > FigureCanvasBase, etc. I am not sure there is a consensus on this. I > > am currently thinking that the best way to integrate this, while > > minimizing repeated code, is a mixin plus a couple of new classes, > > FigureCanvasBaseGUI and FigureCanvasGUIAgg. These new classes would > > inherit the mixin and the base classes without "GUI". Interactive > > backends would then inherit these. Non-interactive backends would > > inherit versions that throw errors from FigureBaseCanvas. Complex, but > > this assures clean inheritance. Thoughts welcome. > See my response in the original thread. I'm not sure we ever reached > a consensus on this one, and I'm still uncomfortable with a more > complex hierarchy. I'm willing to be convince if you and Paul and > Gael disagree, but I have yet to see why a flat implementation will > not work here. I actually lean on the simple side for now. If we find as we improve the event-loop related stuff that we need this, we can easily add an abstraction, but right now I don't see a big benefit. Anyhow, whoever does the work gets to decide, as usual. Gaël - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Scale independent drawing
Eric Firing wrote: Ryan May wrote: Hi, I'll continue my current flood of emails to the list. :) I'm finally getting back to my work on Skew-T plots, and I have a semi-working implementation (attached.) It runs, and as is, plots up some of the grid, with the x-value grid lines skewed 45 degrees to the right (as they should be.) The problem is as you resize the plot horizontally, some weird things happen. First, some of the lines that start overlaid end up separating as you expand the plot. The difference is between what is added using ax.plot and what is added using ax.vlines. The former adds Line2D objects while the latter adds a LineCollection which is holding path objects. I'm really not sure what's going on there. I'm not done checking it out yet, but I'm curious if anyone has any ideas off the top of their head. The second issue, which is more pressing, is when you resize vertically, the axes limits of the plot don't change (good), but unfortunately the lines don't stay connected to their lower y-coordinate in data space (bad). I'm really needing to draw things in a coordinate system that's independant of the data scale but also doesn't depend on the aspect ratio of the axes, so that I can get lines (and data plots) where the x gridlines are always at a 45 degree angle and the lower Y-value point stays fixed. By problem right now is that while I can find the lower left corner in pixel space and use that to do the proper adjustments, this changes when you resize. This changing is especially important in the y-direction. What I need is either of: 1) Axes space adjusted for aspect ratio (and updated with resizes) 2) Pixel space relative to some corner of the axes Or something similar that I don't know about. Any thoughts, or do I just need to come up with some magical combination of transforms that works? You can see what I have so far in my attached file. Ryan, based only on your description of the problems, and of what you need, I think the answer, or at least part of it, may be in good old quiver. Look at the way the transform is being generated depending on the units chosen, and note that preserving a specified angle on the page is part of it. Also note that the transform has to be regenerated on resize events, so a custom draw method is required. Ok, I've attached code that works for my purpose. It includes text data so that you can see what the plot is supposed to look like. It turned out to be rather simple once I figured out exactly what needed to happen and how the matplotlib API stacked up. As noted in the file, I still have much to do, like add proper gridlines and somehow fix the nastiness when you try to pan or zoom. I now at least have a plot that gives me what I want and resizes correctly (the fact that it looks weird to my meteorologist eyes when resized is a consequence of the transform's dependence on data ranges and physical size of the plot). I ended up going with an approach that just overrides draw to call a function to update the Axes.transData attribute. I also set transData to be a transformWrapper() so that any objects that grab the transform will have access the the updated transform when a resize occurs. BIG THANKS to Mike for creating such an awesome transform framework. Once you get the hang of the coordinate systems and know what's actually possible, it's *extremely* powerful. Now my bigger question is where the heck to put what I have when I'm finished... Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma from matplotlib.axes import Axes from matplotlib.path import Path from matplotlib.lines import Line2D from matplotlib.ticker import Formatter, Locator, NullLocator, FixedLocator, \ NullFormatter, AutoLocator, ScalarFormatter from matplotlib import transforms from matplotlib.projections import register_projection import numpy as np #TODO: # *Panning and zooming are horribly broken, probably because the #skewed data are used as bounds. Needs to be disabled (especially panning) #or updated to work sensibly # *Gridlines for the x-axis need to be redone to use the skewed ones # *New functions/methods needed to add the various significant lines: # -Water vapor mixing ratio # -Dry adiabats # -Moist adiabats #Will these work as new kinds of gridlines? class SkewXAxes(Axes): # The projection must specify a name. This will be used be the # user to select the projection, i.e. ``subplot(111, # projection='skewx')``. name = 'skewx' def draw(self, *args): ''' draw() is overridden here to allow the data transform to be updated before calling the Axes.draw() method. This allows resizes to be properly handled without registering callbacks. The amount of work done here is kept to a minimum. ''' self._update_data_transform() Axes.
Re: [matplotlib-devel] Wind Barbs Full Patch
John Hunter wrote: > On Sat, Jul 19, 2008 at 11:09 PM, Ryan May <[EMAIL PROTECTED]> wrote: > >> The only issue I've seen is that scaling with PS is way too big. I've >> attached ps and pdf files from the same run to show the problem. > > The only thing I can think of is since you are using a identity > transform and drawing in pixels, you are seeing the effect of the > savefig dpi in pdf and png but not in ps, which hardcodes the dpi to > 72. If this is correct, you should not see the effect if you pass > dpi=72 to savefig when saving the PS and PDF. You will probably want > to modify the patch to make sure your barbs scales are dpi > independent. I have only looked briefly at the barbs code so I could > be missing something obvious, but this is the first thing that comes > to mind. Ok, it fixes the problem if I pass dpi=72 to savefig(). Curiously, passing dpi=72 to Figure() does not have the same effect. So now how do I fix it? I'm really not sure what's going wrong here. If I had to guess, it's a problem between figure size being in inches while I'm drawing in pixels (still don't know how that works, because there's no way those barbs are 9 pixels long). Ideas? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
