Jeff, I agree with John's comments.
> Based on a look at the code, but no testing, it looks like
> your patch is well along the way. I don't have anything
> ready to merge with it now, but I think I could work on it a
> bit this weekend, if that would help.
> One thing I would look at is the handling of the color
> spacing and the ticks and tick labelling. Allowing linear
> spacing is a good idea, but we may need more than a single
> binary kwarg: either two kwargs, or one with string
> arguments to allow more choice. Specifically, in my
> experience, it is often useful to give clevels like this:
> [-100] + frange(-5, 5) + [100]. The middle range may or may
> not be linear, but the two end points have arbitrary very
> large absolute values to ensure they will catch the extremes
One suggestions, instead of a linear_spacing kwarg, have something
neutral like "ticks". If ticks is a string like "linearq"
create the ticks accordingly. If it is a sequence, assume it is the
tick locations, eg [-100, -5, -4, ..., 4, 5, 100]. If it is
callable, call it (the latter would support matplotlib.ticker.Locator
instances as well as user functions)
if is_string_like(ticks):
if ticks == 'linear':
theticks = do_something()
elif ticks == 'log':
theticks = do_something_else()
else:
raise ValueError("ticks must be log|linear'")
elif iterable(ticks):
theticks = ticks
elif callable(ticks):
theticks = ticks()
else:
raise TypeError("ticks must be a string, a sequence, or callable")
> in the dataset. This is also the case for which Phil is
> requesting triangles at the ends, I think. In my Matlab
> code, I don't bother drawing triangles (which have a certain
> logic and appeal, but would make the colorbar code
> substantially more complicated); instead I simply make the
> first and last color patch have the length of the average of
The triangles per-se aren't too hard. Here is an example showing how
to draw them. I haven't used these before so I don't know how to set
their color, but perhaps one of you could plug this in. This would
also have to be adapted to support horizontal colorbars too
from matplotlib.patches import Polygon
import matplotlib.numerix as nx
from pylab import figure, show
fig = figure()
ax = fig.add_subplot(111)
im = ax.imshow(nx.mlab.rand(20,20))
cax = fig.colorbar(im)
l,b,w,h = cax.get_position()
t = b+h
r = l+w
midx = l+w/2.
upper = (l,t), (midx, t+w), (r,t)
lower = (l,b), (midx, b-w), (r,b)
pupper = Polygon(upper, fc='red', ec='k', lw=0.5,
transform=fig.transFigure)
plower = Polygon(lower, fc='blue', ec='k', lw=0.5,
transform=fig.transFigure)
fig.patches.append(pupper)
fig.patches.append(plower)
show()
> their immediate neighbors. Then I don't put a tick or label
> at the ends of the colorbar, but instead start and end at
> the second and next-to-last clev.
> Another aspect I customized for Matlab, and would like to do
> for mpl, is in selecting the size and shape of the colorbar.
> To my eye, plots look much nicer, and are just as
> functional, with colorbars smaller in both dimensions than
> the present default. Any possible change in this aspect,
> however, would be independent of your changes to support
> discrete colorbars, and would probably best be left for a
> separate patch.
Are you aware that the cax arg to colorbar lets you specify the
axes for the colorbar?
JDH