matplotlib-users Mailing List for matplotlib

It works on my machine (linux) with svn, but I don't see anything about 
this in CHANGELOG.

Eric

Eric Emsellem wrote:
> hi,
> 
> I am trying to have text written on 2 lines, but everything is written
> on a single line. Is that normal?
> 
> here is an example:
> 
> plot(arange(10))
> ylabel('this is vertical \n test')
> text(0.5,0.5,"this is a test \n but does not work")
> 
> thanks
> Eric
> =======================
> Suse 10.1
> matplotlib version 0.87.7
> numerix numpy 1.0.2.dev3491
> Python 2.4.2 (#1, May  2 2006, 08:13:46)
> IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python.
> 
> 
> -------------------------------------------------------------------------
> 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 am trying to have text written on 2 lines, but everything is written
on a single line. Is that normal?

here is an example:

plot(arange(10))
ylabel('this is vertical \n test')
text(0.5,0.5,"this is a test \n but does not work")

thanks
Eric
=======================
Suse 10.1
matplotlib version 0.87.7
numerix numpy 1.0.2.dev3491
Python 2.4.2 (#1, May  2 2006, 08:13:46)
IPython 0.7.4.svn.r2010 -- An enhanced Interactive Python.

John,

Thank you for your thorough and thoughtful reply. OK, I am convinced.  I 
had not realized that the present line-drawing code actually is omitting 
nonpositive points, but now I see the Line.get_plottable() method.

I have committed changes to svn that I think will be helpful--maybe good 
enough for now.  From the CHANGELOG:

2006-12-28 Improved error message for nonpositive input to log
            transform; added log kwarg to bar, barh, and hist,
            and modified bar method to behave sensibly by default
            when the ordinate has a log scale.  (This only works
            if the log scale is set before or by the call to bar,
            hence the utility of the log kwarg.) - EF

Examples:

This makes a sensible plot that behaves well under zooming and panning:
hist(randn(1000), log=True)
show()


The following still generates an exception:
hist(randn(1000))
gca().set_yscale('log')
show()

but the traceback is more informative and ends with:

/usr/local/lib/python2.4/site-packages/matplotlib/patches.py in 
draw(self, renderer)
     183
     184         verts = self.get_verts()
--> 185         tverts = self.get_transform().seq_xy_tups(verts)
     186
     187         renderer.draw_polygon(gc, rgbFace, tverts)

ValueError: Cannot take log of nonpositive value

I have not put in any form of your suggested addition to set_yscale and 
set_xscale.  Maybe I should, but I am hoping that the changes above are 
sufficient.

Eric



John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
> 
>     Eric>   Adjusting zero and negative values (or maybe just zero)
>     Eric> would be unacceptable in a numerics library, but in the
>     Eric> context of our graphical transforms it is analogous to
>     Eric> clipping, and this we do all the time--we don't raise an
>     Eric> exception if someone tries to plot outside the box. (This
>     Eric> clipping strategy to handle nonpositive values is present
>     Eric> already in the LogLocator.)
> 
> I'm more comfortable dropping points than I am altering the data.
> Consider some use case like
> 
>   ax.hist(...)
>   rect = Rectangle(...)
>   ax.add_patch(rect)
>   ax.set_xscale('log')
> 
> In set_xscale we only see a bunch of rectangles.  User defined
> rectangles may be used to store data (eg the JPL uses custom bars with
> xlimits that are the start and stop times when orbiting spacecraft are
> within view of a ground station).  Some of these users will also want
> to "pick" the rectangle and inspect the data values.  If we are
> altering them, they have no guarantee that what they put in is what
> they get out.  Now we might argue that they get what they deserve if
> they are using invalid data for a log scale, but one good solution in
> my view is to fail noisily with helpful messages, and provide an easy
> interface to do it right.
> 
> But if I am missing your point or you have an implementation that will
> address these concerns, I'm certainly open to them.  One possibility
> is to flag artists that we create internally (eg hist) and take more
> liberty with these, or have some flag like the Artist "clip_on"
> property which allows the user to control whether their data is
> mutable to support "helpful" alterations for log or other
> transformations.
> 
>     Eric> We can use such a small adjustment value that a problem such
>     Eric> as you mention above is highly unlikely--and note that
>     Eric> floating point itself has limitations, and does not permit
>     Eric> arbitrarily small or large numbers. Furthermore, note that
> 
>     Eric> the user can always take advantage of the bottom kwarg.  And
>     Eric> if in some extreme case the user has not used the bottom
>     Eric> kwarg and the bars really are shorter than the adjustment
>     Eric> value, it will probably be quite obvious.
> 
> The other thing to think about is choosing a bottom so that the
> natural range of the tops is revealed.  Eg if the bottom is 1e-200,
> all the bars will appear the same height in many cases.
> 
>     Eric> It is in ordinary line plotting that adjusting the value
>     Eric> could be misleading--it plots an extremely small number (if
>     Eric> the data limits are set to include it) instead of zero.
>     Eric> Maybe this is enough of a drawback to nix the whole idea.
> 
> I am happy with the current behavior of culling the non-positive
> points.  matlab does it and noone has complained here.  There is a
> difference in lines created with "plot" and bars created with hist: in
> the former case the users explicitly picked the x,y points.  In the
> latter they implicitly do so with a default bottom kwarg that they may
> have overlooked.  This suggests to me that we need not treat the two
> cases the same.
> 
>     Eric> Every alternative that you propose is more complicated and
>     Eric> less comprehensive than the low-level adjustment, however,
>     Eric> and I see little if any real advantage to the alternatives.
> 
> If you would like to take a stab at an implementation I am happy to be
> persuaded (with caveats below).  In the simple case of
> 
>   ax.hist()
>   ax.set_xscale('log')
> 
> this would indeed be fairly easy because you know how the data were
> created.  In the general case where the user has added lots-o-patches
> to the axes, it may not be easy to do well.  I'm still inclined to the
> "explicit is better than implicit" and either require them to do one of
> 
>   1) use the bottom kwarg
>  
>   2) set log scaling before calling hist -- we can make the default
>      bottom=None and do different things for linear and log scaling
> 
>   3) use a loghist function
> 
>     Eric> If you still don't want the adjustment, then the easiest way
>     Eric> to improve the error message would be to raise a Python
>     Eric> exception instead of a c++ error in places like
> 
>     Eric>          for(int i=0; i < length; i++) { if (x<=0) { throw
>     Eric> std::domain_error("Cannot take log of nonpositive value"); }
>     Eric> else newx[i] = log10(x[i]);
>     Eric>          }
> 
>     Eric> The domain error message above is informative, but it never
>     Eric> makes it out to the user.
> 
> I really don't feel too strongly about this -- my gut reaction is that
> a helpful message and an easy way to fix it is enough and it won't get
> us into a possible quagmire of trying to be too smart.  Personally, I
> don't like it when computers try to be too helpful (think MS windows
> and clippy); I like it when they do what I tell them to do.  With the
> snippet I posted previously we can easily warn them before doing the
> transformation and with bottom=None we can handle the case when the
> log scale is set before the call to hist.  That in conjunction with
> some additional docstrings in hist should work reasonably well.
> 
> That said, if you want to try something more ambitious I won't get in
> your way.  I recommend at a minimum that you have some artist flag
> that governs whether mpl can make helpful data alterations (just as we
> do with clip) so the power user can turn it off.
> 
> JDH

