matplotlib-devel Mailing List for matplotlib (Page 512)

I resynced and still had the problem.  I committed this change which
makes everything happy for me.

cvs diff: Diffing .
Index: _backend_agg.cpp
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/src/_backend_agg.cpp,v
retrieving revision 1.81
diff -r1.81 _backend_agg.cpp
677c677
<   agg::rect<int> rect( (int)l, height-(int)t, (int)r, height-(int)b ) ;
---
>   agg::rect rect( (int)l, height-(int)t, (int)r, height-(int)b ) ;
Index: _backend_agg.h
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/src/_backend_agg.h,v
retrieving revision 1.22
diff -r1.22 _backend_agg.h
162c162
<   agg::rect<int> bbox_to_rect( const Py::Object& o);
---
>   agg::rect bbox_to_rect( const Py::Object& o);


- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> CVS is giving compile errors in several of the cpp
>     Charles> backend files: error: `agg::rect' is not a template
> 
>     Charles> I think these should be `agg::rect_base' instead.
>     Charles> Changing that makes it compile fine.  Since I have never
>     Charles> messed with these files I thought I would post to the
>     Charles> list instead of committing the changes myself.
> 
> 
> In agg23/include/agg_basics.h you have
> 
>   typedef rect_base<int>    rect;   //----rec
> 
> So its either 
> 
>   agg::rect r;
> 
> or
> 
>   agg::rect_base<int> r;
> 
> 
> But strangely, I am not encountering any compile problems on my end.
> I did a fair amount of work in the agg backend yesterday, I just
> committed my tree, It may be that this problem will disappear after
> you resync.  If not, feel free to commit any needed fixes.
> 
> Thanks,
> JDH

John Hunter a =E9crit :

>>>>>>"Paul" =3D=3D Paul Cristini <pau...@un...> writes:
>>>>>>           =20
>>>>>>
>
>    Paul> you use PickBigLine.  Basically, PickBigLine evaluates the
>    Paul> orthogonal distance from the selected point to the line by
>    Paul> calculating the intersection between the line you want to
>    Paul> select and a line passing through the selected point which
>    Paul> is orthogonal.  Here is a modified version of PickBigLine
>    Paul> taking into account your remarks and working with Matplotlib
>    Paul> 0.82.
>
>Hi Paul,=20
>
>OK, at least now I understand what the problem is.  The current Axes
>picker works on line vertices and not individual segments, so if you
>zoom in on a segment and click on it you may not be near any of the
>vertices.  There is a similar problem with picking on polygons.
>Ideally, you want to iterate over all the segments in the lines and
>return the minimum distance to a segment (note there is a method
>matplotlib.mlab.dist_point_to_segment which computes this distance).
>For polygons, you would want to implement a test of insidedness.=20
>
>I thought about this when implementing the pick method but was afraid
>of the case when you have lots of segments; things could get really
>slow if you have a line with 10000 points unless you wrote some
>special purpose extension code.
>
>I do not think a separate "pick big line method" is needed here.
>Perhaps it makes more sense to add a flag to the pick method which
>either does it the correct and potentially slow way (useverts=3DFalse or
>something like that) or just picks on the vertices which is fast.  For
>dense lines, picking on the vertices works fine, but as you note this
>condition isn't always true.
>
>    Paul> My interests are in ray tracing in geophysics. I am
>    Paul> generating a lot of lines (thousands of) and then I need
>    Paul> after zooming to identify trajectories connecting a source
>    Paul> and a receiver . For example when I am picking a line I need
>    Paul> to know to what beam it belongs and also to what ray it
>    Paul> coresponds (two integers for instance) which is something I
>    Paul> know when I am plotting the line.  I don't know how to do it
>    Paul> with the label property. It is an axes property not a line2D
>    Paul> property.  If you want I can give an example of the use of
>    Paul> the tag property I add.
>
>An example would help.
>
>Of course, in python, you can "tag" anything you want
>
>    ax =3D subplot(111)
>    ax.myinitials =3D 'JDH'
>
>    line, =3D ax.plot([1,2,3])
>    line.mydata =3D ('Hi', 23)
>
>So it is questionable whether adding a "tag" attribute in particular
>is helpful.
>
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli=
ck
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20
>
You're right I did some tests taking into account your remarks and it
works well. I agree the tag method is not helpfull and I can do without
it. I also agree that a separate method for picking is not needed a flag
just as you suggested will be enough. The mlab.dist_point_to_segment
provides exactly the same results as what I wrote in the PickBigLine.
Thanks a lot for your advices
Paul

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> CVS is giving compile errors in several of the cpp
    Charles> backend files: error: `agg::rect' is not a template

    Charles> I think these should be `agg::rect_base' instead.
    Charles> Changing that makes it compile fine.  Since I have never
    Charles> messed with these files I thought I would post to the
    Charles> list instead of committing the changes myself.


In agg23/include/agg_basics.h you have

  typedef rect_base<int>    rect;   //----rec

So its either 

  agg::rect r;

or

  agg::rect_base<int> r;


But strangely, I am not encountering any compile problems on my end.
I did a fair amount of work in the agg backend yesterday, I just
committed my tree, It may be that this problem will disappear after
you resync.  If not, feel free to commit any needed fixes.

