matplotlib-users Mailing List for matplotlib (Page 2)

ok thanks for the check. Since it seems like a personal setting pb, I
have now restarted from a clean matplotlibrc and set up my prefered option.
It now works (no clue why it didn't...)

sorry for the trouble and thanks for doing that test.
cheers
Eric

Eric Firing wrote:
> 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.
>>
>>

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> either, indistinguishably from the way it does now.  The
    Eric> problem is that with a linear axis we want the axis to start
    Eric> at zero by default, but with a log axis we want it to start

With ymin at 1e-100, the default (linear) locator should choose 0 as
ymin.  If it doesn't it looks like a bug.  Is either the log or linear
autoscaler broken for bottom=something-really-small ?

JDH

Diwaker Gupta wrote:
>> Examples:
>>
>> This makes a sensible plot that behaves well under zooming and panning:
>> hist(randn(1000), log=True)
>> show()
> 
> Thanks! However...
> 
>> The following still generates an exception:
>> hist(randn(1000))
>> gca().set_yscale('log')
>> show()
> 
> I think this makes the API more confusing. As an end user, I want the
> API to be consistent and intuitive. Its weird if I can set log scale
> after all plot commands, but not after calling hist. And yet, log
> scale DOES work with that keyword arg. I might even think things were
> broken had I not been following this thread.
> 
> Anyways, thanks for looking into this!

I agree that it is not optimal, but I have not figured out any simple 
way of making bar (which is the underlying plot command) do the right 
thing without knowing beforehand whether it is dealing with a log or a 
linear axis.  It simply has to make different choices for the patch 
(rectangle) corners and the data limits that are used for autoscaling. 
   For this to work correctly in an interactive mode with 
set_yscale('log') called after the hist or bar command would require a 
mechanism for undoing and then redoing the hist or bar command.  Such a 
mechanism could be developed, but it would require some structural 
changes in mpl (or maybe some very ugly hacks), and I don't see that 
this particular problem is bad enough to motivate such changes.

Actually, I think the sticking point is the autoscaling, not the 
patches.  For the default "bottom=None" case, we could set bottom to 
1e-100 for both the log and linear axes, and for all practical purposes 
it would work correctly for either, indistinguishably from the way it 
does now.  The problem is that with a linear axis we want the axis to 
start at zero by default, but with a log axis we want it to start a bit 
below the lowest bar, so the autoscaling is inherently different and 
needs to be based on a different dataLim bounding box.

Maybe in time we will figure out better solutions.

Eric

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

Thanks! However...

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

I think this makes the API more confusing. As an end user, I want the
API to be consistent and intuitive. Its weird if I can set log scale
after all plot commands, but not after calling hist. And yet, log
scale DOES work with that keyword arg. I might even think things were
broken had I not been following this thread.

Anyways, thanks for looking into this!
-- 
Web/Blog/Gallery: http://floatingsun.net/blog

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

>>>>> "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
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.
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

Hi Guys,

I'm a new user of Matplotlib and am very impressed by its plotting capabilities.

I have the latest version of Matplotlib and Numpy 1.0 running on my Win 2000 system with Python 2.4. 

On running the pythonic_matplotlib.py,cursor_demo.py etc.. in Matplotlib examples in the Pythonwin interpreter, the program runs fine, the tk window shows up and when I close the window by way of the 'x' on the right hand side, it closes fine.

But however, when I reload pythonic_matplotlib.py, and run it again (by pressing F5), the tk window shows up, but the all the functions on the toolbar do not work. When I press the 'x' on the right hand side of the window, it shows the following message and Pythonwin crashes.

"Runtime Error!

Program: c:\Python24\Lib\site-packages\pythonwin\pythonwin.exe

This application has requested the Runtime to terminate in an unusual way. Please contact the application's support team for more information"

I was wondering what the issue could be.

Your response is greatly appreciated.

Thanks.
Maser



 
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.

On Dec 16, 2006, at 1:58 PM, Pierre GM wrote:
>> I've also written a neat pre-processor that allows you to embed
>> python and matplotlib code in LaTeX, so you don't need to have it all
>> spread out. And you can populate the results from SQL queries, right
>> there in the LaTeX. It makes paper writing much easier.
> Oh, that sounds great ! Could you post it somewhere ? I'm sure it'd  
> be quite
> useful (I do have a need for it myself...)

I've made an initial release at http://www.simson.net/pylatex.tar.gz

It's very preliminary, and you'll need to figure out the latex stuff  
yourself. I had wanted to put in some more examples, but haven't  
figure out a good way to do it easily....

Oops, I replied to your previous message before seeing this one.

Still, the larger question remains: maybe we should do something to make 
it easier for users to understand what is going on when the transform 
chokes on log(0).  Changing numbers <=0 to a small positive number and 
issuing a warning would accomplish this, and I don't see much disadvantage.

Eric

John Hunter wrote:
>>>>>> "John" == John Hunter <jdh...@ac...> writes:
> 
>     John> You have to make sure your yaxis limits are strictly
>     John> positive, eg
> 
>     John>   ax.set_ylim(1e-3, 1e3) ax.set_yscale('log')
> 
> No that won't quite do it, sorry for the noise.  The problem is that
> the histogram bottom of the rectangle is zero by default, and
> transforming those vertices are causing the problem.  You need to use
> the "bottom" kwarg to set the bottom of the bars to be positive, eg
> 
> hist(rand(100), 20,  bottom=1e-3)
> 
> JDH
> 
> 
> -------------------------------------------------------------------------
> 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

John Hunter wrote:
>>>>>> "Diwaker" == Diwaker Gupta <diw...@gm...> writes:
> 
>     >> >> The following minimal script reveals a rendering problem
>     >> with >> displaying a histogram on a log vertical axis.
> 
>     Diwaker> Has this been resolved yet? I'm running Matplotlib
>     Diwaker> 0.87.5-2.2 on Debian Unstable. I try to run the following
>     Diwaker> script:
> 
>     Diwaker> from pylab import * hist(rand(100), 20) ax = gca()
>     Diwaker> ax.set_yscale('log') show()
> 
> You have to make sure your yaxis limits are strictly positive, eg
> 
>   ax.set_ylim(1e-3, 1e3)
>   ax.set_yscale('log')


This doesn't work.  The problem is that the patch objects are made 
first, and they start at y=0, so changing the y limits doesn't prevent 
the attempt to take the log of zero.

One solution would be to have the transform simply trap zero and 
negative inputs and change them, with or without a warning, to some very 
small positive value.  This would do the right thing in the present 
case.  In cases where a zero is used inadvertently and incorrectly, and 
where an exception really should be raised, it would not do so.  Maybe 
this is a worthwhile tradeoff?  This question has come up quite a few 
times, and it would be nice to stop that.

A solution for hist would be a kwarg to handle the log case.  If hist is 
the only context in which this problem arises--that is, if all other 
cases are ones in which the zero has no business being there so an 
exception is appropriate--then adding log-handling to hist would be the 
way to go.  But I suspect there are other cases, and we will keep 
getting this question.  It's understandable, because the exception that 
gets triggered is not very informative.

Eric

> 
> 
> JDH

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> You have to make sure your yaxis limits are strictly
    John> positive, eg

    John>   ax.set_ylim(1e-3, 1e3) ax.set_yscale('log')

No that won't quite do it, sorry for the noise.  The problem is that
the histogram bottom of the rectangle is zero by default, and
transforming those vertices are causing the problem.  You need to use
the "bottom" kwarg to set the bottom of the bars to be positive, eg

hist(rand(100), 20,  bottom=1e-3)

JDH

>>>>> "Diwaker" == Diwaker Gupta <diw...@gm...> writes:

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

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

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

You have to make sure your yaxis limits are strictly positive, eg

  ax.set_ylim(1e-3, 1e3)
  ax.set_yscale('log')


JDH

On 12/26/06, John Hunter <jdh...@ac...> wrote:
> Did you rm -rf your build dir (and sometimes site-packages/matplotlib)
> before rebuilding.  This is usually the cause of such crashes.

Yes I have.  I even reinstalled windows (not related to matplotlib :),
and I had the same problems.

I'll experiment a bit more, but maybe the problem is not my system... ;)

Cheers,
Edin

The problem is still present in svn.  Thanks for the reminder.

Eric

Diwaker Gupta wrote:
>>>> 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.
> 

On Tue, 26 Dec 2006, Eric Firing apparently wrote: 
> 1) edgecolor=facecolor is not the same as not drawing the 
> edge; it leads to artifacts that can be very damaging. 

Strongly agree!

Cheers,
Alan Isaac