matplotlib-users Mailing List for matplotlib (Page 3)

> >> The following minimal script reveals a rendering problem with
> >> displaying a histogram on a log vertical axis.

Has this been resolved yet? I'm running Matplotlib 0.87.5-2.2 on
Debian Unstable. I try to run the following script:

from pylab import *
hist(rand(100), 20)
ax = gca()
ax.set_yscale('log')
show()

And get the error:
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py",
line 284, in expose_event
    self._render_figure(self._pixmap, w, h)
  File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtkagg.py",
line 73, in _render_figure
    FigureCanvasAgg.draw(self)
  File "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py",
line 391, in draw
    self.figure.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line
538, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 1057, in draw
    a.draw(renderer)
  File "/usr/lib/python2.4/site-packages/matplotlib/patches.py", line
165, in draw
    tverts = self._transform.seq_xy_tups(verts)
ValueError: Domain error on nonlinear Transformation::seq_xy_tups
operator()(thisx, thisy)

The error is always reproducible, both from the console and the ipython console.

Any ideas?

On 7/22/06, Gary Ruben <gr...@bi...> wrote:
> More information on this bug: on my WinXP laptop, it seems to only
> manifest under some circumstances. When running the script from inside
> SciTE or ipython, it seems more or less repeatable (sometimes it won't
> show on the first run but does from then on), but if the .py file is run
> directly from the windows explorer, it doesn't show up. On my win98
> desktop, however, it shows up regardless.
>
> Gary Ruben wrote:
> > Note: I just verified that this was introduced into 0.87.4.
> > 0.87.3 doesn't exhibit the problem. See attachment.
> >
> > Gary R.
> >
> > gr...@bi... wrote:
> >> The following minimal script reveals a rendering problem with
> >> displaying a histogram on a log vertical axis.
> >> I'm using matplotlib0.87.4 in WinXP with python 2.3.5 Enthon.
> >>
> >> from pylab import *
> >> hist(rand(100), 20, bottom=1)
> >> setp(gca(), yscale="log")
> >> show()
> >>
> >>
> >> Gary R.

-- 
Web/Blog/Gallery: http://floatingsun.net/blog

On Sun, 2006-12-24 at 22:43 -0800,
mat...@li... wrote:
>         hi,
>         TypeError happened when I ran contour_demo.py -dGtkCairo,Can
>         anybody
>         tell me the reason? 
>         TypeError: surface_create_for_array() argument 1 must be
>         array, not
>         numpy.ndarray
>         
>         -
>         window xp
>         python24
>         matplotlib 0.87

The cairo backend was developed using Numeric and the problem you report
is triggered when using numpy. The TypeError has been fixed in SVN so it
should not be a problem in the next matplotlib release.

Running contour_demo.py works for figure 1,2,3 but figure 4 highlights
another problem.

Steve

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

On Wed, 2006-12-20 at 04:27 -0800,
mat...@li... wrote:
>         Hi there!
>         
>         I implemented a Print method with gtk-2.10 PrintOperations...
>         It was not
>         easy, because of some transformations issues inside
>         matplotlib...
>         
>         My wish is: The plot window navigation bar should provide a
>         print button
>         in future. I think many people are missing this button.
If I understand correctly you are suggesting that a new icon, "print the
figure" be added to the matplotlib toolbar, to function in a similar way
to the "File / Print .." menu on many other applications.
I don't do any printing myself so it does not affect me, but it looks
like a reasonable request. However, I didn't see any replies to your
mail so are there really many matplotlib people missing this button?

>         Here, I want to provide code for printing the screen, just
>         like the save
>         button on the navigation bar.
>         It is the merge of the save button's code and the code in
>         pygtk-2.10.1/examples/pygtk-demo/demos/print_editor.py
>         
>         Maybe, there is already a lot of print code available for
>         other GUI
>         backends, if it will be shared, it could become part of
>         matplotlib...
I think that GUI backend printing code will be GUI backend-specific and
not suitable to be shared among backends.

>         Yours, Achim
>         
>         (Sorry, I could not provide a running program, because I am
>         short in
>         time. The code is working in a bigger project
>         http://www.fkp.physik.tu-darmstadt.de/damaris/ )

Steve




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

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>     Eric> We did decide to make linewidth=0 suppress drawing the line,
>     Eric> and this is in the ps backend.  Most likely it is not in all
>     Eric> backends, but it is in pdf, svg, and agg as well as ps.  In
> 
> Would it not be better to catch this at the Artist level and either
> not make a call to the backend, or force the edgecolor=facecolor
> before calling the backend?  Then the backend can remain blissfully
> ignorant...

No, this strategy won't work for two reasons:

1) edgecolor=facecolor is not the same as not drawing the edge; it leads 
to artifacts that can be very damaging.

