Thread: [Matplotlib-users] Plotting a matrix in some region

Hi,

today I urgently needed to plot a matrix in a given
region of a plot. It seems that imshow does not
support this (at least I could not find how)
and I don't understand the internals well
enough to add such a feature.
As work-around I have set up the quick hack listed
at the end of this mail.
It is not really complicated, but
maybe it is useful to someone else.

Note, that there are a couple of problems:
- zooming does not work as expected
  (the displayed matrix stays fixed in absolute coords wrt to
   the current graph)
- drawing a line over the shown bitmap is not possible
- presumably more

Is there a way to this better with imshow?

Best,

Arnd


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

def plot_mat(mat,extent=None):
    """ Plot a matrix (or whatever suits imshow) at
        the place defined by extent=[x0,x1,y0,y1].
        """
    g=gca()
    l,b,w,h=g.get_position()
    x0,x1=g.get_xlim()
    y0,y1=g.get_ylim()

    #print "Axes coords of curr axes:",l,b,w,h
    #print "Ranges:",x0,x1,y0,y1

    if extent!=None:
        inset_x0=extent[0]
        inset_x1=extent[1]
        inset_y0=extent[2]
        inset_y1=extent[3]
    else:
        inset_x0=x0
        inset_x1=x1
        inset_y0=y0
        inset_y1=y1


    #print "WANTED:",inset_x0,inset_x1,inset_y0,inset_y1

    inset_w=w*(inset_x1-inset_x0)/(x1-x0)
    inset_h=h*(inset_y1-inset_y0)/(y1-y0)
    inset_l=l+(inset_x0-x0)/(x1-x0)*w
    inset_b=b+(inset_y0-y0)/(y1-y0)*h

    #print "RESULT:",inset_l  , inset_b  , inset_w , inset_h

    ax=axes( [inset_l  , inset_b  , inset_w , inset_h],axisbg="y")
    setp(ax,xticks=[],yticks=[])
    imshow(arr,interpolation="nearest")

# 2D
arr=reshape(arange(25),(5,5))

# 1D plot
x=arange(2.0,10.0,0.1)
line1,=plot(x,x**2)
line2,=plot(x,x**2)

#draw()

plot_mat(arr,extent=[5.0,8.0,15.0,50.0])

# Problem: try to plot this over the other plot,
# does not work
setp(line2,data=(x,0.25*x**3),zorder=1000)

show()

On 9/1/05, Arnd Baecker <arn...@we...> wrote:

  > today I urgently needed to plot a matrix in a given
  > region of a plot. It seems that imshow does not
  > support this (at least I could not find how)
  > and I don't understand the internals well
  > enough to add such a feature.
  > As work-around I have set up the quick hack listed
  > at the end of this mail.
  > It is not really complicated, but
  > maybe it is useful to someone else.

If I'm understanding you correctly, you want to set the "extent"
argument of imshow

from pylab import *
arr=3Dreshape(arange(25),(5,5))

imshow(arr, extent=3D[5.0,8.0,15.0,50.0])
x=3Darange(2.0,10.0,0.1)
line1,=3Dplot(x,x**2)
line2,=3Dplot(x,x**2)
setp(line2,data=3D(x,0.25*x**3),zorder=3D1000)
show()

  > Note, that there are a couple of problems:
  > - zooming does not work as expected
  >   (the displayed matrix stays fixed in absolute coords wrt to
  >    the current graph)
  > - drawing a line over the shown bitmap is not possible
  > - presumably more

The approach above should fix these three problems.

JDH

Hi John,

thank you very much for your quick reply!
It seems things are slightly more complicated, though...

On Thu, 1 Sep 2005, John Hunter wrote:

> On 9/1/05, Arnd Baecker <arn...@we...> wrote:
>
>   > today I urgently needed to plot a matrix in a given
>   > region of a plot. It seems that imshow does not
>   > support this (at least I could not find how)
>   > and I don't understand the internals well
>   > enough to add such a feature.
>   > As work-around I have set up the quick hack listed
>   > at the end of this mail.
>   > It is not really complicated, but
>   > maybe it is useful to someone else.
>
> If I'm understanding you correctly, you want to set the "extent"
> argument of imshow

