Re: [Matplotlib-users] histogram bug
John Hunter wrote:
Diwaker == Diwaker Gupta [EMAIL PROTECTED] 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
-
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.phpp=sourceforgeCID=DEVDEV
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] pylatex
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 - 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.phpp=sourceforgeCID=DEVDEV ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Runtime Error on running matplotlib examples pythonic_matplotlib.py, cursor_demo.py, etc .. (Pythonwin 2.4 crashes)
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.- 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.phpp=sourceforgeCID=DEVDEV___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] histogram bug
Eric == Eric Firing [EMAIL PROTECTED] 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 - 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.phpp=sourceforgeCID=DEVDEV ___ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] histogram bug
John Hunter wrote:
Eric == Eric Firing [EMAIL PROTECTED] 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
-
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.phpp=sourceforgeCID=DEVDEV
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
