matplotlib-users Mailing List for matplotlib

>>>>> "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 2006年12月26日, 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

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