Chris Pettit wrote:
> Thanks in advance to anyone who can help. This is my first extended  
> attempt to make matplotlib work, and I'm relatively new to the whole  
> Python world. I have MacPython2.4 running now, which seems to work  
> fine. I installed everything for matplotlib, scipy, etc., from the  
> Mac OS 10.4 SciPy Superpack binaries, so I didn't expect to have much  
> trouble, but I get the following when I try to import pylab:
>
>  >>> from pylab import *
> Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/pylab.py", line 1, in ?
>      from matplotlib.pylab import *
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/matplotlib/pylab.py", line 202, in ?
>      from axes import Axes, PolarAxes
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/matplotlib/axes.py", line 15, in ?
>      from axis import XAxis, YAxis
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/matplotlib/axis.py", line 25, in ?
>      from font_manager import FontProperties
>    File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/matplotlib/font_manager.py", line 39, in ?
>      from matplotlib import ft2font
> ImportError: Failure linking new module: /Library/Frameworks/ 
> Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/ 
> ft2font.so: Symbol not found: _FMDisposeFontFamilyIterator
>    Referenced from: /usr/local/lib/libfreetype.6.dylib
>    Expected in: flat namespace
>
>
> I saw a couple of posts about problems caused by libfreetype in the  
> most recent Apple X11 update, so I tried reinstalling Freetype2 from  
> souce and ended up with libfreetype6.3.10 in my /usr/local/lib. I  
> tried moving this to my /usr/X11R6/lib and resetting the symbolic  
> links to point to this, but no luck.
>
> Any advice?
>
> Thanks,
> Chris Pettit
>
>   