Thanks,
JDH

CVS is giving compile errors in several of the cpp backend files:

error: `agg::rect' is not a template

I think these should be `agg::rect_base' instead.  Changing that makes
it compile fine.  Since I have never messed with these files I thought I
would post to the list instead of committing the changes myself.

- Charlie

    Paul> The code just draw two lines a big one and a small one. The
    Paul> classical pick method works prefectly if you do not do a
    Paul> zoom to see the small line. But if you do it to see more
    Paul> accurately this small line then it is impossible to pick the
    Paul> big line unless you use PickBigLine.  Basically, PickBigLine
    Paul> evaluates the orthogonal distance from the selected point to
    Paul> the line by calculating the intersection between the line
    Paul> you want to select

Hi Paul, 

OK, at least now I understand what the problem is.  The current Axes
picker works on line vertices and not individual segments, so if you
zoom in on a segment and click on it you may not be near any of the
vertices.  There is a similar problem with picking on polygons.
Ideally, you want to iterate over all the segments in the lines and
return the minimum distance to a segment (note there is a method
matplotlib.mlab.dist_point_to_segment which computes this distance).
For polygons, you would want to implement a test of insidedness. 

I thought about this when implementing the pick method but was afraid
of the case when you have lots of segments; things could get really
slow if you have a line with 10000 points unless you wrote some
special purpose extension code.

I do not think a separate "pick big line method" is needed here.
Perhaps it makes more sense to add a flag to the pick method which
either does it the correct and potentially slow way (useverts=False or
something like that) or just picks on the vertices which is fast.  For
dense lines, picking on the vertices works fine, but as you note this
condition isn't always true.

    Paul> My interests are in ray tracing in geophysics. I am
    Paul> generating a lot of lines (thousands of) and then I need
    Paul> after zooming to identify trajectories connecting a source
    Paul> and a receiver . For example when I am picking a line I need
    Paul> to know to what beam it belongs and also to what ray it
    Paul> coresponds (two integers for instance) which is something I
    Paul> know when I am plotting the line.  I don't know how to do it
    Paul> with the label property. It is an axes property not a line2D
    Paul> property.  If you want I can give an example of the use of
    Paul> the tag property I add.

An example would help.

Of course, in python, you can "tag" anything you want

    ax = subplot(111)
    ax.myinitials = 'JDH'

    line, = ax.plot([1,2,3])
    line.mydata = ('Hi', 23)

So it is questionable whether adding a "tag" attribute in particular
is helpful.

JDH

>>>>> "Paul" == Paul Cristini <pau...@un...> writes:

    Paul> you use PickBigLine.  Basically, PickBigLine evaluates the
    Paul> orthogonal distance from the selected point to the line by
    Paul> calculating the intersection between the line you want to
    Paul> select and a line passing through the selected point which
    Paul> is orthogonal.  Here is a modified version of PickBigLine
    Paul> taking into account your remarks and working with Matplotlib
    Paul> 0.82.

Hi Paul, 

OK, at least now I understand what the problem is.  The current Axes
picker works on line vertices and not individual segments, so if you
zoom in on a segment and click on it you may not be near any of the
vertices.  There is a similar problem with picking on polygons.
Ideally, you want to iterate over all the segments in the lines and
return the minimum distance to a segment (note there is a method
matplotlib.mlab.dist_point_to_segment which computes this distance).
For polygons, you would want to implement a test of insidedness. 

I thought about this when implementing the pick method but was afraid
of the case when you have lots of segments; things could get really
slow if you have a line with 10000 points unless you wrote some
special purpose extension code.

I do not think a separate "pick big line method" is needed here.
Perhaps it makes more sense to add a flag to the pick method which
either does it the correct and potentially slow way (useverts=False or
something like that) or just picks on the vertices which is fast.  For
dense lines, picking on the vertices works fine, but as you note this
condition isn't always true.

    Paul> My interests are in ray tracing in geophysics. I am
    Paul> generating a lot of lines (thousands of) and then I need
    Paul> after zooming to identify trajectories connecting a source
    Paul> and a receiver . For example when I am picking a line I need
    Paul> to know to what beam it belongs and also to what ray it
    Paul> coresponds (two integers for instance) which is something I
    Paul> know when I am plotting the line.  I don't know how to do it
    Paul> with the label property. It is an axes property not a line2D
    Paul> property.  If you want I can give an example of the use of
    Paul> the tag property I add.

An example would help.

Of course, in python, you can "tag" anything you want

    ax = subplot(111)
    ax.myinitials = 'JDH'

    line, = ax.plot([1,2,3])
    line.mydata = ('Hi', 23)

So it is questionable whether adding a "tag" attribute in particular
is helpful.

JDH

Forgot the previous message, I did a bad manipulation

John,

Sorry for the late answer but I had problems in designing a simple example ( I had the very bad idea to choose letter "l" as the key to press) and also lots of other things to do. Here it is :

############################################################################
from pylab import *

