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.
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'
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
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
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
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
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=
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 i
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
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
th
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 Quan
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 g
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
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 look
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 ne
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
16 matches
Mail list logo