Chris:  Do you have  /usr/local/lib/libfreetype.6.dylib?  (it should be 
a symlink to /usr/local/lib/libfreetype.6.3.dylib)
If you do, I imagine that your version of libfreetype is old and doesn't 
have  the _FMDisposeFontFamilyIterator  symbol.

You could try setting the /usr/local/lib/libfreetype.6.dylib symlink to 
point to /usr/X11R6/lib/libfreetype.6.3.x.dylib.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Thanks in advance to anyone who can help. This is my first extended  
attempt to make matplotlib work, and I'm relatively new to the whole  
Python world. I have MacPython2.4 running now, which seems to work  
fine. I installed everything for matplotlib, scipy, etc., from the  
Mac OS 10.4 SciPy Superpack binaries, so I didn't expect to have much  
trouble, but I get the following when I try to import pylab:

 >>> from pylab import *
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/pylab.py", line 1, in ?
     from matplotlib.pylab import *
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/pylab.py", line 202, in ?
     from axes import Axes, PolarAxes
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/axes.py", line 15, in ?
     from axis import XAxis, YAxis
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/axis.py", line 25, in ?
     from font_manager import FontProperties
   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/font_manager.py", line 39, in ?
     from matplotlib import ft2font
ImportError: Failure linking new module: /Library/Frameworks/ 
Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/ 
ft2font.so: Symbol not found: _FMDisposeFontFamilyIterator
   Referenced from: /usr/local/lib/libfreetype.6.dylib
   Expected in: flat namespace


I saw a couple of posts about problems caused by libfreetype in the  
most recent Apple X11 update, so I tried reinstalling Freetype2 from  
souce and ended up with libfreetype6.3.10 in my /usr/local/lib. I  
tried moving this to my /usr/X11R6/lib and resetting the symbolic  
links to point to this, but no luck.

Any advice?

Thanks,
Chris Pettit

Petr Danecek wrote:
> Hello,
> first of all: thanks for the great software!! After the years of
> struggling with gnuplot, i really enjoy making my graphs with
> matplotlib.
>
> I'd like to ask, if it is possible to create a contour graph using polar
> coordinates? If not, can someone give me some pointers about how to
> implement it? 
>
> Kind regards,
> Petr Danecek
>
>
>   
Here's a slightly prettier version of my previous example:

from pylab import *
deltatheta = 2.*pi/100.
theta = arange(0.,2.*pi+0.5*deltatheta,deltatheta)
R = arange(0.,pi,deltatheta)
r,t = meshgrid(R, theta)
Z = sin(r)*sin(3.*t)
X = r*cos(t)
Y = r*sin(t)
ax = subplot(111)
cs = ax.contourf(X,Y,Z)
# make sure aspect ratio preserved
ax.set_aspect('equal')
# turn off rectangular frame.
ax.set_frame_on(False)
# turn off axis ticks.
ax.set_xticks([])
ax.set_yticks([])
# draw a circle around the edge of the plot.
rmax = max(R)
ax.plot(rmax*cos(theta),rmax*sin(theta),'k')
title('Polar contours')
show()

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Petr Danecek wrote:
> Hello,
> first of all: thanks for the great software!! After the years of
> struggling with gnuplot, i really enjoy making my graphs with
> matplotlib.
>
> I'd like to ask, if it is possible to create a contour graph using polar
> coordinates? If not, can someone give me some pointers about how to
> implement it? 
>
> Kind regards,
> Petr Danecek
>
>   

Petr:  I don't think contour directly supports polar axes, but if your 
data are in polar coordinates you can easily make a contour plot with 
cartesian axes, like this:

from pylab import *
deltatheta = 2.*pi/100.
theta = arange(0.,2.*pi,deltatheta)
R = arange(0.,pi,deltatheta)
r,t = meshgrid(R, theta)
Z = sin(r)*sin(3.*t)
X = r*cos(t)
Y = r*sin(t)
cs = contourf(X,Y,Z)
show()