def pick(event):
    if event.key=='p' and event.inaxes is not None:
        ax=event.inaxes
        a=ax.pick(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
    if event.key=='m' and event.inaxes is not None:
        ax=event.inaxes
        a=ax.pickBigLine(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
############################################################################
def PlotTwoLines():
    plot([0.,0.],[-100.,100.])
    plot([2.,2.],[-1.,1.])
    connect('key_press_event',pick)
    xmin,xmax,ymin,ymax=axis()
    axis([xmin-1.,xmax+1.,ymin*1.1,ymax*1.1])
    show()
if __name__=='__main__':
        PlotTwoLines()
#################################################################################

In this simple program, there is two way for picking a line, the classical pick method associated to the "p" key and PickBigLine method bassociated to the "m" key.
The code just draw two lines a big one and a small one. The classical pick method works prefectly if you do not do a zoom to see the small line. But if you do it to see more accurately this small line then it is impossible to pick the big line unless you use PickBigLine.
Basically, PickBigLine evaluates the orthogonal distance from the selected point to the line by calculating the intersection between the line you want to select
and a line passing through the selected point which is orthogonal.
Here is a modified version of PickBigLine taking into account your remarks and working with Matplotlib 0.82.

--------------------------------------------------------------------------------------------------
    def pickBigLine(self, x, y, trans=None):
        """
        Return the Line artist under point that is closest to the x, y.  if trans
        is None, x, and y are in window coords, 0,0 = lower left.  Otherwise,
        trans is a matplotlib transform that specifies the coordinate system
        of x, y.
        Calculates the orthogonal distance to the line
        Note this algorithm calculates distance to the vertices of the
        polygon, so if you want to pick a patch, click on the edge!
        """
        if trans is not None:
            xywin = trans.xy_tup((x,y))
        else:
            xywin = x,y

        def dist(a):
            Cste=1.e6    
            xdata = a.get_xdata(valid_only = True)
            ydata = a.get_ydata(valid_only = True)
            # A point is not a line
            if len(xdata) == 1: return Cste
            xt, yt = a.get_transform().numerix_x_y(xdata, ydata)
            xc, yc = xt[1]-xt[0], yt[1]-yt[0]
            if (xc==0.0 and yc == 0.0): return Cste
            D  = xc*xc + yc*yc
            D1 = -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc
            D2 = -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
            if D2/D>1.00001 or D2/D<-0.00001: return Cste
            return abs(D1/sqrt(D))

        artists = self.lines
   
        if not len(artists): return None
        ds = [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]
------------------------------------------------------------------------------------

My interests are in ray tracing in geophysics. I am generating a lot of lines
(thousands of) and then I need after zooming to identify  trajectories connecting a
source and a receiver . For example when I am picking a line I need to know to
what beam it belongs and also to what ray it coresponds (two integers for
instance) which is something I know when I am plotting the line.
I don't know how to do it with the label property. It is an axes
property not a line2D property.
If you want I can give an example of the use of the tag property I add.

Paul

John Hunter wrote:

>>>>>>"paul" =3D=3D paul cristini <pau...@un...> writes:
>
>
>    paul> The pick method because of the need to click on edges did
>    paul> not fullfill my needs. So I wrote a new method Called
>    paul> PickBigLine that does not required a mouse click close to
>    paul> the edge but close to the line you want to pick. This is
>    paul> particularly useful after zooming when the edges are
>    paul> sometimes out of the axis limits. =20
>
>Hi Paul,
>
>It is not clear to me what this method is for.  It would help if you
>posted an example where the current pick functionality failed and the
>one you propose succeeds (perhaps you could define your function at
>the top of the file for ease of use).
>
>I have a couple of questions/comments about your code...
>
>            xt, yt =3D a.get_transform().numerix_x_y(xdata, ydata)
>            xt, yt =3D asarray(xt), asarray(yt)=20
>
>There is no need to call asarray since numerix_x_y returns arrays.
>
>
>          =20
>            xc, yc =3D xt[1]-xt[0], yt[1]-yt[0]
>
>What is the point of this?  Why do you only look at the points xt[1],
>xt[0], yt[1], yt[0]?  What if someone needs to click on another point
>of the line?
>
>            if xc=3D=3D0.0 and yc =3D=3D 0.0: return 1000000.
>            D  =3D xc*xc + yc*yc
>            D1 =3D -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc             =
         =20
>            D2 =3D -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
>
>What do D1 and D2 represent?  I'm having trouble understanding why,
>for example, you need to do (xt[0]-xywin[0])*yc
>
>            if D2/D>1.001 or D2/D<-0.001: return 1000000.
>
>I think the 1000000.0 sentinel value should be renamed to some useful
>constant name so it will be self documenting.
>
>            return abs(D1/D)
>
>
>        artists =3D self.lines
>        if not len(artists): return None
>        ds =3D [ (dist(a),a) for a in artists]
>        ds.sort()
>        return ds[0][1]
>
>
>    paul> I also needed to add a
>    paul> new property to Line2D called tag (similar to matlab) for
>    paul> sorting purposes. I wonder if you have thought of adding
>    paul> such a possibility to some objects for which it can be very
>    paul> useful.
>
>Does the "label" property help here.  Could you give a use case?
>
>Thanks!
>
>JDH
>
Sorry for the late answer but I had problems in designing a simple exampl=
e( I
had the very bad idea to letter "l" tas a key to press). Here it is :

from pylab import *

def pick(event):
    if event.key=3D=3D'p' and event.inaxes is not None:
        ax=3Devent.inaxes
        a=3Dax.pick(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
    if event.key=3D=3D'm' and event.inaxes is not None:
        ax=3Devent.inaxes
        a=3Dax.pickBigLine(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
#########################################################################=
###
def PlotTwoLines():
#     hold(True)
    plot([0.,0.],[-100.,100.])
    plot([2.,2.],[-1.,1.])
    connect('key_press_event',pick)
    xmin,xmax,ymin,ymax=3Daxis()
    axis([xmin-1.,xmax+1.,ymin*1.1,ymax*1.1])
    show()
if __name__=3D=3D'__main__':
        PlotTwoLines()

Two way for picking a line the classical pick method by using the "p"key =
and
PickBigLine by using the "m" key.
The code just draw two lines a big one and a small one. The classical pic=
k
method works prefectly if you do not zoom to see the small line. But if y=
ou do a
zoom
to see more accurately the small line then it is impossible to pick the b=
ig line
unless you use PickBigLine.
Basically, PickBigLine evaluates the orthogonal distance from the selecte=
d point
to the line by calculating the intersection between the line you want to =
select
and a line passing through the selected point which is orthogonal.
Here is a modified version of PickBigLine taking into account your remark=
s and
working with Matplotlib 0.82
-------------------------------------------------------------------------=
-------------------------
    def pickBigLine(self, x, y, trans=3DNone):
        """
        Return the Line artist under point that is closest to the x, y.  =
if trans
        is None, x, and y are in window coords, 0,0 =3D lower left.  Othe=
rwise,
        trans is a matplotlib transform that specifies the coordinate sys=
tem
        of x, y.
    Calculates the orthogonal distance to the line
        Note this algorithm calculates distance to the vertices of the
        polygon, so if you want to pick a patch, click on the edge!
        """
        if trans is not None:
            xywin =3D trans.xy_tup((x,y))
        else:
            xywin =3D x,y

        def dist(a):
        Cste=3D1.e6
            xdata =3D a.get_xdata(valid_only =3D True)
            ydata =3D a.get_ydata(valid_only =3D True)
        # A point is not a line
        if len(xdata) =3D=3D 1: return Cste
            xt, yt =3D a.get_transform().numerix_x_y(xdata, ydata)
        xc, yc =3D xt[1]-xt[0], yt[1]-yt[0]
        if (xc=3D=3D0.0 and yc =3D=3D 0.0): return Cste
        D  =3D xc*xc + yc*yc
        D1 =3D -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc
        D2 =3D -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
        if D2/D>1.00001 or D2/D<-0.00001: return Cste
            return abs(D1/sqrt(D))

        artists =3D self.lines
  =20
        if not len(artists): return None
        ds =3D [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]
-------------------------------------------------------------------------=
-----------

My interests are in ray tracing in geophysics. I am generating a lot of l=
ines
(thousands of) and then I need by zooming to identify  trajectories conne=
cting a
source and a receiver. For example when I am picking a line I need to kno=
w to
what beam it belongs and also to what ray it coresponds (two integers for
instance). I don't know how to do it with the label property. It is an ax=
es
property not a line2D property.
If you want I can give an example of the use of the tag property I add.

Paul

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> John, Is there anything special required to get the subplot
    Ted> configuration tool available from QtAgg?  I'm in the process
    Ted> of fixing that sizing problem reported last week and the only
    Ted> way to fix it was to change how the toolbar layout works so
    Ted> I'm mucking around in the toolbar right now.

    Ted> I guess I'll sync and take a look at the Gtk backend and see
    Ted> what happens in there...

Hi Ted,

It shouldn't be hard.  The subplot configuration toolbar is a pure
matplotlib widget so all it requires id for your toolbar to embed it
into a properly sized qt canvas.  This means your toolbar needs to
know how to make a canvas, so you need to subclass the toolbar gor
qtagg.  What I did for GTK was add a "_get_canvas(self, fig)" method
to the toolbar.  

The base class binds the new subplots.png button to
configure_subplots, which looks like this -- note the line marked with
the arrow

class NavigationToolbar2GTK(NavigationToolbar2, gtk.Toolbar):
   ...snip...


    def configure_subplots(self, button):
        toolfig = Figure(figsize=(6,3))
====>   canvas = self._get_canvas(toolfig)
        toolfig.subplots_adjust(top=0.9)
        tool =  SubplotTool(self.canvas.figure, toolfig)

        w = int (toolfig.bbox.width())
        h = int (toolfig.bbox.height())


        window = gtk.Window()
        window.set_title("Subplot Configuration Tool")
        window.set_default_size(w, h)
        vbox = gtk.VBox()
        window.add(vbox)
        vbox.show()

        canvas.show()
        vbox.pack_start(canvas, True, True)
        window.show()


    def _get_canvas(self, fig):
        return FigureCanvasGTK(fig)


Then in gtkagg, I subclass the toolbar with



class NavigationToolbar2GTKAgg(NavigationToolbar2GTK):
    def _get_canvas(self, fig):
        return FigureCanvasGTKAgg(fig)


You might want to try the same approach for qtagg.  Of course there is
no FigureCanvasQt, but this approach will make it easier if someone
wants to add a different renderer to Qt, eg QtCairo.

JDH

On Wed, 2005-06-15 at 09:22 -0500, John Hunter wrote: 
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> Figure.get_width_height() returns width, height as floats,
>     Steve> but isn't width, height of a Figure always integers, and
>     Steve> wouldn't it make sense to return these as integers?
> 
>     Steve> This would enable changing the code: width, height =
>     Steve> figure.get_width_height() width, height = int(width),
>     Steve> int(height)
> 
>     Steve> to simply: width, height = figure.get_width_height()
> 
> The width and height of a figure are width/height in inches * dpi, and
> both dpi and the width/height vars can be floats.  So no, these values
> don't have to be integers.  In the postscript backend, for example, it
> returns the width and height of the figure in points.  We could add a
> convenience kwarg to the method, since in practice it is usually used
> by GUI developers who want the dimensions in pixels
> 
>   w, h = fig.get_width_height(asinteger=True)
> 
> If you think this is a good idea, feel free to add it.
> 
> JDH
My understanding is, the frontend does all its calculations in floating
point and never uses fig.get_width_height() because its always dealing
width width, height in inches and dpi.

'grep' shows that fig.get_width_height() is not used by the frontend,
its only ever used by the backends so it does not really belong in
Figure it belongs it FigureCanvas.

The value of width/height in inches * dpi does not need to be integers,
but what about the ACTUAL width, height values that the backends
produce?
The backends will either draw to the display with width, height in
integer pixels, or create an output file png, ps, svg etc, which in most
(all?) cases will have integer width, height. 
Does it make sense having an output file 1200.8 x 900.6? What use is the
fractional point/pixel?

I ran './simple_plot.py -dAgg' with
"savefig('simple_plot.png', dpi=150.1)"
to see if I would get the theoretical 1200.8 x 900.6 images.

png and jpg gave 1200 x 900
for svg I used w,h in inches of 8.1, 6.1 (and the default 72 dpi)
the svg file says the width, height is 583.2, 439.2, yet gthumb
shows the image size as 583 x 439.

So there is definitely a float-to-integer conversion/truncation for
width, height taking place.

I suggest moving Figure.get_width_height() to
FigureCanvas.get_width_height() and returning integers. If a backend
really can produce float width, height it can simply override
get_width_height().

regards,
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

John,
Is there anything special required to get the subplot configuration tool 
available from QtAgg?  I'm in the process of fixing that sizing problem 
reported last week and the only way to fix it was to change how the toolbar 
layout works so I'm mucking around in the toolbar right now.

I guess I'll sync and take a look at the Gtk backend and see what happens 
in there...

Ted

At 01:14 PM 6/15/2005, John Hunter wrote:

>What's new in 0.82
>
>Subplot configuration
>
>   All of the parameters of the subplots are now exposed at the rc,
>   pylab and API layout.  These are left, right, bottom, top, wspace
>   and hspace which control how the subplots are placed on the screen.
>   See figure.SubplotParams, figure.Figure.subplots_adjust and the
>   pylab method subplots_adjust and examples/subplots_adjust.py .  Also
>   added a GUI neutral widget for adjusting subplots, see
>   examples/subplot_toolbar.py.  There is a new toolbar button on GTK*,
>   WX* and TkAgg to launch the subplot configuration tool (which uses
>   the new matplotlib cross GUI classes discussed below).
>
>   This also makes it easier to make ganged plots -- see
>   examples/ganged_plots.py
>
>   Note this required a small change to how the toolbar on some GUIs
>   are imported; if you are using the mpl API in WXAgg and GTKAgg, see
>   API_CHANGES.
>
>GUI neutral widgets
>
>   Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
>   buttons and sliders).  You have to manually create properly sized
>   Axes for them to live in, but otherwise they are pretty easy to use.
>   See examples/widgets/*.py and
>   http://matplotlib.sf.net/screenshots.html#slider_demo.  This makes
>   it easier to create interactive figures that run across backends.
>
>Cap and join style
>
>   Exposes line cap and join style via new rc params and Line2D
>   properties
>
>     lines.dash_joinstyle : miter        # miter|round|bevel
>     lines.dash_capstyle : butt          # butt|round|projecting
>     lines.solid_joinstyle : miter       # miter|round|bevel
>     lines.solid_capstyle : projecting   # butt|round|projecting
>
>Axes kwargs
>
>   All Axes properties are now exposed via kwargs, so you can do, for
>   example
>
>    subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
>            xlim=(-1,1), ylim =(0,10) )
>
>Small bugfixes and features:
>
>   Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
>   docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
>   cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
>   fix (see API_CHANGES)
>
>http://matplotlib.sf.net
>
>Enjoy!
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> 
>     Steve> Figure.get_width_height() returns width, height as floats,
>     Steve> but isn't width, height of a Figure always integers, and
>     Steve> wouldn't it make sense to return these as integers?
> 
>     Steve> This would enable changing the code: width, height =
>     Steve> figure.get_width_height() width, height = int(width),
>     Steve> int(height)
> 
>     Steve> to simply: width, height = figure.get_width_height()
> 
> The width and height of a figure are width/height in inches * dpi, and
> both dpi and the width/height vars can be floats.  So no, these values
> don't have to be integers.  In the postscript backend, for example, it
> returns the width and height of the figure in points.  We could add a
> convenience kwarg to the method, since in practice it is usually used
> by GUI developers who want the dimensions in pixels
> 
>   w, h = fig.get_width_height(asinteger=True)
> 
> If you think this is a good idea, feel free to add it.

Just to be nitpicky, isn't this a bit of API bloat, when a simple

w, h = map(int,fig.get_width_height())

does the job just fine?  And it's even less characters :)

Cheers,

f

What's new in 0.82

Subplot configuration

  All of the parameters of the subplots are now exposed at the rc,
  pylab and API layout.  These are left, right, bottom, top, wspace
  and hspace which control how the subplots are placed on the screen.
  See figure.SubplotParams, figure.Figure.subplots_adjust and the
  pylab method subplots_adjust and examples/subplots_adjust.py .  Also
  added a GUI neutral widget for adjusting subplots, see
  examples/subplot_toolbar.py.  There is a new toolbar button on GTK*,
  WX* and TkAgg to launch the subplot configuration tool (which uses
  the new matplotlib cross GUI classes discussed below).  

  This also makes it easier to make ganged plots -- see
  examples/ganged_plots.py

  Note this required a small change to how the toolbar on some GUIs
  are imported; if you are using the mpl API in WXAgg and GTKAgg, see
  API_CHANGES.

GUI neutral widgets

  Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
  buttons and sliders).  You have to manually create properly sized
  Axes for them to live in, but otherwise they are pretty easy to use.
  See examples/widgets/*.py and
  http://matplotlib.sf.net/screenshots.html#slider_demo.  This makes
  it easier to create interactive figures that run across backends.

Cap and join style

  Exposes line cap and join style via new rc params and Line2D
  properties

    lines.dash_joinstyle : miter        # miter|round|bevel
    lines.dash_capstyle : butt          # butt|round|projecting
    lines.solid_joinstyle : miter       # miter|round|bevel
    lines.solid_capstyle : projecting   # butt|round|projecting

Axes kwargs

  All Axes properties are now exposed via kwargs, so you can do, for
  example

   subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
           xlim=(-1,1), ylim =(0,10) )

Small bugfixes and features:

  Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
  docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
  cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
  fix (see API_CHANGES)

http://matplotlib.sf.net

Enjoy!
JDH

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

    Steve> Figure.get_width_height() returns width, height as floats,
    Steve> but isn't width, height of a Figure always integers, and
    Steve> wouldn't it make sense to return these as integers?

    Steve> This would enable changing the code: width, height =
    Steve> figure.get_width_height() width, height = int(width),
    Steve> int(height)

    Steve> to simply: width, height = figure.get_width_height()

The width and height of a figure are width/height in inches * dpi, and
both dpi and the width/height vars can be floats.  So no, these values
don't have to be integers.  In the postscript backend, for example, it
returns the width and height of the figure in points.  We could add a
convenience kwarg to the method, since in practice it is usually used
by GUI developers who want the dimensions in pixels

  w, h = fig.get_width_height(asinteger=True)

If you think this is a good idea, feel free to add it.

JDH

Figure.get_width_height() returns width, height as floats,
but isn't width, height of a Figure always integers, and wouldn't it
make sense to return these as integers?

This would enable changing the code:
    width, height = figure.get_width_height()
    width, height = int(width), int(height)

to simply:
    width, height = figure.get_width_height()

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> So I am going to go ahead and throw this one out.  It is
    Charles> by no means complete.

    Charles> http://euclid.uits.iupui.edu/~cmoad/CocoaAgg.tar.gz

Cool, I just go that working on Panther.  For those who want to try
it, I'll add to Charles instructions that you need to add CocoaAgg to
matplotlib/__init__.py and matplotlib/backends/__init__.py.

It looks nice!  Charles, the toolbar will be easier than you think,
since all you have to do is make the right connections to mouse press
event, motion notify event and so on.  If you set up the events, mpl
will do the rest.  Also, the save figure button doesn't seem to do
anything.  I assume this is just a place holder?

    Charles> There a lot of things I would like to do with this
    Charles> including using QTKit to dump a movie and adding
    Charles> clipboard support.  Long term, it would be nice to make
    Charles> the plots embeddable in an app.  

Sounds good -- keep up the good work!

JDH

So I am going to go ahead and throw this one out.  It is by no means  
complete.

http://euclid.uits.iupui.edu/~cmoad/CocoaAgg.tar.gz

     It requires PyObjC.  You need to put the nib file in the  
matplotlib data path.  On panther you can run a script with - 
dCocoaAgg and resize the native window.  Unfortunately tiger changed  
something with creating an imagerep and things aren't working quite  
right with it yet.
     You DO NOT have to use pythonw to run your scripts.
     There a lot of things I would like to do with this including  
using QTKit to dump a movie and adding clipboard support.  Long term,  
it would be nice to make the plots embeddable in an app.  Anyway, let  
me know if anyone is interested in working on this.

- Charlie

>>>>> "paul" == paul cristini <pau...@un...> writes:

    paul> The pick method because of the need to click on edges did
    paul> not fullfill my needs. So I wrote a new method Called
    paul> PickBigLine that does not required a mouse click close to
    paul> the edge but close to the line you want to pick. This is
    paul> particularly useful after zooming when the edges are
    paul> sometimes out of the axis limits.  

Hi Paul,

It is not clear to me what this method is for.  It would help if you
posted an example where the current pick functionality failed and the
one you propose succeeds (perhaps you could define your function at
the top of the file for ease of use).

I have a couple of questions/comments about your code...

            xt, yt = a.get_transform().numerix_x_y(xdata, ydata)
            xt, yt = asarray(xt), asarray(yt) 

There is no need to call asarray since numerix_x_y returns arrays.

           
            xc, yc = xt[1]-xt[0], yt[1]-yt[0]

What is the point of this?  Why do you only look at the points xt[1],
xt[0], yt[1], yt[0]?  What if someone needs to click on another point
of the line?

            if xc==0.0 and yc == 0.0: return 1000000.
            D  = xc*xc + yc*yc
            D1 = -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc                       
            D2 = -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc

What do D1 and D2 represent?  I'm having trouble understanding why,
for example, you need to do (xt[0]-xywin[0])*yc

            if D2/D>1.001 or D2/D<-0.001: return 1000000.

I think the 1000000.0 sentinel value should be renamed to some useful
constant name so it will be self documenting.

            return abs(D1/D)


        artists = self.lines
        if not len(artists): return None
        ds = [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]


    paul> I also needed to add a
    paul> new property to Line2D called tag (similar to matlab) for
    paul> sorting purposes. I wonder if you have thought of adding
    paul> such a possibility to some objects for which it can be very
    paul> useful.

Does the "label" property help here.  Could you give a use case?

Thanks!

JDH

>>>>> "Baptiste" == Baptiste Carvello <bap...@al...> writes:

    Baptiste> While I was at it, I recoded those functions as property
    Baptiste> setters, to put them in line with the rest of
    Baptiste> matplotlib.

Thanks Baptiste - I just committed this to CVS.  For future patches,
could  you please use mpl naming conventions

    UpperCase  - classes
    lower of mixedCase: variables
    lower_underscore : functions

I know this is not prominently documented anywhere, but it will help
keep the code more consistent.  I already made the required changes
for your patch.

Thanks again!
JDH

cf...@li... wrote:

>Looks like a problem with drawing ticks. Attached is code that demonstrates the problem (for me), and the traceback.
>
>I'm using Python 2.4.1, Numeric 23.8, and the stock .matplotlibrc, on win32.
>
>The script runs fine in 0.80.
>
>
>[...]
>
>------------------------------------------------------------------------
>
>Traceback (most recent call last):
>  File "bug-0.81.py", line 50, in ?
>    PlotResults()
>  File "bug-0.81.py", line 18, in PlotResults
>    cvs.draw()
>  File "C:\Python24\Lib\site-packages\matplotlib\backends\backend_agg.py", line 369, in draw
>    self.figure.draw(renderer)
>  File "C:\Python24\Lib\site-packages\matplotlib\figure.py", line 395, in draw
>    for a in self.axes: a.draw(renderer)
>  File "c:\Python24\lib\site-packages\matplotlib\axes.py", line 1357, in draw
>    self.yaxis.draw(renderer)
>  File "C:\Python24\Lib\site-packages\matplotlib\axis.py", line 530, in draw
>    self.major.formatter.set_locs(majorLocs)
>  File "C:\Python24\Lib\site-packages\matplotlib\ticker.py", line 296, in set_locs
>    self._set_orderOfMagnitude(d)
>  File "C:\Python24\Lib\site-packages\matplotlib\ticker.py", line 323, in _set_orderOfMagnitude
>    else: oom = math.floor(math.log10(locs[-1]))
>OverflowError: math range error
>  
>
Sorry about that. I didn't anticipate the case where only one tick is 
present, and also being equal to zero. The fix has been committed to CVS.

Darren

Hello,

I finally tracked down an annoying ticking bug. The bug goes that way:
1) you plot a figure with many ticks
2) you zoom in so that few ticks are left
3) you call tick_top()
4) you zoom out
Then, some of your ticks will be on top, some others at bottom.

The cause of this bug is that tick_top and friends do not change the visibility 
properties of all the ticks, but only the visible ones. This is because they 
call self.get_major_ticks(), instead of modifying all ticks in self.majorTicks.

While I was at it, I recoded those functions as property setters, to put them in 
line with the rest of matplotlib.

Regards,
BC

Hi everyone,

On Wednesday 08 June 2005 11:42 am, Fernando Perez wrote:
> Darren Dale wrote:
>
> > Would you send me a copies of the bad eps and the fixed version, and al=
so
> > a copy of ps2eps? I don't have that program on my system, and was not
> > able to find it on the web.
>
> Here goes. As it turns out, ps2eps is a simple perl script which I got god
> knows when.  So people won't actually have it on their systems, it's
> something that lives in /usr/local/bin on my box, sorry.
>
> But no worries.  I can lie with using ps2eps for now, until I can upgrade
> to a moer current ghostscript.

I am still unhappy with the bitmapped fonts that result from the conversion=
 to=20
eps, using ghostscript's epswrite. They look ok in Adobe Reader, but not so=
=20
in kpdf or ggv. (I was inspired to look at this today after discovering tha=
t=20
Adobe Reader for linux does not display correctly when I run in 1024x768=20
resolution on my native 1680x1050 laptop. Kpdf displays correctly, but the=
=20
fonts are terrible.)

I looked into ps2eps some more today, to see if it would generate a file th=
at=20
I could embed in a latex document. The short answer is no.=20

The long answer is that PSFrag was not designed to do what I am trying to d=
o:=20
generate an eps file that can later be embedded in a document. It uses a=20
number of PostScript operators that are illegal in an eps file: setglobal,=
=20
statusdict and userdict. Here is the blurb from PostScript Language=20
Reference, Second Edition, Appendix I: setglobal disrupts page independence=
=20
and nesting of included documents. [...] Creation and modification of globa=
l=20
objects are uneffected by save-restore operators.

I think it might be worth looking into the way PyX is dealing with TeX/LaTe=
X,=20
as someone recently suggested. PyX's eps output looks just like standard (n=
o=20
tex) MPL output, where these nesting issues do not exist. They even have th=
e=20
same issue of dumping entire font definitions into the output.

Darren

 
The pick method because of the need to click on edges did not fullfill
my needs. So I wrote a new method Called PickBigLine that does not
required a mouse click close to the edge but close to the line you want
to pick. This is particularly useful after zooming when the edges are
sometimes out of the axis limits.
I also needed to add a new property to Line2D called tag (similar to
matlab) for sorting purposes. I wonder if you have thought of adding
such a possibility to some objects for which it can be very useful.

Thanks,

Paul Crisini


     def pickBigLine(self, x, y, trans=None):
        """
        Return the Line artist under point that is closest to the x, y. 
if trans
        is None, x, and y are in window coords, 0,0 = lower left. 
Otherwise,
        trans is a matplotlib transform that specifies the coordinate system
        of x, y.

        No need to click on the edge!
        """
        if trans is not None:
            xywin = trans.xy_tup((x,y))
        else:
            xywin = x,y

        def dist(a):
            xdata = a.get_xdata()
            ydata = a.get_ydata()
            xt, yt = a.get_transform().numerix_x_y(xdata, ydata)
            xt, yt = asarray(xt), asarray(yt)
            xc, yc = xt[1]-xt[0], yt[1]-yt[0]
            if xc==0.0 and yc == 0.0: return 1000000.
            D  = xc*xc + yc*yc
            D1 = -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc
            D2 = -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
            if D2/D>1.001 or D2/D<-0.001: return 1000000.
            return abs(D1/D)

        artists = self.lines
        if not len(artists): return None
        ds = [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]

Looks like a problem with drawing ticks. Attached is code that demonstrates the problem (for me), and the traceback.

I'm using Python 2.4.1, Numeric 23.8, and the stock .matplotlibrc, on win32.

The script runs fine in 0.80.

Cheers,
Chris Fuller

John Hunter wrote:

> TeX support : Now you can (optionally) use TeX to handle *all* of the
>   text elements in your figure with the rc param text.usetex (*Agg and
>   PS only).  PS support requires tex, dvips and Ghostscript 8.51
>   (older versions do not work properly -- test your version with
>   'gs --version').  Agg support requires tex and dvipng.  A
>   directory ~/.tex.cache is created where support files are cached for
>   later reuse.  We opted to ues TeX rather than LaTeX because it is
>   faster and can do all the things we thought useful for figure text
>   snippets.  See http://matplotlib.sf.net/screenshots.html#tex_demo
>   and http://matplotlib.sf.net/matplotlib.texmanager.html.  There are
>   several new rc params for configuring tex/latex support

Yes!  Many, many thanks to all who helped on this.  Below are some notes 
for Fedora users, who may find it a bit tricky to get this thing working.

The new mpl TeX support requires dvipng, which is not available in any 
Yum repository I could find.  It seems that FedoraCore 4 will include 
tetex-3.0, which bundles dvipng.  But in Fedora Core 2-3, it is not 
available.  You can obviously build it from sources from:

http://sourceforge.net/project/showfiles.php?group_id=109426&package_id=118693&release_id=302829

but if like me, you are lazy and like to keep all your machines 
centrally administered thanks to the convenience of Yum, you can do 
better.  Here, I found a dvipng rpm built for Fedora 2, but which works 
fine in FC3:

http://rpm.nogin.org/WebWork/fc2/dvipng-1.4-1.rhfc2.i386.html

Just drop that RPM somewhere in your local Yum repo (or just install it 
by hand), and you're done.  TeX beauty in all your mpl plots!

Again, eternal gratitude to Darren, John and the rest.

Cheers,

f