[matplotlib-devel] preparing for trunk release
Now that we (finally!) got the bug fix release out for 0.98.5.3, which I am hoping will be the last, I'd like to turn our attention to a trunk release, which is where all the good stuff is, including the new axes grid and mplot3d toolkits. In advance of this, I suggest you commit any pending work you'd like to see in the release, and try to tackle any pending sf bug reports or patches (and file a bug report if you know of an issue that needs to be addressed). In a week or so, I'll ask Michael to create a release branch from HEAD at which point the 98.5 branch will die and the release branch will become the new stable branch to which we apply only bugfixes and not new features. We'll do a release candidate from the branch, and then a release, in perhaps two weeks time. Thanks, JDH -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Updating Circle.radius has no effect (+minor example fix)
I'm animating a Circle patch with a varying center and radius, and I noticed that changing the ``radius`` attribute has no effect on the patch. Currently, ``radius`` is only used to instantiate an Ellipse object, but updating radius has no effect (i.e. redrawing the patch doesn't use the new radius). I've included a patch to add this feature. Also included in the patch is a small fix to one of the UI examples (sorry for included a completely unrelated patch but the fix seemed to small for a separate email). BTW, I'm using a property idiom from: http://code.activestate.com/recipes/205183/ . I thought that this approach was better than polluting the namespace with getters and setters, especially since this would differ from the way the Ellipse class uses ``width`` and ``height`` attributes. Cheers, -Tony === --- lib/matplotlib/patches.py (revision 7128) +++ lib/matplotlib/patches.py (working copy) @@ -1131,6 +1131,14 @@ self.radius = radius Ellipse.__init__(self, xy, radius*2, radius*2, **kwargs) __init__.__doc__ = cbook.dedent(__init__.__doc__) % artist.kwdocd + +def radius(): +def fget(self): +return self.width / 2. +def fset(self, radius): +self.width = self.height = 2 * radius +return locals() +radius = property(**radius()) class Arc(Ellipse): """ Index: examples/user_interfaces/embedding_in_wx3.py === --- examples/user_interfaces/embedding_in_wx3.py(revision 7128) +++ examples/user_interfaces/embedding_in_wx3.py(working copy) @@ -147,7 +147,7 @@ return True def OnBang(self,event): -bang_count = XRCCTRL(self.frame,"bang_count") +bang_count = xrc.XRCCTRL(self.frame,"bang_count") bangs = bang_count.GetValue() bangs = int(bangs)+1 bang_count.SetValue(str(bangs)) -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
John Hunter wrote:
> wrote:
>> If it's going to be done, I think it really shouldn't be too MPL
>> specific -- it should be built on a good (and hopefully eventually
>> widely used) unit-array system, perhaps like Darren Dale's Quantities
>> package (there are quite a few other that should be looked at also).
>
> This is not how it works -- we will not be assuming any units package.
> Rather, we provide an interface where any units package can be used
> with mpl.
Fair enough, but you still need to require a particular API to a unit-ed
object, which it no so different.
One thing that strikes me is that there is a distinctive difference
between something like Darren's Quantities (and other numpy-based
packages) and what MPL no supports for DateTimes -- in Quantities, the
sequence itself has units, whereas with Datetimes, you use a generic
sequence, and each element has units. I suppose that difference can be
dealt with in the API, though.
> The original use case is that the JPL has an internal units
> package and they want to pass their objects directly to mpl
But, of course, the rest of us probably don't want to (or can't) use
JPL's package, so we'll want a more generic package to test with and
write samples for, etc.
In general, I think it's next to impossible to write a generic API
without AT LEAST two use cases -- so maybe JPL's and Quantities would be
a good start.
> One nice thing about this is we were able to extend support to native
> datetime objects (which we cannot modify obviously) to mpl, so this
> facility works with both proper unit types as well as arbitrary types.
And I have enjoyed the DateTime support (except when it's not there,
natch!). In thinking about this more, I think the real benefit is in the
coupling with the units support with nifty things like AutoLocaters and
AutoFormatters -- these are great for DateTimes, and my first thought
was "who cares" for simpler units like meters. However, in thinking, I
realize that I've written a fair bit of code for my data that may be in
meters, for instance, that goes like:
if max < 1:
do_stuff_to display_centimeters.
elif max < 1000:
do_stuff_to display_meters.
else:
do_stuff_to display_kilometers.
It would be nice to push that stuff into an MPL locater and formatter,
even if I do need to write them myself. And, ideally between us all, a
nice collection of generic ones could be written.
I could (and now that I think about it, will) still do that by simply
assuring my data are always in a particular unit, but it would be nicer
if the locaters could be unit aware, so that one could pass in any
length unit, and apply a "SI_length_Formatter" to it. Or just
SI_Formatter, now that I think about it.
I'm not sure how to resolve one issue:
If I have a locator/formatter that decides whether to display cm or km,
etc, depending on values, I probably want the axis label to reflect that
too, but I don't know how one can get all those to communicate.
Also, it sounds like you're talking about converting units to the same
something -- but, for length, it might be feet, or miles, or cm, or
This is a bit different than what is done for time, where datetimes are
always converted to the same base -- days since 0001-01-01 00:00:00.
Perhaps this convention could be followed with a standard base unit for
length, etc. though maybe that wouldn't capture the range of precisions
that may be required -- some data in centuries, some in nanoseconds...
(by the way, there was some work on handling datetimes with numpy arrays
a while back -- I wonder what came of that?)
> I'm open to the idea of not supporting post-facto conversions after
> data is added, but am mostly minus one on it, and I'd like to hear
> from the JPL who requested the ability initially. I think their users
> are working with complex plots and might have arrays in different
> distance units, and would like to be able to pass in any distance
> units as long as conversion is possible.
I can see that, but suggest that the unit finally displayed by the plot
be specified by an axis method, or Locators or Formatters, or ??, but in
any case, not change depending on what order you add data to the plot.
It would be pretty cool to be able to do:
ax.plot(x, data_in_feet)
ax.plot(x, data_in_meters)
and get it all scaled right!
> there is little difference between the code
> you suggest::
>
> ax.plot(values.rescale('cm'))
> ax.set_xlim(limits.rescale('cm'))
>
> and::
>
> ax.plot(values.rescale('cm').tofloat())
> ax.set_xlim(limits.rescale('cm').tofloat())
>
> where the latter means we have no units or custom type support.
there are a couple differences:
1) with date2num, we still always use float-days- since-epoc for the
actual numbers. That means that there can be one set of formatters. In
that example, what units would tofloat() return? If we want formatter to
work, some info about the units needs to be passed into mpl.
2) in t
Re: [matplotlib-devel] Units issue
Er... Anybody has tried the plotting capacities of scikits.timeseries (pytseries.sourceforge.net)? In short, the package provides some extensions to matplotlib to plot timeseries. One of these extensions changes the ticks depending on the zoom level: start over a few decades and ticks will be every 5 y or so. Select a smaller area and the ticks will be every quarter, you get the idea. The series associated with the plot (either the first plotted or one given at plot creation) sets the units (frequency) of the xaxis. Afterwards, other series plotted on the same plot are converted to the plot's frequency) with our own conversion routines. Theses extensions were coded about 18 months ago, at a time where the support for units was inexistent (or hidden somewhere I never fund it). A couple weeks ago I realized that units converting would probably be the way to go (and that in general, our extensions should be rewritten). Anyway, the zoom-level dependent ticks we implemented might be a good starting point for implementing a "locator/formatter that decides whether to display cm or km"... I'd be quite happy to get some feedback about these extensions... Cheers P. -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On 2009-05-21 14:55, Pierre GM wrote: > Anyway, the zoom-level dependent ticks we implemented might be a good > starting point for implementing a "locator/formatter that decides > whether to display cm or km"... Well, if we're pushing products, Chaco has a subsystem for doing exactly this in a generic fashion for times or anything else: https://svn.enthought.com/svn/enthought/Chaco/trunk/enthought/chaco/scales/ It was written to be self-contained so that it could be shared with matplotlib or anything else that need it. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
On Thu, May 21, 2009 at 2:20 PM, Christopher Barker wrote: > John Hunter wrote: >> wrote: >>> If it's going to be done, I think it really shouldn't be too MPL >>> specific -- it should be built on a good (and hopefully eventually >>> widely used) unit-array system, perhaps like Darren Dale's Quantities >>> package (there are quite a few other that should be looked at also). >> >> This is not how it works -- we will not be assuming any units package. >> Rather, we provide an interface where any units package can be used >> with mpl. > > Fair enough, but you still need to require a particular API to a unit-ed > object, which it no so different. No, this is incorrect. The object can have any API it wants. The person who wants to add support for that object registers the object type with a converter class for that object. The converter class can be entirely external to the class, as in the datetime example I posted, so the object's API is not exposed to mpl. This is the crucial distinction. The converter class at a minimum must know how to convert the object to a sequence of floats. JDH JDH -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
There seems to be some confusion as to how the mpl unit system works, I hope the following will help to clarify that and keep this thread focused on the issue. Currently mpl provides an API via the 'ConversionInterface' class in 'matplotlb.units' that allows a user to define how to translate their data into something meaningful for mpl to process (i.e. floats). If you are already passing around floats, then this interface is not for you. This interface is for typed data that is to be plotted (i.e. it needs to be "manipulated" to convert it to a float). This manipulation is handled via the user-defined and registered ConversionInterface sub-class. The idea is not that a user will do the following: >>> ax.plot( cms ) >>> ax.plot( inches ) As that would imply that the user has already converted their data to floats. But that the user will this intead: >>> ax.plot( length_data1 ) >>> ax.plot( length_data2 ) Where the length_dataX is some user-defined data type and a user-defined conversion class has been pre-registered. mpl will choose the default units based upon what the user-defined conversion class says the default should be. But if a more explicit specification is required, then the user does the following instead: >>> ax.plot( length_data1, xunits="cm" ) >>> ax.plot( length_data2 ) This would plot the length data in centimeters. If desired then the user can do the following: >>> ax.xaxis.set_units( "cm" ) And the plot would be updated. The following also currently works: >>> ax.plot( length_data1, xunits="cm" ) >>> ax.plot( length_data2, xunits="inches" ) And the final plot would be in inches. The current mpl interface for units is quite robust and supports a very generic interface that is highly user-customizable (should the user want to do so). The interface is so robust that I defined a simple converter class that will "convert" strings to floats. I use this with bar plots and do something like the following: >>> ax.bar( ["a", "b', "c"], [1, 2, 3] ) An example can be seen in the matplotlib 'test/mplTest/units/StrConverter.py' file. Additionally other unit example classes can be found in the 'test/mplTest/units' directory. The issue is, as John has already stated with the individual plot functions. 'ax.plot' works perfectly fine due to the way the line data is cached and updated as needed (the updates take into account if units might have changed). Some individual plot functions strip out the units then manipulate the data, and others keep the unitized data and pass it along to be stripped out later. The issue is getting a consistent mechanism for dealing with where the conversion is to occur. I think that John's proposal of having higher level classes that handle this (as well as the caching) might be the way to go. It would allow the individual plot functions to stay simplistic and true to what they provide and let the data handle itself. This type of mechanism promises to be faster since the data only needs to be converted once (in the typical use case). Overhead of re-converting would only occur when the user explicitly changes the units for a specified axis. Additionally this approach looks to be more appealing when it comes to making plottable data items that are selectable and ultimately manipulatable via a gui interface. --James Evans -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] attempting to enable buildbot
The tests now seem to be running OK. There are some failures due to image comparison mismatch, but I think we should attempt to track these down as a team -- hopefully running on more computers than just mine and with James' input. To see the latest test results, click on the "stdio" link for each run of the "test" box in the waterfall display http://mpl-buildbot.code.astraw.com/waterfall . It would be nice if the buildbot web GUI would easily let us see, for failed image-based tests, the baseline, output, and difference image, but that's not implemented (as far as I know). It would probably be possible to add something like this to the MplNosePlugin to do this with relatively little pain, although the display would be easiest via a pastebin or something rather than hooking back into a patched buildbot framework that supported test images. John Hunter wrote: > On Wed, May 20, 2009 at 3:48 AM, Andrew Straw wrote: > >> Let's see if we can get all the tests passing and if this buildbot >> approach looks sustainable -- if so, I'd like to get some more build >> slaves into the mix and make MPL a good continuous integration citizen. >> I don't think the buildbot master will take many resources on my server, > > The sage project has given us access to a network accessible > persistent OSX box, so I will try and get that setup with the buildbot > infrastructure. I'm not yet familiar with the buildbot project or > approach, so I have some learning to do, so if you have a cheatsheet > or docs thaty you think are particularly handy, send them along > (otherwise I'll just make my way through the site docs) OK, here's what you do:: # (Make a username you want to run this buildslave as. # Become that user. Change into a new directory e.g. $HOME/builbot) curl http://astraw.com/mpl/bootstrap-py.txt > bootstrap.py curl http://astraw.com/mpl/buildout-example.cfg > buildout.cfg # Edit buildout.cfg according the instructions in the file. Send me # the values you added. # python bootstrap.py # bin/buildout Once you've been added to the build master: # bin/ start And that should be it. For now we can start/stop builds by clicking the "force build" button in the buildmaster web GUI. SVN polling doesn't seem to be working yet... I'll look into that when I have time. Ditto for building binaries and uploading them somewhere. -Andrew -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] dropped spine support
Andrew Straw wrote: > I've implemented initial support for "dropped spines". This is motivated > by the ability to draw figures that look like > http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm > attaching the patches and an image created by the new example. > > This is a somewhat invasive change into the core of the axis rendering > code, so I'm hereby requesting a review before committing it into the > code base. In particular, I dropped the idea of using Traits in MPL not > because I think it's a bad idea, but because that would involve more > substantial changes. > > Anyhow, I'm attaching the proposed implementation as a series of > patches. If the general form of this looks OK, I'd write up doc strings > and a CHANGELOG entry and commit it. Should I wait until after the trunk > release? > > Please let me know what you think. All the examples run with > exaples/tests/backend_driver.py still seem to give OK results, and the > test suite raises a few more failures, but these appear due to > (sub)pixel shifts in text rendering rather than anything more severe. > > -Andrew Andrew, It looks like that nicely addresses a frequent request. Great! I haven't looked closely enough yet to see how it all works, but one immediate suggestion is that the adjust_spines function in your example looks like something that should be modified a bit and turned into an axes method with the usual pyplot wrapper. That is a fine point, of course, that can be deferred. It looks like the offset is defined as positive outward from center of the plot. Are negative values allowed, so the spine goes through the middle of the plot, for example? The name "spine" threw me off for a while; but I guess that is a reasonable description for a line with ticks. "Axis" and "Scale" are already taken, so maybe "spine" is as good as we can find. "Dropped spine" sounds like a painful medical condition... Oh, well... Eric -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] radial grids broken on polar?
When plotting the polar demo, I am not getting radial grids on the
trunk (but I am getting them on the branch). Any ideas?
import matplotlib
import numpy as np
from matplotlib.pyplot import figure, show, rc, grid
# radar green, solid grid lines
rc('grid', color='#316931', linewidth=1, linestyle='-')
rc('xtick', labelsize=15)
rc('ytick', labelsize=15)
# force square figure and square axes looks better for polar, IMO
width, height = matplotlib.rcParams['figure.figsize']
size = min(width, height)
# make a square figure
fig = figure(figsize=(size, size))
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
r = np.arange(0, 3.0, 0.01)
theta = 2*np.pi*r
ax.plot(theta, r, color='#ee8d18', lw=3)
ax.set_rmax(2.0)
ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
ax.grid(True)
ax.set_title("And there was much rejoicing!", fontsize=20)
show()
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] dropped spine support
On Thu, May 21, 2009 at 7:47 PM, Eric Firing wrote: > Andrew Straw wrote: >> I've implemented initial support for "dropped spines". This is motivated >> by the ability to draw figures that look like >> http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm >> attaching the patches and an image created by the new example. > It looks like that nicely addresses a frequent request. Great! I > haven't looked closely enough yet to see how it all works, but one > immediate suggestion is that the adjust_spines function in your example > looks like something that should be modified a bit and turned into an > axes method with the usual pyplot wrapper. That is a fine point, of > course, that can be deferred. > > It looks like the offset is defined as positive outward from center of > the plot. Are negative values allowed, so the spine goes through the > middle of the plot, for example? Hey Andrew -- this is really excellent. The lack of support for spine placement is one of the things that has been mentally holding me back from releasing mpl as 1.0, so by all means commit it. I did read through the patch, and it looks like a clean implementation so I don't have any specific suggestions. I would like to see a 'xcenter'or 'ycenter' (or whatver name works best) option in addition to the 'left', 'right', 'top' and 'bottom' so we can easily support things like Mathematica/Sage style spines http://webscripts.softpedia.com/scriptScreenshots/SAGE-Screenshots-27855.html Do you think you could add this fairly easily? Also, it would be nice to have some simple configuration options, perhaps a few default themes, so one could easily switch between them, and probably rc support for a default theme. The theme might specify both the spine placement as well as the tick in/out/center placement. None of this needs to go in ahead of the initial commit though. Thanks! JDH -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] radial grids broken on polar?
John Hunter wrote: > When plotting the polar demo, I am not getting radial grids on the > trunk (but I am getting them on the branch). Any ideas? git bisect let me narrow it down to r7100 in a few minutes. (I'm back to using git to interact with MPL svn again. Just don't ask me to deal with the svn branches! :) Author: efiring Date: Wed May 13 19:59:16 2009 + Experimental clipping of Line _transformed_path to speed zoom and pan. This can be modified to work with x monotonically decreasing, but for a first try it works only with x monotonically increasing. The intention is to greatly speed up zooming and panning into a small segment of a very long time series (e.g., 10^6 points) without incurring any significant speed penalty in other situations. git bisect start # bad: [e4c9c46ab1909c05323da28c057c8d64fc6d44a8] add example of dropped spines git bisect bad e4c9c46ab1909c05323da28c057c8d64fc6d44a8 # good: [bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da] removed extraneous savefig calls from examples git bisect good bdf5bb3116a6d58d49b0d7a98e8dab5d9dacd1da # bad: [f36409e021d030fa22515d4d9362a2c657e3df3e] applied Michiel's sf patch 2792742 to speed up Cairo and macosx collections git bisect bad f36409e021d030fa22515d4d9362a2c657e3df3e # good: [6d21b5b655f045d9edf759037e3a67ca51f89d08] updates to doc git bisect good 6d21b5b655f045d9edf759037e3a67ca51f89d08 # bad: [d7a5aecdbf274227e98ad4ac4257435d2e37156d] Fixed bugs in quiver affecting angles passed in as a sequence git bisect bad d7a5aecdbf274227e98ad4ac4257435d2e37156d # bad: [736a4f9804e01d0d5b738f869444709496e34c56] psfrag in backend_ps now uses baseline-alignment when preview.sty is used git bisect bad 736a4f9804e01d0d5b738f869444709496e34c56 # bad: [86e1487f9718db26c86867a2711aac5410bd828d] Experimental clipping of Line _transformed_path to speed zoom and pan. git bisect bad 86e1487f9718db26c86867a2711aac5410bd828d -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] radial grids broken on polar?
Andrew Straw wrote: > John Hunter wrote: >> When plotting the polar demo, I am not getting radial grids on the >> trunk (but I am getting them on the branch). Any ideas? > > git bisect let me narrow it down to r7100 in a few minutes. (I'm back to > using git to interact with MPL svn again. Just don't ask me to deal > with the svn branches! :) Hmm, it seems my git mirror of the svn repo is bad... For some reason git thinks r7100 comes after r6550, so there are a few commits in there that seem to have been lumped with r7100! Oh, wait, now I remember doing "git svn fetch -r 7100:HEAD" at some point. I'll have to remedy this... -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] dropped spine support
I just had a quick at the patch and it looks good. I have two minor issues. 1) API change in Axes.get_xaxis_transform & get_yaxis_transform. The default keyword argument which=None raises an exception. Maybe you meant which="grid"? 2) Axes.frame Is it okay to simply drop this attribute? Any code that access this attribute will raise an exception. For example, some of my code in mpl_toolkits.axes_grid access this attribute, although a fix would be very trivial. Regards, -JJ On Thu, May 21, 2009 at 8:06 PM, Andrew Straw wrote: > I've implemented initial support for "dropped spines". This is motivated > by the ability to draw figures that look like > http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm > attaching the patches and an image created by the new example. > > This is a somewhat invasive change into the core of the axis rendering > code, so I'm hereby requesting a review before committing it into the > code base. In particular, I dropped the idea of using Traits in MPL not > because I think it's a bad idea, but because that would involve more > substantial changes. > > Anyhow, I'm attaching the proposed implementation as a series of > patches. If the general form of this looks OK, I'd write up doc strings > and a CHANGELOG entry and commit it. Should I wait until after the trunk > release? > > Please let me know what you think. All the examples run with > exaples/tests/backend_driver.py still seem to give OK results, and the > test suite raises a few more failures, but these appear due to > (sub)pixel shifts in text rendering rather than anything more severe. > > -Andrew > > -- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] radial grids broken on polar?
The default resolution (which is used to interpolate a path in polar
coordinate) has change to 1 at some point. And because of this, a
radial grid becomes a 0-length line. Increasing the resolution will
bring back your gridlines.
ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
resolution=100)
-JJ
On Thu, May 21, 2009 at 10:13 PM, John Hunter wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch). Any ideas?
>
> import matplotlib
> import numpy as np
> from matplotlib.pyplot import figure, show, rc, grid
>
> # radar green, solid grid lines
> rc('grid', color='#316931', linewidth=1, linestyle='-')
> rc('xtick', labelsize=15)
> rc('ytick', labelsize=15)
>
> # force square figure and square axes looks better for polar, IMO
> width, height = matplotlib.rcParams['figure.figsize']
> size = min(width, height)
> # make a square figure
> fig = figure(figsize=(size, size))
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>
> r = np.arange(0, 3.0, 0.01)
> theta = 2*np.pi*r
> ax.plot(theta, r, color='#ee8d18', lw=3)
> ax.set_rmax(2.0)
>
> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
> ax.grid(True)
>
> ax.set_title("And there was much rejoicing!", fontsize=20)
> show()
>
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] radial grids broken on polar?
Jae-Joon Lee wrote:
> The default resolution (which is used to interpolate a path in polar
> coordinate) has change to 1 at some point. And because of this, a
> radial grid becomes a 0-length line. Increasing the resolution will
> bring back your gridlines.
This is not the right solution, though. There was a reason for the
change in default resolution to 1--it gives the expected behavior for
plotting a line between two points in polar coordinates--and it is not
going back. The inability to set resolution on a per-artist basis is a
serious problem that doesn't seem to have a simple solution. Until one
can be found, some sort of special case handling will be needed for the
radial grid lines.
Eric
>
> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c',
> resolution=100)
>
> -JJ
>
>
>
> On Thu, May 21, 2009 at 10:13 PM, John Hunter wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch). Any ideas?
>>
>> import matplotlib
>> import numpy as np
>> from matplotlib.pyplot import figure, show, rc, grid
>>
>> # radar green, solid grid lines
>> rc('grid', color='#316931', linewidth=1, linestyle='-')
>> rc('xtick', labelsize=15)
>> rc('ytick', labelsize=15)
>>
>> # force square figure and square axes looks better for polar, IMO
>> width, height = matplotlib.rcParams['figure.figsize']
>> size = min(width, height)
>> # make a square figure
>> fig = figure(figsize=(size, size))
>> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>>
>> r = np.arange(0, 3.0, 0.01)
>> theta = 2*np.pi*r
>> ax.plot(theta, r, color='#ee8d18', lw=3)
>> ax.set_rmax(2.0)
>>
>> ax.set_rgrids(np.arange(0.5, 2.0, 0.5))
>> ax.grid(True)
>>
>> ax.set_title("And there was much rejoicing!", fontsize=20)
>> show()
>>
>> --
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