-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Hello,
first of all: thanks for the great software!! After the years of
struggling with gnuplot, i really enjoy making my graphs with
matplotlib.

I'd like to ask, if it is possible to create a contour graph using polar
coordinates? If not, can someone give me some pointers about how to
implement it? 

Kind regards,
Petr Danecek

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

    Eric>   Adjusting zero and negative values (or maybe just zero)
    Eric> would be unacceptable in a numerics library, but in the
    Eric> context of our graphical transforms it is analogous to
    Eric> clipping, and this we do all the time--we don't raise an
    Eric> exception if someone tries to plot outside the box. (This
    Eric> clipping strategy to handle nonpositive values is present
    Eric> already in the LogLocator.)

I'm more comfortable dropping points than I am altering the data.
Consider some use case like

  ax.hist(...)
  rect = Rectangle(...)
  ax.add_patch(rect)
  ax.set_xscale('log')

In set_xscale we only see a bunch of rectangles.  User defined
rectangles may be used to store data (eg the JPL uses custom bars with
xlimits that are the start and stop times when orbiting spacecraft are
within view of a ground station).  Some of these users will also want
to "pick" the rectangle and inspect the data values.  If we are
altering them, they have no guarantee that what they put in is what
they get out.  Now we might argue that they get what they deserve if
they are using invalid data for a log scale, but one good solution in
my view is to fail noisily with helpful messages, and provide an easy
interface to do it right.

But if I am missing your point or you have an implementation that will
address these concerns, I'm certainly open to them.  One possibility
is to flag artists that we create internally (eg hist) and take more
liberty with these, or have some flag like the Artist "clip_on"
property which allows the user to control whether their data is
mutable to support "helpful" alterations for log or other
transformations.

    Eric> We can use such a small adjustment value that a problem such
    Eric> as you mention above is highly unlikely--and note that
    Eric> floating point itself has limitations, and does not permit
    Eric> arbitrarily small or large numbers. Furthermore, note that

    Eric> the user can always take advantage of the bottom kwarg.  And
    Eric> if in some extreme case the user has not used the bottom
    Eric> kwarg and the bars really are shorter than the adjustment
    Eric> value, it will probably be quite obvious.

The other thing to think about is choosing a bottom so that the
natural range of the tops is revealed.  Eg if the bottom is 1e-200,
all the bars will appear the same height in many cases.

    Eric> It is in ordinary line plotting that adjusting the value
    Eric> could be misleading--it plots an extremely small number (if
    Eric> the data limits are set to include it) instead of zero.
    Eric> Maybe this is enough of a drawback to nix the whole idea.

I am happy with the current behavior of culling the non-positive
points.  matlab does it and noone has complained here.  There is a
difference in lines created with "plot" and bars created with hist: in
the former case the users explicitly picked the x,y points.  In the
latter they implicitly do so with a default bottom kwarg that they may
have overlooked.  This suggests to me that we need not treat the two
cases the same.

    Eric> Every alternative that you propose is more complicated and
    Eric> less comprehensive than the low-level adjustment, however,
    Eric> and I see little if any real advantage to the alternatives.

If you would like to take a stab at an implementation I am happy to be
persuaded (with caveats below).  In the simple case of

  ax.hist()
  ax.set_xscale('log')

this would indeed be fairly easy because you know how the data were
created.  In the general case where the user has added lots-o-patches
to the axes, it may not be easy to do well.  I'm still inclined to the
"explicit is better than implicit" and either require them to do one of

  1) use the bottom kwarg
 
  2) set log scaling before calling hist -- we can make the default
     bottom=None and do different things for linear and log scaling

  3) use a loghist function

    Eric> If you still don't want the adjustment, then the easiest way
    Eric> to improve the error message would be to raise a Python
    Eric> exception instead of a c++ error in places like

    Eric>          for(int i=0; i < length; i++) { if (x<=0) { throw
    Eric> std::domain_error("Cannot take log of nonpositive value"); }
    Eric> else newx[i] = log10(x[i]);
    Eric>          }

    Eric> The domain error message above is informative, but it never
    Eric> makes it out to the user.

I really don't feel too strongly about this -- my gut reaction is that
a helpful message and an easy way to fix it is enough and it won't get
us into a possible quagmire of trying to be too smart.  Personally, I
don't like it when computers try to be too helpful (think MS windows
and clippy); I like it when they do what I tell them to do.  With the
snippet I posted previously we can easily warn them before doing the
transformation and with bottom=None we can handle the case when the
log scale is set before the call to hist.  That in conjunction with
some additional docstrings in hist should work reasonably well.