2) the backends implement patch rendering which inherently includes both 
the edge and the fill, so we can't avoid having mechanisms for telling 
the backend whether to stroke the former and/or paint the latter.

Eric

> 
> JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> We did decide to make linewidth=0 suppress drawing the line,
    Eric> and this is in the ps backend.  Most likely it is not in all
    Eric> backends, but it is in pdf, svg, and agg as well as ps.  In

Would it not be better to catch this at the Artist level and either
not make a call to the backend, or force the edgecolor=facecolor
before calling the backend?  Then the backend can remain blissfully
ignorant...

JDH

John Hunter wrote:

> Whether or not linewidth=0 is respected may be backend dependent.  In
> postscript it means use the smallest possible line.  We have discussed
> overriding this at the mpl level to impose consistency, but am not
> sure what the status of this is.  The safest best is to set the
> edgecolor and facecolor to be identical.

John,

We did decide to make linewidth=0 suppress drawing the line, and this is 
in the ps backend.  Most likely it is not in all backends, but it is in 
pdf, svg, and agg as well as ps.  In the ps backend it is in the 
_draw_ps() method, so unless there is a code path that does not use this 
method, it should work.

Sergio, I deleted your original message so I don't remember how much 
info you gave.  If linewidth=0 is not suppressing edge drawing and you 
are using mpl 0.87.7 or svn, then please provide a simple script 
illustrating the problem and say what backend and mpl version you are using.

Eric

>>>>> "Sergio" == Sergio Drumond Ventura <da...@gm...> writes:

    Sergio> Hi, I am a new user of matplotlib.  First of all I would
    Sergio> like to say that the people working on matplotlib is doing
    Sergio> a great job.

    Sergio> Well, I have tried to use the 'fill', but I cannot get rid
    Sergio> of the lines.  I have tried to use 'linewidth=0' at the
    Sergio> end, but it did not work.

    Sergio> Could somebody, please, tell me if I am doing something
    Sergio> wrong ?


Whether or not linewidth=0 is respected may be backend dependent.  In
postscript it means use the smallest possible line.  We have discussed
overriding this at the mpl level to impose consistency, but am not
sure what the status of this is.  The safest best is to set the
edgecolor and facecolor to be identical.

JDH

>>>>> "Steve" == Steve Kacenjar <kac...@co...> writes:

    Steve> Just installed FC6 onto AMD 64 bit processor and have
    Steve> installed Python.  I have also installed numpy and
    Steve> matplotlib however when I run IPython and begin importing
    Steve> items I run into a problem when try to import pylab.
    Steve> Specifically I receive the following dump:


    Steve> ImportError: No module named _ns_backend_gdk

Or a 2nd thought -- it may be that pygtk or the gtk-devel environment
was not in place when you built.  Even if they are installed,
matplotlib requires a connection to the X11 server when building the
gtk backend, something that is not always available when building as
root.

So 

  1) make sure you have the proper numpy installed, as in my previous
     post

  2) make sure you can do

     >>> import gtk

     in the same environment in which you are building and installing
     mpl

   3) make sure you have the gtk-devel headers and libs installed, as
      well as the other devel libs listed on the installing pages of
      the web site.

   4) capture stdout and stderr when you build, and post it if you
      encounter further problems

      > python setup.py build >& build.out

JDH

>>>>> "Steve" == Steve Kacenjar <kac...@co...> writes:

    Steve> Just installed FC6 onto AMD 64 bit processor and have
    Steve> installed Python.  I have also installed numpy and
    Steve> matplotlib however when I run IPython and begin importing
    Steve> items I run into a problem when try to import pylab.
    Steve> Specifically I receive the following dump:


    Steve> ImportError: No module named _ns_backend_gdk

    Steve> I am new to this and would appreciate any help in resolving
    Steve> this problem.  Thanks.

this looks like numpy was not available at compile time.  Make sure
you have a compatible numpy and mpl (eg the latest release of both or
the latest svn of both) and then do a clean build (eg 'rm -rf build').

JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I don't think so--at least, I have not figured it out after
    Eric> a few minutes of looking around and trying to understand how
    Eric> things work.  I think polar plotting needs quite a bit of
    Eric> work.  In particular, I suspect the lack of a "set_rmax"
    Eric> method is not an oversight but a consequence of limitations
    Eric> in the present implementation. I will look at it some more
    Eric> and see if I can improve it.  This might be long-term, not
    Eric> quick.

