[matplotlib-devel] Gaps between bars with pyplot.bar
Hello developers,
I'm seeing what appears to be a bug when plotting bars next to each
other without edges. In pdf output, you can see that there is a tiny
gap in between each bar, which renders as one pixel wide no matter how
far I zoom in. It's also visible in interactive or png output:
http://www.dumpt.com/img/viewer.php?file=mc0wf07aksrzqs1h8j5k.png
You can generate the above by running a slightly modified demo:
---
#!/usr/bin/env python
# a stacked bar plot with errorbars
import numpy as np
import matplotlib.pyplot as plt
N = 5
menMeans = (20, 35, 30, 35, 27)
womenMeans = (25, 32, 34, 20, 25)
menStd = (2, 3, 4, 1, 2)
womenStd = (3, 5, 2, 3, 3)
ind = np.arange(N)# the x locations for the groups
width = 1.0 # CHANGED from 0.35 in the demo
# CHANGED: adding linewidth=0 to these calls
p1 = plt.bar(ind, menMeans, width, color='r', yerr=womenStd, linewidth=0)
p2 = plt.bar(ind, womenMeans, width, color='y', linewidth=0,
bottom=menMeans, yerr=menStd)
plt.ylabel('Scores')
plt.title('Scores by group and gender')
plt.xticks(ind+width/2., ('G1', 'G2', 'G3', 'G4', 'G5') )
plt.yticks(np.arange(0,81,10))
plt.legend( (p1[0], p2[0]), ('Men', 'Women') )
plt.show()
---
Any thoughts on why there's always a tiny gap between bars?
Thanks,
Jeff
|| Jeff Klukas
|| Physics Lecturer, University of Wisconsin -- Whitewater
|| Research Assistant, University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://hep.wisc.edu/~jklukas/
--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book Blueprint to a
Billion shares his insights and actions to help propel your
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug in 'weights' in axes.hist
Hello,
The documentation for hist seems to indicate that you should be able
to send a list of values through the 'weights' parameter in axes.hist,
and this worked in previous versions. In 1.0, however, this produces
an error. I've attached a diff (also pasted below) that I believe
produces the expected behavior.
It can be tested with:
plt.hist([1,2,3], weights=[1,2,3])
The above fails in the development version, but works with the diff.
Could someone add this fix?
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://klukas.web.cern.ch/
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 8565)
+++ lib/matplotlib/axes.py (working copy)
@@ -7587,7 +7587,12 @@
else:
raise ValueError(weights must be 1D or 2D)
else:
-w = [np.array(wi) for wi in weights]
+try:
+weights[0][0]
+except TypeError:
+w = [np.array(weights)]
+else:
+w = [np.array(wi) for wi in weights]
if len(w) != nx:
raise ValueError('weights should have the same shape as x')
weights.diff
Description: Binary data
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Minor fix to histogram weights (patch attached)
I noticed a small problem in axes.py; when setting weights with a histogram, a variable 'w' is accessed before it's assigned. It looks like this is a typo where 'w' should instead be 'weights'. The patch is copied below and attached. Cheers, Jeff || Jeff Klukas, Research Assistant, Physics || University of Wisconsin -- Madison || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype || http://www.hep.wisc.edu/~jklukas/ Index: lib/matplotlib/axes.py === --- lib/matplotlib/axes.py (revision 8316) +++ lib/matplotlib/axes.py (working copy) @@ -7364,7 +7364,7 @@ raise ValueError(color kwarg must have one color per dataset) if weights is not None: -if isinstance(w, np.ndarray): +if isinstance(weights, np.ndarray): w = np.array(weights) if w.ndim == 2: w = w.T klukashist.diff Description: Binary data -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in stepfilled hist with log y
I was using matplotlib 0.99.1.1. I just set up an Ubuntu system in
VirtualBox so I could run the current svn trunk, and all is well. It
looks like the fix has already been implemented.
On Wed, May 12, 2010 at 3:06 PM, Jeff Klukas klu...@wisc.edu wrote:
I've looked now through the source code for axes.hist, and I see where
the problem is. If any value of any bin of the histogram is zero,
then axes.fill fails, as zero is necessarily outside the y boundaries
of the axes for log scale.
Already, a default value of 1e-100 is chosen for the first and last
points given to axes.fill. If you also clean the histogram, replacing
all zero y-values with 1e-100, then the fill succeeds. I see no
downside to this treatment, since the default value has already been
introduced.
The user will still need to choose a reasonable lower limit for the y-axis.
Any objections or concerns?
Cheers,
Jeff
On Wed, May 12, 2010 at 11:13 AM, Jeff Klukas klu...@wisc.edu wrote:
When creating a histogram with histtype='stepfilled' and log=True, the
fill always ends up getting cut off diagonally. It looks like it's
connection one datapoint with 10^-100 on the other side of the plot.
So, also, it looks like it's always choosing 10^-100 as an arbitrary
lower limit, which is another problem.
Is this a known bug? Does anybody have ideas for an intelligent way
to handle stepfilled log histograms?
A working example is below, with the output plot attached.
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://www.hep.wisc.edu/~jklukas/
-
#!/usr/bin/env python
import numpy as np
import matplotlib.mlab as mlab
import matplotlib.pyplot as plt
mu, sigma = 100, 15
x = mu + sigma*np.random.randn(1)
# the histogram of the data
n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75,
log=True, histtype='stepfilled')
plt.xlabel('Smarts')
plt.ylabel('Probability')
plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')
plt.axis([40, 160, 0, 0.03])
plt.grid(True)
plt.show()
-
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug in stepfilled hist with log y
I've looked now through the source code for axes.hist, and I see where
the problem is. If any value of any bin of the histogram is zero,
then axes.fill fails, as zero is necessarily outside the y boundaries
of the axes for log scale.
Already, a default value of 1e-100 is chosen for the first and last
points given to axes.fill. If you also clean the histogram, replacing
all zero y-values with 1e-100, then the fill succeeds. I see no
downside to this treatment, since the default value has already been
introduced.
The user will still need to choose a reasonable lower limit for the y-axis.
Any objections or concerns?
Cheers,
Jeff
On Wed, May 12, 2010 at 11:13 AM, Jeff Klukas klu...@wisc.edu wrote:
When creating a histogram with histtype='stepfilled' and log=True, the
fill always ends up getting cut off diagonally. It looks like it's
connection one datapoint with 10^-100 on the other side of the plot.
So, also, it looks like it's always choosing 10^-100 as an arbitrary
lower limit, which is another problem.
Is this a known bug? Does anybody have ideas for an intelligent way
to handle stepfilled log histograms?
A working example is below, with the output plot attached.
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://www.hep.wisc.edu/~jklukas/
-
#!/usr/bin/env python
import numpy as np
import matplotlib.mlab as mlab
import matplotlib.pyplot as plt
mu, sigma = 100, 15
x = mu + sigma*np.random.randn(1)
# the histogram of the data
n, bins, patches = plt.hist(x, 50, normed=1, facecolor='green', alpha=0.75,
log=True, histtype='stepfilled')
plt.xlabel('Smarts')
plt.ylabel('Probability')
plt.title(r'$\mathrm{Histogram\ of\ IQ:}\ \mu=100,\ \sigma=15$')
plt.axis([40, 160, 0, 0.03])
plt.grid(True)
plt.show()
-
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Use of Color Cycles for Hist
Alright, I have attached a top-level diff that contains the changes to axes.py that allow sending multiple colors to the 'color' argument in Axes.hist. Below is a short examples that passes lists to 'colors' and 'labels'. Cheers, Jeff || Jeff Klukas, Research Assistant, Physics || University of Wisconsin -- Madison || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype || http://www.hep.wisc.edu/~jklukas/ -- import pylab as P mu, sigma = 200, 25 x0 = mu + sigma*P.randn(1) x1 = mu + sigma*P.randn(7000) x2 = mu + sigma*P.randn(3000) P.figure() colors = ['crimson', 'burlywood', 'chartreuse'] labels = ['Crimson', 'Burlywood', 'Chartreuse'] n, bins, patches = P.hist([x0,x1,x2], 10, histtype='bar', color=colors, label=labels) P.legend() P.show() - On Wed, Mar 31, 2010 at 1:27 PM, Eric Firing efir...@hawaii.edu wrote: Jeff Klukas wrote: When plotting multiple data with one Axes.hist call, the method's interface allows you to specify a list of labels to the 'label' kwarg to distinguish between the datasets. To get different colors, however, you cannot give a list of colors to 'color'; instead, you have to leave out the 'color' kwarg and change the color cycle. Is there any reason why the color kwarg can't work like label? I spent an hour or two trying to debug a script before I realized that 'color' wasn't being interpreted as I expected. I realize that there is some ambiguity since a color argument can be an rgb or rgba sequence. My proposal would be that 'color' would be interpreted as a list of distinct colors only when multiple datasets are given as input and len(color) equals the number of datasets. I find it hard to imagine a case where you would want to set all datasets to be the same color, so I don't think the ambiguity would be a major issue. I would be happy to write and submit an implementation if others think this is a reasonable idea. Sounds good to me. I agree that it makes no sense to have to set the color cycle for hist (although using the color cycle as a default is reasonable), and I think it is just an artifact of the way hist has evolved. Eric Cheers, Jeff || Jeff Klukas, Research Assistant, Physics || University of Wisconsin -- Madison || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype || http://www.hep.wisc.edu/~jklukas/ histcolors.diff Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Use of Color Cycles for Hist
When plotting multiple data with one Axes.hist call, the method's interface allows you to specify a list of labels to the 'label' kwarg to distinguish between the datasets. To get different colors, however, you cannot give a list of colors to 'color'; instead, you have to leave out the 'color' kwarg and change the color cycle. Is there any reason why the color kwarg can't work like label? I spent an hour or two trying to debug a script before I realized that 'color' wasn't being interpreted as I expected. I realize that there is some ambiguity since a color argument can be an rgb or rgba sequence. My proposal would be that 'color' would be interpreted as a list of distinct colors only when multiple datasets are given as input and len(color) equals the number of datasets. I find it hard to imagine a case where you would want to set all datasets to be the same color, so I don't think the ambiguity would be a major issue. I would be happy to write and submit an implementation if others think this is a reasonable idea. Cheers, Jeff || Jeff Klukas, Research Assistant, Physics || University of Wisconsin -- Madison || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype || http://www.hep.wisc.edu/~jklukas/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Proposal for Broken Axes
I haven't heard a response back about the proposal I posted for broken
axes. Hopefully that just means people are busy :). If there are
concerns about the method or interface, I'm certainly open to hearing
them.
In the meantime, I've been thinking about the interface, and I think
the more correct and more ambitious thing to do would be to create a
new BrokenAxes class that inherits from Axes. The class could
redefine __getattribute__ to pass most function calls straight to the
subaxes. So in the end a session could look like the following:
# Create BrokenAxes with bottom from 0 to 5 and top from 30 to 35
ax = plt.broken_axes(ybounds=[0.,5.,30.,35.])
# Plot a line onto BOTH subaxes
ax.plot(range(35),range(35))
The call to plot would get routed through __getattribute__, which
would then call plot for each of the subaxes. This would be much more
intuitive than my existing breaky solution, where you have to loop
over all subaxes and plot on each individually.
The more ambitious thing to do would be to also define a BrokenAxis
class that inherits from Axis and would redefine get_ticklabel_extents
to look as each subaxis and push the axis label far enough out to
clear the ticklabels on all subaxes.
Does that new interface sound like a good idea? Are there any
show-stopping problems that seem apparent. If it sounds like
something worth trying, I could take a stab at writing an
implementation.
Cheers,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://www.hep.wisc.edu/~jklukas/
On Thu, Mar 18, 2010 at 1:38 PM, Jeff Klukas klu...@wisc.edu wrote:
I have implemented breakx and breaky methods for the Axes class and
attached the diff for axes.py to this message.
You can test out the function with the following examples:
--
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
# Broken y
fig = plt.figure()
main_axes = plt.axes()
plt.title('Broken x-axis example')
plt.xlabel('x-axis label')
subaxes = main_axes.breaky([0., 1.9, 5.1, 6.9, 9.1, 12])
for axes in subaxes:
axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
plt.ylabel('y-axis label')
plt.show()
--
import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
# Broken x
fig = plt.figure()
main_axes = plt.axes()
plt.title('Broken x-axis example')
plt.ylabel('y-axis label')
subaxes = main_axes.breakx([0., 1.9, 5.1, 6.9, 9.1, 12])
for axes in subaxes:
axes.plot(np.linspace(0,12,13),np.linspace(0,12,13))
plt.xlabel('x-axis label')
plt.show()
-
I've included in the docstrings some of the TODO items, but this is
pretty stable in its current form.
Cheers,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://www.hep.wisc.edu/~jklukas/
On Tue, Mar 16, 2010 at 1:08 PM, Jeff Klukas klu...@wisc.edu wrote:
What would be great is if you could refactor the basic functionality
into a matplotlib.Axes.breaky method (and possibly breakx but most
people request a broken y axis), which would resize the self axes
and return the broken compliment which could be plotted onto. Then
you could provide a thin pyplot wrapper much like pyplot.twinx, so
that pyplot as well as API users could benefit.
I can try to do this. I think I would prefer, however, not to resize
the self axes and continue with my current approach of creating two
new axes within the original axes. On the user end, I think it makes
more sense to set the title and ylabel of the main axes, rather than
setting them for the individual upper and lower axes. More on that
below.
The only real problems here is that you need to
explicitly plot things on both the upper and lower axes, and then I haven't
figured out how to push out the y-axis label of the main axes object so it
doesn't overlap with the tick labels of the upper and lower axes. So, I
instead moved the y-labels of the upper and lower axes so that they appear
at the center of the axis, but this is problematic. Any thoughts on how to
do that part better?
klukas, I'm afraid I don't understand your issue... Can you explain using
it differently?
In my approach, you end up with a main axes object that is invisible,
and then two visible axes objects (upper and lower) within the main
axes. I would ideally like to have the y label display in the middle
of the main y-axis, independent of where the break lies. If I place a
y label on the main axes (which has ticks or tick labels), though, it
appears right up against the axis line. I'd like it to be placed
further to the left, clear of the tick labels that appear on the upper
and lower axes. So, I'd like to be able to access whatever algorithm
is used to choose the offset of the axis label, and explicitly set the
offset
[matplotlib-devel] Proposal for a new example of a polar 3d plot
Attached and also pasted below is an example which creates a 3d figure
using polar coordinates rather than the x and y. The solution was
created by Armin Moser when I posted a question to the users list.
There are currently no examples of polar coordinates in 3D available.
Any objections to adding this to mpl_examples/mplot3d?
Thanks,
Jeff
|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype
|| http://www.hep.wisc.edu/~jklukas/
import matplotlib.pyplot as plt
import numpy as np
from mpl_toolkits.mplot3d import Axes3D
from matplotlib import cm
fig = plt.figure()
ax = Axes3D(fig)
# create supporting points in polar coordinates
r = np.linspace(0, 1.25, 50)
phi = np.linspace(0, 2*np.pi, 50)
R, PHI = np.meshgrid(r,phi)
# transform them to cartesian system
X,Y = R * np.cos(PHI), R * np.sin(PHI)
Z = ((R**2 - 1)**2)
ax.plot_surface(X, Y, Z, rstride=1, cstride=1, cmap=cm.jet)
ax.set_zlim3d(0, 1)
ax.set_xlabel(r'$\phi_\mathrm{real}$')
ax.set_ylabel(r'$\phi_\mathrm{im}$')
ax.set_zlabel(r'$V(\phi)$')
ax.set_xticks([])
plt.show()
polar3d_demo.py
Description: Binary data
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Proposal for Broken Axes
What would be great is if you could refactor the basic functionality into a matplotlib.Axes.breaky method (and possibly breakx but most people request a broken y axis), which would resize the self axes and return the broken compliment which could be plotted onto. Then you could provide a thin pyplot wrapper much like pyplot.twinx, so that pyplot as well as API users could benefit. I can try to do this. I think I would prefer, however, not to resize the self axes and continue with my current approach of creating two new axes within the original axes. On the user end, I think it makes more sense to set the title and ylabel of the main axes, rather than setting them for the individual upper and lower axes. More on that below. The only real problems here is that you need to explicitly plot things on both the upper and lower axes, and then I haven't figured out how to push out the y-axis label of the main axes object so it doesn't overlap with the tick labels of the upper and lower axes. So, I instead moved the y-labels of the upper and lower axes so that they appear at the center of the axis, but this is problematic. Any thoughts on how to do that part better? klukas, I'm afraid I don't understand your issue... Can you explain using it differently? In my approach, you end up with a main axes object that is invisible, and then two visible axes objects (upper and lower) within the main axes. I would ideally like to have the y label display in the middle of the main y-axis, independent of where the break lies. If I place a y label on the main axes (which has ticks or tick labels), though, it appears right up against the axis line. I'd like it to be placed further to the left, clear of the tick labels that appear on the upper and lower axes. So, I'd like to be able to access whatever algorithm is used to choose the offset of the axis label, and explicitly set the offset of the ylabel for the main axes so that it clears the tick labels. // Jeff -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
