matplotlib-users Mailing List for matplotlib

Yannick Copin wrote:
> Hi,
> 
> in a case similar to matplotlib-0.87.7/examples/contour_demo.py (figure 
> 4), would it be possible to merge to two colorbars (a continuous one 
> from imshow, a discrete one from contour) into a single colorbar? 
> Indeed, in that case, the two colorbars are mostly redundant.
> 
> Cheers.
Yes, lines can be superimposed on a continuous colorbar. The demo is 
not ideal; I was mainly showing that one could use two colorbars for two 
different things. I have changed the contourf_demo.py in svn to include 
an example of a merged colorbar. Maybe I will change contour_demo.py 
later to make it an illustration of having colorbars for completely 
different fields, so it won't look so pointless as it does now.
Eric

Yannick Copin wrote:
> Hi,
> 
> running the simple test code:
> 
> from pylab import *
> X, Y = meshgrid(linspace(-3,3,11),linspace(-3,3,11))
> Z = randn(*X.shape)
> lev = linspace(Z.min(),Z.max(),11)[1:-1]
> contourf(X,Y,Z, lev, extend='both')
> contour(X,Y,Z, lev, colors='k')
> show()
> 
> you will probably notice that the 'contourf' contours are not always 
> exactly the sames as the 'contour' contours. Why is it so? Don't contour 
> and contourf use the same contour constructor?
The same overall routine is used for contour as for contourf, but the 
contour tracing operation is not identical. Tracing a filled contour is 
much more complicated--that is probably why it is so hard to find filled 
contour routines. I suspect that whoever wrote the original code we are 
using wrote the line contour version first, then had to add quite a bit 
of logic and code to get it to make filled contours.
Now, you may be wondering why we can't simply use the boundary of the 
filled regions for the lines as well, to guarantee they are the same. 
The reason is that filled contour boundaries include cuts connecting 
inner and outer contours, and also inner boundaries (edges of masked 
regions--except when affected by a bug) and the outer boundaries of the 
domain). It might be possible to simply exclude those line segments 
from the line contours, but it is not clear to me that the effort would 
be well-spent.
I think that the differences illustrated in your example will occur 
almost entirely in pathologically ambiguous cases, but it is also 
possible that they reflect actual bugs or shortcomings of the algorithms 
used. Understanding the logic and tracing the code path in the present 
cntr.c is difficult; I have tried but failed to figure out and correct 
the interior masked region bug in contourf. If a better core contour 
routine with a suitable license could be found and substituted for the 
present one, that would be very nice. I have searched many times 
without turning anything up.
Eric

In past work I have not been able to get clipping to behave as I expected.
Today I was trying to understand how to add a right-axis label and was using
an example from the matplotlib site that set clip_on=False. It did not
work. In looking at the code in method text() it appears that it checks for
the existance of clip_on and not the value. So clip_on=False results in
clipping but not specifying clip_on does not. Is this understanding correct
and is it the intended behavior? If so, I can't see how the example could
have worked.
Also is there a standard, easy way to get a 2nd (right) axis label and ticks
or does it have to be done manually? I found only the one example on the
screenshots page where it is done with several text() method calls.
-- David

>>>>> "Martin" == Martin Richter <law...@gm...> writes:
 Martin> My question now is: Is there a way to avoid using global
 Martin> variables but also avoid an object-oriented programming?
 Martin> In other words: Is it possible to pass e.g. a dictionary
 Martin> containing some information to the function called by the
 Martin> event? The reason for not wanting the object-oriented way
 Martin> is: We want to teach something to students who never
 Martin> programmed before. And to them it would be pretty hard if
 Martin> we start everything object-oriented!
The can use attrs on the function
def two_parts(event):
 if event.button == 3:
 two_parts.program_part = two_parts.program_part%2 + 1
 print " Changed to part to ", program_part
 if two_parts.program_part == 1 and event.button == 1:
 plot([event.xdata], [event.ydata], marker = 'o', mfc = 'r')
 if two_parts.program_part == 2 and event.button == 1:
 plot([event.xdata], [event.ydata], marker = 's', mfc = 'g')
 draw()
two_parts.program_part = 1
which would introduce them to attributes and pave the way to thinking
about OO.
JDH

Hello everyone,
below is a little code - what it actually does is quite self-explanatory.
(When clicking with left - draw a red circle. When the right button is pressed 
switch to a different mode. Now green squares are drawn and so on.)
My question now is: Is there a way to avoid using global variables but also 
avoid an object-oriented programming? In other words: Is it possible to pass 
e.g. a dictionary containing some information to the function called by the 
event? The reason for not wanting the object-oriented way is: We want to 
teach something to students who never programmed before. And to them it would 
be pretty hard if we start everything object-oriented!
Thanks for your suggestions,
Martin
########################################
from pylab import *
def two_parts(event):
 global program_part
 if event.button == 3:
 program_part = program_part%2 + 1
 print " Changed to part to ", program_part
 if program_part == 1 and event.button == 1:
 plot([event.xdata], [event.ydata], marker = 'o', mfc = 'r')
 if program_part == 2 and event.button == 1:
 plot([event.xdata], [event.ydata], marker = 's', mfc = 'g')
 draw()
figure(1)
ax = subplot(111, autoscale_on=False)
ax.set_xlim([0,1])
ax.set_ylim([0,1])
program_part = 1
print " Actual program part is ", program_part
connect('button_press_event', two_parts)
show()
########################################