Well, I thought so too, but I also need `axis("equal")`
and depending on the order of setting the
axis intervals (`axis([-0.35,2.1,-0.2,1.25])`)
before or after this, one obtains completely different results.

Below is an example, where this is illustrated,
by changing the code at the places marked by ===>.

So the example I posted was stripped down too strongly
(and your solution does work for that case!).

Best,

Arnd

P.S.: I ran my test with yesterdays CVS.

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

# ===> uncommenting this gives a different result:
#ax=subplot(111,autoscale_on=False)

# ===> changing the order of these two gives different results:
axis("equal")
axis([-0.35,2.1,-0.2,1.25])
    # (note that -0.2 and 1.25 are not respected)


arr=reshape(arange(25),(5,5))

# ===> commenting this one out, when autoscale_on=False
#      gives the expected result
imshow(arr, extent=[0.5,1.0,0.2,0.8])

# plot a circle to see if the aspect ratio is correct:
phi=arange(0.0,2.0*pi,0.01)
x=0.5*cos(phi)+0.5
y=0.5*sin(phi)+0.5

plot(x,y,lw="8")

show()

hi,

i've been having lots of fun with scatter plots and =20
coloured circles.  i want to provide a legend.

i'm using colour to define discrete elements rather =20
than continuous values (so colorbar() isn't much =20
help to me -- i think...)

basically:
      (red) chevrolet
   (orange) mazda
   (yellow) honda
    ...

any tips?


jack

is there any more information you'd like to help me =20
with constructing a legend for this scatter?

i think i am misusing the scatter graph here... =20
letting scatter assign colours from a continous =20
selection rather than specifying a color.

please help,

jack

On 03/09/05 14:22:33, Jack Andrews wrote:
>  I could guess at what you are trying to do, but  =20
> it would help a lot if  you posted an example =20
> that we could run, with  comments about what you  =20
> want to happen versus what is happening.

thanks... attached is an image of roughly what i =20
want.  a program is below.

#!/usr/bin/python
from pylab import *
N=3D20
def xycs():
  x,y=3Dresize(rand(2*N),(2,N))
  x[:N/2]*=3D2;y[:N/2]/=3D2;
  c=3Darray([0]*(N/2)+[1]*(N/2))
  s=3Darray(([400]+[30]*(N/2-1))*2)
  print zip(c,s)
  p=3Dscatter(x,y,c=3Dc,s=3Ds,faceted=3D0)
  grid(True)
  setp(p, 'alpha', 0.75)
  savefig('scat_lgnd.png')
  show()
  return 0
if __name__=3D=3D'__main__':
  xycs()


----                       _I v o r y__K i t e____
jack andrews
university of mordialloc
vic australia                ef...@iv...

Hi John,

I looked a little bit further into this,
and maybe there is a simple solution:

In imshow (axes.py): if I comment out the lines

        #corners = (xmin, ymin), (xmax, ymax)
        #self.update_datalim(corners)
        #self.set_xlim((xmin, xmax))
        #self.set_ylim((ymin, ymax))

it works fine for the example I sent yesterday.
(only the different behaviour when changing the order
of `axis("equal")` and `axis([-0.35,2.1,-0.2,1.25])`
persists.)

So maybe it is already enough to encapsulate the above
part by  `if autoscale_on==True`?
I am sorry that I can't help more here, but I just don't understand
the internals of matplotlib well enough.


Best,

Arnd

hi,

matplot is great! my question:

   can i rotate a (scatter) plot 45 degrees
   anticlockwise?

ie. rotate from y|
                  |
                  -----
                      x

              to  y\   /x
                    \ /
?

the labels on the axes would also be rotated.
of course, i could rotate the plot elements 45
degrees clockwise then rotate the resulting
image anticlockwise

thanks,


jack andrews