In the next month or so I plan to spend some time fixing up the
limitations of polar, so I'll flag this and take a look at it then.

JDH

>>>>> "Edin" == Edin Salkovic <edi...@gm...> writes:

    Edin> Hi, I'm having problems with building mpl from SVN on WinXP,
    Edin> Python 2.5, latest numpy.  I'm using MinGW from the
    Edin> enthought edition.  I remember building it without problems
    Edin> just few weeks ago.  The build process finishes without
    Edin> error.  Then, when I try:

    Edin> from pylab import *

    Edin> it crashes

    Edin> import matplotlib


Did you rm -rf your build dir (and sometimes site-packages/matplotlib)
before rebuilding.  This is usually the cause of such crashes.

JDH

Has anyone tried freezing matplotlib embedded in a wx app (using py2ece,
cx_freeze or pyinstaller)? The setup.py in the FAQ seems to be outdated. I
want to freeze the embedding_in_wx.py in the examples. Do you have any
suggestions or cookbook steps that I can follow?

> contourf is not drawing in raster mode--it is generating filled=20
> polygons.  What you are seeing is the fact that when it follows the edge=
=20
> of a masked region, it does so in a stairstep fashion.  This is inherent=
=20
> in the algorithm being used.

it seems that the filled polygon is composed of a set of points in some
a contour and some points in the 'drawn' edge which offsets with the
real edge of a masked region.=20


> I have thought a little bit about ways of=20
> making it at least take a diagonal path when reasonable so as to reduce=
=20
> the jaggy effect.  I am not at all sure it would be worth the trouble,=20
> though--I expect it would be a lot of work for only a little gain.

I do think that matplotlib can do a very good job now. the same time i
think it's valuable to take some time to work out this little flaw.
maybe there're some tricky methods.
1) make a contourf plot on the whole rectangle mesh with no mask.
2) make a mask picture of the same size with the contourf plot. black in
mask ploygon and white outside.
3) do AND operation on contourf plot and the mask picture and outside
the mask polygon will be clipped.

x,y is axes array.
z is mesh grid data array.
zz is mesh grid data array with mask.
p is polygon for the edge.

cs=3Dcontourf(x,y,z)          ----> contourf plot,identifies A.=20
cs2=3Dcontour(x,y,zz) =20
clabel(cs2,....) --> label at the right position inside the mask polygon.
draw_polygon(p,fillcolor=3Dblack)  --> make a mask picture of the same
                                          size with A,identifies B.
A and B drawing.   ---> it seems that cairo and agg can do this.
                        i don't know how to do in matplotlib.but i'm
                        sure some functions work for it.

there's no need to change the mask array when we zoom the picture now
because the mask picture is redrawn dynamicaly and 'vectorly'
=2E


>=20
> To get around this you may want to use some interpolation/extrapolation=
=20
> to extend your data one grid point into the masked region, then contour=
=20
> with the reduced masked region, then plot your own filled polygon on top=
=20
> of the contour plot to define the masked region more precisely to your=20
> taste.

yes,filled contour map with smooth edge can be drawn with a more high
resolution mask array given.it's not a hard job.However,there's some
disadvantages in this way.firstly,mask array will have much larger size
than before and x,y arrays will be enlarged.these steps should be
repeated every time we wanna zoom the picture.


> Yes, I agree that this is a pain, and that the present contour/contourf=
=20
> routine is not ideal (although it is very clever and I suspect very=20
> fast).  If you can find a better filled contour routine with a BSD-style=
=20
> license, or even a clear and complete description of a superior=20
> algorithm that could be implemented without running into copyright or=20
> patent problems, please point it out to us.
>=20
> There is one interesting difference between the algorithm we use (taken=
=20
> from the gist package) and the one used by Matlab: ours generates=20
> polygons that enclose only a given level--polygons do not=20
> overlap--whereas Matlab's generates polygons that stack.  As a result,=20
> ours is suitable for use with alpha blending, whereas Matlab's is not=20
> (last time I looked, anyway).

> Eric

would you like to add some more interpolation algorithm such as kriging
ect.to matplotlib? there are many interpolation source codes in public.

shu



--=20
 <>

On Monday 25 December 2006 01:30, Eric Firing wrote:
> I don't think so--at least, I have not figured it out after a few
> minutes of looking around and trying to understand how things work.  I
> think polar plotting needs quite a bit of work.  

