matplotlib-users Mailing List for matplotlib

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> John, I noticed that when plotting sine waves
    Steve> (simple_plot.py for example) with the gtk backend that the
    Steve> lowest points are not plotted.

Hi Steve, thanks for letting me know.  There is an off-by-one error
and it looks like and easy fix.  For future reference, you may want to
consider using GTKAgg as your default GUI.  This has the GTK widget
but uses agg for rendering.  Agg supports subpixel rendering and so
isn't susceptible to one pixel errors that crop up in GTK in a number
of contexts.  At low resolutions, these become particularly
noticeable.  Other benefits over the GTK backend are alpha blending,
anti-aliased drawing, and faster image support -
http://matplotlib.sourceforge.net/backends.html#GTKAgg

    Steve> So I wrote a test script to plot a square, the result is
    Steve> that the left and top edges are plotted and the bottom and
    Steve> right edges are clipped off (I can pan the view to display
    Steve> the missing lines). I can't think of any reason why you
    Steve> would plot data points and then expect them to be clipped
    Steve> off, so to me it looks like an off-by-one error.

Now on to your problem.

In backend_gtk draw_rectangle, change

        x, y = int(x), self.height-int(math.ceil(y+height))

to
        x, y = int(x), self.height-int(y+height)

and the GraphicsContext.set_clip_rectangle method to

    def set_clip_rectangle(self, rectangle):
        GraphicsContextBase.set_clip_rectangle(self, rectangle)
        l,b,w,h = rectangle
        rectangle = (int(l), self.renderer.height-int(b+h)+1,
                     int(w), int(h))
        self.gdkGC.set_clip_rectangle(rectangle)        

This fixes the bug, but doesn't handle your test case.  The lines in
your example are still clipped, but there is a reason for that.  In
your example, the lines are exactly where the axes lines will be
drawn.  It's a judgment call whether you want to see the axes line or
your line at that location.  In interactive navigation when you pan
and zoom around, it often happens that your data extend beyond the
axes lines; in this case you usually want a clean axes line not
partially obscured by your data.

If I set the clip so that the lines in your example are plotted, then
the axes lines are also overridden in other where the data extend
beyond the axes.

By tweaking the clip rectangle, eg 

        rectangle = (int(l), self.renderer.height-int(b+h),
                     int(w+1), int(h+2))

you can get your lines drawn but then the axes lines are obscured, eg
in subplot_demo and arctest.

Try experimenting with a few different demos and clip settings to see
what you think is the best compromise; let me know.

In Agg this is less of a problem since agg uses pixel blending when
two pixels are drawn at the same location so the data pixel over the
axes line pixel is less glaring.

Cheers,
JDH

>>>>> "Greg" == Greg Whittier <gr...@th...> writes:

    Greg> As a temporary solution you might try just transforming your
    Greg> r,theta data to x, y and then drawing a grid over it.

A nice workaround.  You may want to add 

  axis('off')

To get rid of the background axes.
 
    Greg> I looked at the classes and with the loglog already done as
    Greg> an example, it shouldn't be too hard to add polar plotting.
    Greg> So far though I haven't got any further than printing out
    Greg> some of the code.

I was planning on taking a different tack, and derive a PolarAxes from
Axes and RadialAxis from Axis, etc, which uses circles rather then
lines for the radial gridlines, and so on. But you get so close with
so little code that your approach may be better.  If you want to keep
forging ahead, I'm happy to leave the ball in your court.

On an unrelated note,

  from Numeric import *
  from matplotlib.matlab import *

is redundant because matplotlib.matlab imports all of numeric/numarray
as well as MLab, fft, and some stuff from LinearAlgebra and Matrix.
This is to provide a matlab like environment where most of the things
you need are there.

JDH

John,
I noticed that when plotting sine waves (simple_plot.py for example)
with the gtk backend that the lowest points are not plotted.

So I wrote a test script to plot a square, the result is that the left
and top edges are plotted and the bottom and right edges are clipped off
(I can pan the view to display the missing lines). I can't think of any
reason why you would plot data points and then expect them to be clipped
off, so to me it looks like an off-by-one error.

Test program:

from matplotlib.matlab import *

figure(1)
x = arange(0, 10+1, 1)
plot(x,     x*0+10, 'r-',
     x,     x*0,    'r-',
     x*0,   x,      'r-',
     x*0+10, x,     'r-')

show()

Regards,
Steve

John Hunter wrote:

>>>>>>"LUK" == LUK ShunTim <shu...@po...> writes:
> 
> 
>     LUK> If matplotlib honours the HOME environmental variable, could
>     LUK> it not be used on windows system as well?
> 
> Could you provide the context for your question?  What are you trying
> to do and what isn't working?
> 
> JDH
> 

Hello John,

I'm sorry I was in a hurry to go home and tried to read my mail before 
that. I did not make myself clear. I just clicked on the link in the 
message to take a peek at the .matplotlibrc file and found that "On 
windows, this would be, for example, C:\Python23\share\matplotlib." That 
led me to wonder whether HOME will take effect in windows installation.

I had not updated matplotlib for a while and I know it has seen big 
improvements. I've now downloaded version 0.52 and I can see now when 
HOME is set, matplotlib will first read the config file there.

Perhaps the comments in the original .matplotlibrc can be altered to 
make this clear. It's a really a very good idea to be able to set 
everything using just one config file.

I'm sure the people on the list will agree that matplotlib is a great 
piece of work and you have been wonderful in answering questions.

Good day,
ST
--

As a temporary solution you might try just transforming your r,theta
data to x, y and then drawing a grid over it.

I looked at the classes and with the loglog already done as an example,
it shouldn't be too hard to add polar plotting.  So far though I haven't
got any further than printing out some of the code.

Here's a very rough example of a workaround.

#!/usr/bin/python
from Numeric import *
from matplotlib.matlab import *
 
def drawgrid(sp,rticlevels,thetaticlevels):
    for r in rticlevels:
        theta = arange(0,2*pi+0.05,0.05)
        x = r*cos(theta)
        y = r*sin(theta)
        sp.plot(x,y,'k-')
    for theta in thetaticlevels:
        x = rticlevels[-1]*cos(theta)
        y = rticlevels[-1]*sin(theta)
        sp.plot([0,x],[0,y],'k-')
 
def polar(sp,r,theta,marker,rticlevels,thetaticlevels):
    x = r*cos(theta)
    y = r*sin(theta)
    sp.plot(x,y,marker)
    drawgrid(sp,rticlevels,thetaticlevels)
    return sp
 
sp = subplot(111)
theta = arange(0,pi,0.1)
r = 0.5 + cos(theta)
polar(sp,r,theta,'b-',arange(0.5,2.0,0.5),arange(0.,2*pi,pi/9.))


On Tue, 2004-03-30 at 14:32, Peter Groszkowski wrote:
> Hello:
> 
> I am currently using matplotlib for all the plotting in the software I am writing. I will however need to produce polar plots. As John has mentioned they should be added at one point. So my shameless question is roughly what version could I expect them to be included in? My options are to either wait for it, write it on my own, or write a simple interface (for my code) to GNUPlot or some other tool. I have not done very much poking around in the current matplotlib libraries (other than changing some rather minor details) and have a feeling that this might take me the longest. Interfacing GNUPLot to my code would not take more than a few hours, but I would prefer to stay with matplotlib. 
> 
> Thanks for the great work.
> Best,