>>>>> "Jack" == Jack Andrews <ef...@iv...> writes:


    Jack> the labels on the axes would also be rotated.  of course, i
    Jack> could rotate the plot elements 45 degrees clockwise then
    Jack> rotate the resulting image anticlockwise

It's possible to draw it, but you would have to do all the
transformations/rotations by hand, including drawing the axes as
Line2D instances and labels as Text instances (see for example the
"Scatter3D" example in the archives).  There is no easy, built-in, way
to do it, currently.  In the planned refactoring of the axis handling,
I'll keep this use-case in mind.

JDH

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

    Arnd> Hi John, I looked a little bit further into this, and maybe
    Arnd> there is a simple solution:

    Arnd> In imshow (axes.py): if I comment out the lines

    Arnd>         #corners = (xmin, ymin), (xmax, ymax)
    Arnd> #self.update_datalim(corners) #self.set_xlim((xmin, xmax))
    Arnd> #self.set_ylim((ymin, ymax))

    Arnd> it works fine for the example I sent yesterday.  (only the

Yes, that should read

        corners = (xmin, ymin), (xmax, ymax)
        self.update_datalim(corners)
        if self._autoscaleon:
            self.set_xlim((xmin, xmax))
            self.set_ylim((ymin, ymax))

Thanks.

    Arnd> different behaviour when changing the order of
    Arnd> `axis("equal")` and `axis([-0.35,2.1,-0.2,1.25])` persists.)

It is not surprising that the order makes a difference.  When
correcting for the aspect ratio, either the data limits, window
limits, or both have to change.  The default is to change the data
limits, but you can control this by calling

  ax.set_aspect(aspect='equal', fixLimits=True)

This is the function that axis('equal') calls, and by using it
directly you can tweak some of the default behaviors.  See the
docstring for set_aspect (in CVS) for more information.

This is fairly new functionality so let us know if this works for you.
It might be a good idea for someone to start a wiki entry on the
various issues of axes aspect ratio.

JDH

>>>>> "Jack" == Jack Andrews <ef...@iv...> writes:

    Jack> hi, i've been having lots of fun with scatter plots and
    Jack> coloured circles.  i want to provide a legend.

    Jack> i'm using colour to define discrete elements rather than
    Jack> continuous values (so colorbar() isn't much help to me -- i
    Jack> think...)

    Jack> basically: (red) chevrolet (orange) mazda (yellow) honda ...

    Jack> any tips?

I could guess at what you are trying to do, but it would help a lot if
you posted an example that we could run, with comments about what you
want to happen versus what is happening.

Have you seen examples/legend_demo2.py, which illustrates how to make
legends for a subset of objects in the plot?

JDH

>  I could guess at what you are trying to do, but  =20
> it would help a lot if  you posted an example =20
> that we could run, with  comments about what you  =20
> want to happen versus what is happening.

thanks... attached is an image of roughly what i =20
want.  a program is below.

#!/usr/bin/python
from pylab import *
N=3D20
def xycs():
  x,y=3Dresize(rand(2*N),(2,N))
  x[:N/2]*=3D2;y[:N/2]/=3D2;
  c=3Darray([0]*(N/2)+[1]*(N/2))
  s=3Darray(([400]+[30]*(N/2-1))*2)
  print zip(c,s)
  p=3Dscatter(x,y,c=3Dc,s=3Ds,faceted=3D0)
  grid(True)
  setp(p, 'alpha', 0.75)
  savefig('scat_lgnd.png')
  show()
  return 0
if __name__=3D=3D'__main__':
  xycs()

On Fri, 2 Sep 2005, John Hunter wrote:

> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

[...]

>     Arnd> different behaviour when changing the order of
>     Arnd> `axis("equal")` and `axis([-0.35,2.1,-0.2,1.25])` persists.)
>
> It is not surprising that the order makes a difference.

To be honest, from a user perspective such effects
are very problematic and I would usually considered as a bug.

Together with Martin Richter I had a closer look at this:

 a) pylab.py, axis(...):

   I think, that the command
    ` axis([0.5,1.0,-2.0,5.0])` should,
   whenever `ax.get_aspect() ==  'equal'`,
   recompute the aspect.
   This could be achieved by calling
     ax.set_aspect(recompute=True)
   before the corresponding `draw_if_interactive()`
   and the set_aspect routine in axes.py would read at the beginning:

    def set_aspect(self,aspect='normal',fixLimits=False,alignment='center',
                   recompute=False):

        [...]
        if recompute:
            try:
                aspect=self._aspect
                fixLimits=self._fixLimits
                alignment=self._alignment
            except AttributeError:
                return

         self._aspect=self.aspect
         self._fixLimits=fixLimits
         self._alignment=alignment

 b) For axes.py, set_aspect, it seems better to us
    to restore the originalPosition:

         else:  # Change limits on axes
            #l,b,w,h = self.get_position()  # Keep size of subplot

            # --->   # restore changes which could have come from
            # --->   # a previous call axes("scaled"), i.e. fixLimits=True:
            l,b,w,h = self._originalPosition
            self.set_position( (l,b,w,h) )
            # --->
            axW = w * figW; axH = h * figH


a) should ensure that it does not matter when a range is set
b) should ensure that after an `axis("scaled")`
   an `axis("equal")` gives the same result
   as if the `axis("scaled")` was not given before.

I am not sure if the above has any unwanted side-effects.
At least it gets rid of a couple of the ordering
effects.


> When
> correcting for the aspect ratio, either the data limits, window
> limits, or both have to change.  The default is to change the data
> limits, but you can control this by calling
>
>   ax.set_aspect(aspect='equal', fixLimits=True)
>
> This is the function that axis('equal') calls, and by using it
> directly you can tweak some of the default behaviors.  See the
> docstring for set_aspect (in CVS) for more information.

I don't like the name `fixLimits` to much, because
it sounds as if something has to be fixed (but nothing is broken, IMHO).
What about `fixedLimits`?
(Sorry if I am showing off my English deficiencies here ...)

While at this: I also don't like `autoscale_on` very much.
I think that `autoscale` (being True or False) would be enough.

And one more (just to complicate matters even more):
At the moment there is only autoscaling for x and y
at the same time. Gnuplot, for example, allows
to specify the xrange or yrange separately and the
other range is autoscaled.
I am mentionining this, because it might be a useful feature.
(However, it might make the coding of
the autoscaling even more involved...).


> This is fairly new functionality so let us know if this works for you.
> It might be a good idea for someone to start a wiki entry on the
> various issues of axes aspect ratio.

I hope that everything can be done easily just by using
`axis(...)`. A few examples would be very good for the
wiki (or the demo). I could provide these (after
I am back from a conference next week...).

Best,

Arnd

>>>>> "Jack" == Jack Andrews <ef...@iv...> writes:

    Jack> is there any more information you'd like to help me with
    Jack> constructing a legend for this scatter?

    Jack> i think i am misusing the scatter graph here...  letting
    Jack> scatter assign colours from a continous selection rather
    Jack> than specifying a color.

Yes, you probably want to assign specific colors in multiple calls to
scatter.  Scatter returns a
matplotlib.collections.RegularPolyCollection, which legend is not
equiped to deal with.  To hack around this, you can create a proxy
patch to pass to legend, which has the colors you want to use for the
legend

from matplotlib.patches import Rectangle
from pylab import *

N=20

props = dict( alpha=0.75, faceted=False )

x, y= rand(2,N)
s=array(([400]+[30]*(N/2-1))*2)
reds  = scatter(x, y, c='red',   s=s, **props)

x, y= rand(2,N)
s=array(([400]+[30]*(N/2-1))*2)

blues = scatter(x, y, c='blue', s=s, **props)

redp = Rectangle( (0,0), 1,1, facecolor='red')
bluep = Rectangle( (0,0), 1,1, facecolor='blue')

legend( (redp, bluep), ('reds', 'blues') )
grid(True)

show()

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:

    Arnd> On Fri, 2 Sep 2005, John Hunter wrote:

    Arnd> To be honest, from a user perspective such effects are very
    Arnd> problematic and I would usually considered as a bug.

    Arnd> Together with Martin Richter I had a closer look at this:

Hey Arnd, 

All of your suggestions look reasonable to me on cursory inspection,
but the person best equipped to decide these things is Mark Bakker,
who wrote the axes equal handling.  I've CC'd him on this message.  

    Mark> Regarding the questions of axis('equal') and axis('scaled'),
    Mark> I submitted a patch for the axis('equal') command about a
    Mark> month ago that will turn it into the same behavior as
    Mark> matlab. After the axis('equal') command is given, the scale
    Mark> on both axes will be equal (such that a circle looks like a
    Mark> circle).  It has a little demo file with it as
    Mark> well. Hopefully that will be implemented in CVS soon (let me
    Mark> know if I can help here, John),

Mark, I committed your patch and these guys are using CVS, so the
issues Arnd and Martin describe apply to the patched matplotlib.

If the three of you could hash this out and come up with an updated
patch you are all happy with, I'm happy to apply it.  As always,
please provide some language with your patch for API_CHANGES, if there
are any.

I have a couple of minor comments:

    Arnd> While at this: I also don't like `autoscale_on` very much.
    Arnd> I think that `autoscale` (being True or False) would be enough.

I recall Fernando objecting to this too, so it must be particularly
irritating.  My inclination for cosmetic things like this is to not
break backwards compatibility for a slightly more pleasing name.

    Arnd> And one more (just to complicate matters even more): At the
    Arnd> moment there is only autoscaling for x and y at the same
    Arnd> time. Gnuplot, for example, allows to specify the xrange or
    Arnd> yrange separately and the other range is autoscaled.  I am
    Arnd> mentionining this, because it might be a useful feature.
    Arnd> (However, it might make the coding of the autoscaling even
    Arnd> more involved...).

I think this would be useful too.  We could implement autoscalex and
autoscaley properties which would handle this.  I don't think the code
would be particularly cumbersome.  Then the question is: what should
be done with autoscale_on: deprecate it, or have it set autoscalex and
autoscaley together?

Thanks,
JDH

On Tue, 6 Sep 2005, John Hunter wrote:

[...]

> Hey Arnd,
>
> All of your suggestions look reasonable to me on cursory inspection,
> but the person best equipped to decide these things is Mark Bakker,
> who wrote the axes equal handling.  I've CC'd him on this message.

OK, I think the best is that Mark has a look at the CVS version
and our comments and then we will move on ...


[...]

> I have a couple of minor comments:
>
>     Arnd> While at this: I also don't like `autoscale_on` very much.
>     Arnd> I think that `autoscale` (being True or False) would be enough.
>
> I recall Fernando objecting to this too, so it must be particularly
> irritating.  My inclination for cosmetic things like this is to not
> break backwards compatibility for a slightly more pleasing name.

I can understand this, but on the other hand, we are at *0*.84,
so users should expect things to break when running < 1.0 software.
Also the breakage does not seem too bad to me.
Not changing it now means that it will also be in matplotlib 8.0
(and even in the upcoming MDE (Matplotlib Desktop Environment) ;-).

>     Arnd> And one more (just to complicate matters even more): At the
>     Arnd> moment there is only autoscaling for x and y at the same
>     Arnd> time. Gnuplot, for example, allows to specify the xrange or
>     Arnd> yrange separately and the other range is autoscaled.  I am
>     Arnd> mentionining this, because it might be a useful feature.
>     Arnd> (However, it might make the coding of the autoscaling even
>     Arnd> more involved...).
>
> I think this would be useful too.  We could implement autoscalex and
> autoscaley properties which would handle this.  I don't think the code
> would be particularly cumbersome.  Then the question is: what should
> be done with autoscale_on: deprecate it, or have it set autoscalex and
> autoscaley together?

I think `autoscale`  should imply `autoscalex` and `autoscaley`
(Note that I did not write `autoscale_on`,`autoscale_on_x`,
`autoscale_on_y` ;-).

Best,

Arnd