That said, if you want to try something more ambitious I won't get in
your way.  I recommend at a minimum that you have some artist flag
that governs whether mpl can make helpful data alterations (just as we
do with clip) so the power user can turn it off.

JDH

Hi Steve!

Yes, that's right. Most of the people will help themselves with saving
the picture and then printing by an arbitary program.

On Linux I would implement printing via pipelines to lp, but on Windows
I have no clue how to get the job done. So I was glad to find the
PrintOperations for GTK2 (>=2.10), which were portable to different OS
supported by GTK.

For a print button in matplotlib it is necessary to find implementations
for other widget sets:
 * tk
 * wx
 * qt
I expect, that there is enough support for printing in qt, but I do not
know anything about tk or wx.

My code is just a starter for this process... or at least a try.

Yours, Achim


Steve Chaplin wrote:
> 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?
>   

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
> 
>     Eric> Oops, I replied to your previous message before seeing this
>     Eric> one.  Still, the larger question remains: maybe we should do
>     Eric> something to make it easier for users to understand what is
>     Eric> going on when the transform chokes on log(0).  Changing
>     Eric> numbers <=0 to a small positive number and issuing a warning
>     Eric> would accomplish this, and I don't see much disadvantage.
> 
> This is tricky to implement in practice.  Eg, what if the user did a
> bar graph where the heights were order 1e-10?  Without knowing what
> the user intended when creating the graphics primitives it is
> difficult to know what to do with them.  I am hesitant to alter data
> at the level of graphics primitives without knowing the operation that
> created them.  One possible solution may be to simply create a

John,

  Adjusting zero and negative values (or maybe just zero) would be 
unacceptable in a numerics library, but in the context of our graphical 
transforms it is analogous to clipping, and this we do all the time--we 
don't raise an exception if someone tries to plot outside the box. 
(This clipping strategy to handle nonpositive values is present already 
in the LogLocator.)

We can use such a small adjustment value that a problem such as you 
mention above is highly unlikely--and note that floating point itself 
has limitations, and does not permit arbitrarily small or large numbers. 
  Furthermore, note that the user can always take advantage of the 
bottom kwarg.  And if in some extreme case the user has not used the 
bottom kwarg and the bars really are shorter than the adjustment value, 
it will probably be quite obvious.

It is in ordinary line plotting that adjusting the value could be 
misleading--it plots an extremely small number (if the data limits are 
set to include it) instead of zero.  Maybe this is enough of a drawback 
to nix the whole idea.

Every alternative that you propose is more complicated and less 
comprehensive than the low-level adjustment, however, and I see little 
if any real advantage to the alternatives.


> helper function (loghist, logbar) which works like semilogx: it knows
> what the user wants to do and does the right thing, in this case
> making sure that the "bottom" of the rectangles is some suitable
> positive number less than all the heights.
> 
> I definitely agree that the error message is not terribly helpful.

If you still don't want the adjustment, then the easiest way to improve 
the error message would be to raise a Python exception instead of a c++ 
error in places like

         for(int i=0; i < length; i++)
         {
                 if (x<=0) { throw std::domain_error("Cannot take log of 
nonpositive value"); }
                 else newx[i] = log10(x[i]);
         }

The domain error message above is informative, but it never makes it out 
to the user.

It looks like one variation on my suggestion--warning when adjusting a 
nonpositive value--would be difficult to implement.

Eric


> One possibility is to inspect most of the objects at set_xscale and
> set_yscale and issue a warning if there is non-positive data. 
> 
> Eg: 'one or more patches has a non-positive y coordinate'
> 
> This won't be too helpful for mpl newbies who don't know what a patch
> is, but it will provide some additional information (at the expense of
> inspecting all the data at scale changes)
> 
> Something like
> 
> if xscale=='log': 
>    for line in self.lines:
>        xdata = line.get_xdata(valid_only = True)
>        if min(xdata)<=0.:
>            warn on lines and break
>    
>    for patch in self.patches:
>        if min([x for x,y in patch.get_verts()])<=0.: 
>            warn on patches and break         
> 
>    for collection in self.collections:
>        if min([x for x,y in collection.get_verts()])<=0.:
>             warn on collections and break
> 
> 
> JDH