Sorry for hijacking the thread, but a few months ago I suggested the 
possibility to subclass Subplot. I have a small 
function, 'add_generic_subplot', which just implements this possibility. 
Would anybody be interested ? In that case, a Polarplot would just be a 
particular subclass of Subplot. If there's some heavy cleaning to be done on 
Polar, it might be worth to consider subclassing.
[I realize this was quite a useless post... Sorry again]

Miles Lubin wrote:
> Solved the problems, thanks.
> 
> 
> Another issue has come up. After looking through 
> http://matplotlib.sourceforge.net/matplotlib.axes.html#PolarAxes, I see 
> a  get_rmax() function, but there is no corresponding set_rmax(). Using 
> set_ylim() causes hanging when it attempts to graph, and set_xlim is 
> currently unimplemented. Is there a simple way to set rmax?

I don't think so--at least, I have not figured it out after a few 
minutes of looking around and trying to understand how things work.  I 
think polar plotting needs quite a bit of work.  In particular, I 
suspect the lack of a "set_rmax" method is not an oversight but a 
consequence of limitations in the present implementation. I will look at 
it some more and see if I can improve it.  This might be long-term, not 
quick.

Eric

> 
> Thanks,
> 
> Miles
> 
> **
> 
> 
> Eric Firing wrote:
> 
>>
>> polar(theta, r)
>> gca().set_thetagrids([])
>>
>>
>> If they are all the same kind of points--all markers, for 
>> example--then I would expect the rendering order to be the plot 
>> command order, because each plot command adds a line to a list of 
>> lines to be rendered.  You can control the level using the zorder 
>> attribute.
>>
>> lines = polar(theta, r, zorder=2.5)
>>
>> or
>>
>> lines = polar(theta, r, theta2, r2)
>> zo = lines[0].get_zorder()
>> lines[0].set_zorder(zo+0.1)
>>
>>
>> Eric
>>
>>
>>
> 

Solved the problems, thanks.


Another issue has come up. After looking through 
http://matplotlib.sourceforge.net/matplotlib.axes.html#PolarAxes, I see 
a  get_rmax() function, but there is no corresponding set_rmax(). Using 
set_ylim() causes hanging when it attempts to graph, and set_xlim is 
currently unimplemented. Is there a simple way to set rmax?

Thanks,

Miles

**


Eric Firing wrote:

>
> polar(theta, r)
> gca().set_thetagrids([])
>
>
> If they are all the same kind of points--all markers, for 
> example--then I would expect the rendering order to be the plot 
> command order, because each plot command adds a line to a list of 
> lines to be rendered.  You can control the level using the zorder 
> attribute.
>
> lines = polar(theta, r, zorder=2.5)
>
> or
>
> lines = polar(theta, r, theta2, r2)
> zo = lines[0].get_zorder()
> lines[0].set_zorder(zo+0.1)
>
>
> Eric
>
>
>

Miles Lubin wrote:
> Hi,
> 
> 
> I would like to be able to remove the dotted straight lines on the polar 
> axes, but keep the dotted circular lines (not sure of the technical 
> names, sorry). I also want to remove the degree measurement labels since 
> they are not meaningful for the data that I am displaying.
> 
> How would I go about doing this?

polar(theta, r)
gca().set_thetagrids([])

> 
> 
> Also, is there any reason why certain points would be behind (i.e. 
> covered by) points that were plotted before them?
> 

If they are all the same kind of points--all markers, for example--then 
I would expect the rendering order to be the plot command order, because 
each plot command adds a line to a list of lines to be rendered.  You 
can control the level using the zorder attribute.

lines = polar(theta, r, zorder=2.5)

or

lines = polar(theta, r, theta2, r2)
zo = lines[0].get_zorder()
lines[0].set_zorder(zo+0.1)


Eric


> 
> Thanks,
> 
> Miles
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,


I would like to be able to remove the dotted straight lines on the polar 
axes, but keep the dotted circular lines (not sure of the technical 
names, sorry). I also want to remove the degree measurement labels since 
they are not meaningful for the data that I am displaying.

How would I go about doing this?


Also, is there any reason why certain points would be behind (i.e. 
covered by) points that were plotted before them?


Thanks,

Miles

shu...@16... wrote:
> Hi,
> matplotlib can make a contour plot on a masked array z using
> contourf(x,y,z).but it seems that it draws in a raster mode.there is
> sawtooth at the edge of the picture when it is zoomed.can contour be
> drawed in a vector mode? i means that
> 1) give an array z which has not been masked.
> 2) contourf
> 3) using a ploygon array as a mask instead of using a masked grid array.
> the part out of the polygon will be clipped.it seems that cairo and agg can
> both work in this way.

contourf is not drawing in raster mode--it is generating filled 
polygons.  What you are seeing is the fact that when it follows the edge 
of a masked region, it does so in a stairstep fashion.  This is inherent 
in the algorithm being used.  I have thought a little bit about ways of 
making it at least take a diagonal path when reasonable so as to reduce 
the jaggy effect.  I am not at all sure it would be worth the trouble, 
though--I expect it would be a lot of work for only a little gain.

To get around this you may want to use some interpolation/extrapolation 
to extend your data one grid point into the masked region, then contour 
with the reduced masked region, then plot your own filled polygon on top 
of the contour plot to define the masked region more precisely to your 
taste.

Yes, I agree that this is a pain, and that the present contour/contourf 
routine is not ideal (although it is very clever and I suspect very 
fast).  If you can find a better filled contour routine with a BSD-style 
license, or even a clear and complete description of a superior 
algorithm that could be implemented without running into copyright or 
patent problems, please point it out to us.

There is one interesting difference between the algorithm we use (taken 
from the gist package) and the one used by Matlab: ours generates 
polygons that enclose only a given level--polygons do not 
overlap--whereas Matlab's generates polygons that stack.  As a result, 
ours is suitable for use with alpha blending, whereas Matlab's is not 
(last time I looked, anyway).

Eric

Hi,
matplotlib can make a contour plot on a masked array z using
contourf(x,y,z).but it seems that it draws in a raster mode.there is
sawtooth at the edge of the picture when it is zoomed.can contour be
drawed in a vector mode? i means that
1) give an array z which has not been masked.
2) contourf
3) using a ploygon array as a mask instead of using a masked grid array.
the part out of the polygon will be clipped.it seems that cairo and agg can
both work in this way.


shu
-- 
 <>

Hi,

I'm having problems with building mpl from SVN on WinXP, Python 2.5,
latest numpy.  I'm using MinGW from the enthought edition.  I remember
building it without problems just few weeks ago.  The build process
finishes without error.  Then, when I try:

from pylab import *

it crashes

import matplotlib

doesn't crash

I also had problems with Python 2.4

Best,
Edin

I have verified that this occurs also on svn mpl with Linux,

In [4]:cairo.cairo_version_string()
Out[4]:'1.2.4'

The immediate solution is to use a different backend.

Eric


shu...@16... wrote:
> hi,
> TypeError happened when I ran contour_demo.py -dGtkCairo,Can anybody
> tell me the reason? 
> TypeError: surface_create_for_array() argument 1 must be array, not
> numpy.ndarray
> 
> -
> window xp
> python24
> matplotlib 0.87
> 
> 
> 

hi,
TypeError happened when I ran contour_demo.py -dGtkCairo,Can anybody
tell me the reason? 
TypeError: surface_create_for_array() argument 1 must be array, not
numpy.ndarray

-
window xp
python24
matplotlib 0.87



-- 
 <>

Armando Serrano Lombillo wrote:
> Hello,
> 
> I have installed matplotlib 0.87.7 (with the standard windows exe). If I 
> use the provided matplotlibrc file I get errors complaining about the 
> following lines:
> 
> lines.markerfacecolor  : blue
> lines.markeredgecolor   : black
> 
> Commenting them out stops the problem and matplotlib seems to run fine. 
> Am I the only one getting this errors? Is this already known? Should I 
> worry about it?

No, you did the right thing and it is nothing to worry about. I don't 
specifically recall the matplotlibrc file being out of sync in this 
distribution, but there have been big changes in the matplotlibrc file 
in svn so there is not much point in tracking down the problem in 
0.87.7.  It is harmless.

Eric

> On Fri, Dec 22, 2006 at 02:15:42PM -0500, Alan G Isaac wrote: 
>> Just because the figure window is closed does not 
>> mean the figure is deleted.  Chris apparently 
>> maintains a reference to the figure? 

On Fri, 22 Dec 2006, ch...@se... apparently wrote:
> I just save a PNG on hard drive and load it when needed.  I don't know 
> how to store a reference to PNG and/or if that would be a problem. 


All this is happening before your (final) save to the PNG 
file.  Somehow you are telling Matplotlib to plot repeatedly
to the same figure even though you want it to plot to 
different figures, if I have understood you.

If all else fails as you search for how you are doing this, 
try explicitly naming each figure:

fig1 = pylab.figure(figsize=(figw,figh))
ax1 = fig.gca()
ax1.plot(x,y, 'k', label="My Title")
fig1.savefig(workdir+'\\'+file_name)

Cheers,
Alan Isaac