I was also interested in some sort of legend for scatter plots recently.

To that end I took a bit of a look at the legend code this am with a 
view to adding support for RegularPolyCollection's being passed in as 
handles for legends.

My idea was just to assume the first element in the collection is 
representative of the others and use that to create a suitable 
RegularPolyPatch to use as the handle.

I've not got it quite right as yet -- my current code produces a big 
blue blob in the middle of the plot.

Is it worth me fixing this up and sending in a patch?

John


John Hunter wrote:

>>>>>>"Jack" == Jack Andrews <ef...@iv...> writes:
>>>>>>            
>>>>>>
>
>    Jack> is there any more information you'd like to help me with
>    Jack> constructing a legend for this scatter?
>
>    Jack> i think i am misusing the scatter graph here...  letting
>    Jack> scatter assign colours from a continous selection rather
>    Jack> than specifying a color.
>
>Yes, you probably want to assign specific colors in multiple calls to
>scatter.  Scatter returns a
>matplotlib.collections.RegularPolyCollection, which legend is not
>equiped to deal with.  To hack around this, you can create a proxy
>patch to pass to legend, which has the colors you want to use for the
>legend
>
>from matplotlib.patches import Rectangle
>from pylab import *
>
>N=20
>
>props = dict( alpha=0.75, faceted=False )
>
>x, y= rand(2,N)
>s=array(([400]+[30]*(N/2-1))*2)
>reds  = scatter(x, y, c='red',   s=s, **props)
>
>x, y= rand(2,N)
>s=array(([400]+[30]*(N/2-1))*2)
>
>blues = scatter(x, y, c='blue', s=s, **props)
>
>redp = Rectangle( (0,0), 1,1, facecolor='red')
>bluep = Rectangle( (0,0), 1,1, facecolor='blue')
>
>legend( (redp, bluep), ('reds', 'blues') )
>grid(True)
>
>show()
>
>
>-------------------------------------------------------
>SF.Net email is Sponsored by the Better Software Conference & EXPO
>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>  
>

>>>>> "John" == John Gill <jn...@eu...> writes:

    John> I was also interested in some sort of legend for scatter
    John> plots recently.  To that end I took a bit of a look at the
    John> legend code this am with a view to adding support for
    John> RegularPolyCollection's being passed in as handles for
    John> legends.

    John> My idea was just to assume the first element in the
    John> collection is representative of the others and use that to
    John> create a suitable RegularPolyPatch to use as the handle.

    John> I've not got it quite right as yet -- my current code
    John> produces a big blue blob in the middle of the plot.

    John> Is it worth me fixing this up and sending in a patch?

I think so, the case of a solid colored scatter with varying sizes
seems sufficiently common to warrant legend support.

So a patch would be great, if you aren't too busy with the Katrina
aftermath these days ...

Thanks,
JDH

hi all,

back to my scattered circles, can you show me how =20
to center text (labels) inside the big circles =20
generated by this program (follows)?  help much =20
appreciated.

jack.


#!/usr/bin/env python
from pylab import *
N=3D5
def onecolor(c):
  x,y=3Drand(2,N)
  return scatter(x,y,c=3Dc,s=3Darray([600]+[30]*(N-1)))
[r,b]=3D[onecol(c) for c in 'red blue'.split()]
# find first of each sequence of patches and
# write 'red' in the red one (and 'blue' for blue)
grid(True)
show()

sorry, example contained syntax error...

On 21/09/05 15:11:16, Jack Andrews wrote:
> back to my scattered circles... can you show me =20
> how to center text (labels) inside the big =20
> circles generated by this program (follows)?  =20
> help much appreciated.

#!/usr/bin/env python
from pylab import *
N=3D5
def onecolor(c):
  x,y=3Drand(2,N)
  return scatter(x,y,c=3Dc,s=3Darray([600]+[30]*(N-1)))
[r,b]=3D[onecolor(c) for c in 'red blue'.split()]
# find first of each sequence of patches and
# write 'red' in the red one (and 'blue' for blue)
grid(True)
show()