contourf problem

Using contourf in version 0.99.1,
I'm seeing an unwanted white strip to
the top and right, adjacent to the axes.
(In fact, the strip looks just wide
enough to underlay the ticks.)

Alan Isaac

PS Simple example:

x = np.linspace(-5, 5, 100)
X, Y = np.meshgrid(x, x)
Z = np.sin(x*y[:,None])
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.contourf(Z)

Well, in your simple example you're not even using the X and Y you
calculate to give the spatial dimensions of your data,
so it's just using indices, which run from 0 to 99. Since the limits
are 0 to 100, bam...white space because, indeed, there is no data.

If I do the following example, I don't get any whitespace:

x = np.linspace(-5, 5, 100)
X, Y = np.meshgrid(x, x)
Z = np.sin(x*x[:,None]) #Note change from bug in previous ex.
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.contourf(X, Y, Z)
ax.set_xlim(-5, 5)
ax.set_ylim(-5, 5)
plt.draw()

Is there something I'm missing? (Running SVN trunk here)

Ryan

···

On Sun, Mar 28, 2010 at 11:16 AM, Alan G Isaac <alan.isaac@...287...> wrote:

Using contourf in version 0.99.1,
I'm seeing an unwanted white strip to
the top and right, adjacent to the axes.
(In fact, the strip looks just wide
enough to underlay the ticks.)

Alan Isaac

PS Simple example:

x = np.linspace(-5, 5, 100)
X, Y = np.meshgrid(x, x)
Z = np.sin(x*y[:,None])
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.contourf(Z)

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

OK, it's obvious one you point it out.
Sorry for the typo in the example.

Now suppose I want a colorbar labelled at -1, 0, 1
but the highest value realized is <1. Can I somehow
use ticks=(-1,0,1) anyway, or do I have to tick at
the realized limits and then label "falsely". Here's an
example, hopefully without typos this time.

x = np.linspace(-5, 5, 101)
y = x
Z = np.sin(x*y[:,None]).clip(-1,1-1E-6)
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
cax = ax.imshow(Z, interpolation='nearest', extent=[-5,5,-5,5])
cbar = fig.colorbar(cax, ticks=(-1, 0, 1))

As you see, the top tick is not labelled.

Thanks,
Alan

···

On 3/28/2010 3:04 PM, Ryan May wrote:

it's just using indices, which run from 0 to 99. Since the limits
are 0 to 100, bam...white space because, indeed, there is no data.

2010/3/29 Alan G Isaac <alan.isaac@...287...>:

OK, it's obvious one you point it out.
Sorry for the typo in the example.

Now suppose I want a colorbar labelled at -1, 0, 1
but the highest value realized is <1. Can I somehow
use ticks=(-1,0,1) anyway, or do I have to tick at
the realized limits and then label "falsely". Here's an
example, hopefully without typos this time.

x = np.linspace(-5, 5, 101)
y = x
Z = np.sin(x*y[:,None]).clip(-1,1-1E-6)
fig = plt.figure()
ax = fig.add_subplot(1,1,1)
cax = ax.imshow(Z, interpolation='nearest', extent=[-5,5,-5,5])
cbar = fig.colorbar(cax, ticks=(-1, 0, 1))

As you see, the top tick is not labelled.

On my machine, it /labels/ the +1.0, so I changed the mismatch to the
safe-failing (1 - 0.1) value, in the script attached. Also I fixed
your problem, hopefully.

Friedrich

norm.py (390 Bytes)

Can you explain this:
norm = colors.Normalize(vmin = -1, vmax = 1)

I take it that this scales the range for the
color bar, which is what 'luminance' must
refer to in the docs? In which case, can
we just set vmin and vmax as imshow keywords?
    patch = ax.imshow(Z, interpolation='nearest', extent=[-5,5,-5,5], vmin = -1, vmax = 1)
(Seems to work.)

Thanks!
Alan

···

On 3/28/2010 7:19 PM, Friedrich Romstedt wrote:

I fixed your problem

2010/3/29 Alan G Isaac <alan.isaac@...287...>:

Can you explain this:
norm = colors.Normalize(vmin = -1, vmax = 1)

The normaliser takes some arbitrary value and returns a value in [0,
1]. Hence the name. The value \in [0, 1] is handed over to the
cmap's __call__(), resulting in the color value. And yes, I guess you
can use vmin and vmax directly, it's just a matter of taste.

As you can pass in also *boundaries* to Colorbar(), this may be an
alternative. It will display all red above the max value, though it's
harder to tick. When you want the highest value to be really
represented by red, not near-to-red.

Friedrich

2010/3/29 Alan G Isaac <alan.isaac@...287...>:
> Can you explain this:
> norm = colors.Normalize(vmin = -1, vmax = 1)

The normaliser takes some arbitrary value and returns a value in [0,
1]. Hence the name. The value \in [0, 1] is handed over to the
cmap's __call__(), resulting in the color value. And yes, I guess you
can use vmin and vmax directly, it's just a matter of taste.

OK, thanks!
Alan

···

On 3/28/2010 10:05 PM, Friedrich Romstedt wrote: