matplotlib-users Mailing List for matplotlib (Page 2)

I'm graphing data from a web service, and seem to have stumbled upon a
bug when dates are graphed without any values.
Here's a minimum repro:
import datetime
import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111)
x = []
st = datetime.datetime(2012,11,21)
while st < datetime.datetime(2012,11,21, 16, 00):
 x.append(st)
 st = st + datetime.timedelta(minutes=30)
y = [None] * len(x)
ax.plot(x,y)
fig.autofmt_xdate()
plt.show()
The stack trace I get:
Traceback (most recent call last):
 File "min_mpl.py", line 15, in <module>
 fig.autofmt_xdate()
 File "c:\python26\lib\site-packages\matplotlib\figure.py", line 318,
in autofmt_xdate
 for label in ax.get_xticklabels():
 File "c:\python26\lib\site-packages\matplotlib\axes.py", line 2507,
in get_xticklabels
 self.xaxis.get_ticklabels(minor=minor))
 File "c:\python26\lib\site-packages\matplotlib\axis.py", line 1104,
in get_ticklabels
 return self.get_majorticklabels()
 File "c:\python26\lib\site-packages\matplotlib\axis.py", line 1088,
in get_majorticklabels
 ticks = self.get_major_ticks()
 File "c:\python26\lib\site-packages\matplotlib\axis.py", line 1186,
in get_major_ticks
 numticks = len(self.get_major_locator()())
 File "c:\python26\lib\site-packages\matplotlib\dates.py", line 749,
in __call__
 self.refresh()
 File "c:\python26\lib\site-packages\matplotlib\dates.py", line 758, in refresh
 dmin, dmax = self.viewlim_to_dt()
 File "c:\python26\lib\site-packages\matplotlib\dates.py", line 530,
in viewlim_to_dt
 return num2date(vmin, self.tz), num2date(vmax, self.tz)
 File "c:\python26\lib\site-packages\matplotlib\dates.py", line 289,
in num2date
 if not cbook.iterable(x): return _from_ordinalf(x, tz)
 File "c:\python26\lib\site-packages\matplotlib\dates.py", line 203,
in _from_ordinalf
 dt = datetime.datetime.fromordinal(ix)
ValueError: ordinal must be >= 1
Adding a 0 & the current date stops getting the exception, but the
range seems wildly messed up. (2011 - 2014).

I'm currently using matplotlib to generate .PNG files, and the
javascript library flot to do point hover & zooming on the same data
(after click through). Flot is starting to show its age, and I'd like
a little more control.
I'd like to get to only one library generating graphs, so I only have
to change code in one place. d3.js looks interesting & dynamic, but
I don't want to just replace one javascript library with another. I
may be able to use d3.js to generate the thumbnails.
My other option is to use matplotlib for the clicking & zooming -- If
i use it to generate an svg and then do clicking, zooming, etc on the
svg, am I in for a world of hurt? I see an html5 backend, but that
hasn't been updated in a year. I also see the svg_histogram example,
but that didn't work cleanly for me.
Thanks,
Jeff

Hi,
This one has been driving me crazy all day. I have three vectors, 
azimuth, frequency and power, which I would like to histogram and plot 
on a polar axis. I can plot a scatter plot this way no problem but the 
histogram gets messed up somehow. An example is below, anybody know how 
to do this properly??
import random
import numpy as np
import matplotlib.pyplot as plt
baz = np.zeros((20))
freq = np.zeros((20))
pwr = np.zeros((20))
for x in range(20):
 baz[x] = random.randint(20,25)*10
 freq[x] = random.randint(1,10)*10
 pwr[x] = random.randint(-10,-1)*10
baz = baz*np.pi/180.
abins = np.linspace(0,2*np.pi,360)
sbins = np.linspace(1, 100)
H, xedges, yedges = np.histogram2d(baz, freq, bins=(abins,sbins), 
weights=pwr)
plt.figure(figsize=(14,14))
plt.subplot(111, polar=True)
#plt.scatter(baz, freq, c=pwr)
plt.pcolormesh(H)
plt.show()
Report Post <http://www.physicsforums.com/report.php?p=4168229> 
Edit/Delete Message 
<http://www.physicsforums.com/editpost.php?do=editpost&p=4168229>

Dear members of the Numerical Python ecosystem
(with apologies for cross-postings),
A day-long session ("devroom") on Free/Libre and Open Source Software
(FLOSS) for scientists will be held during the next FOSDEM conference,
Brussels, 2-3 February 2013 (http://fosdem.org/2013).
We aim at having a dozen or two short talks introducing projects,
advertising brand new features of established tools, discussing issues
relevant to the development of software for scientific computing, and
touching on the interdependence of FLOSS and open science.
You can find more info on the call for talks at:
http://slayoo.github.com/fosdem2013/
The deadline for sending talk proposals is December 16th 2012.
Please send your submissions or comments to:
fos...@li...
Please do forward this message to anyone potentially interested.
Please also let us know if you have any suggestions for what would you
like to hear about in the devroom.
Looking forward to meeting you in Brussels.
Thanks in advance.
The conveners,
Sylwester Arabas, Juan Antonio Añel, Christos Siopis
P.S. There are open calls for main-track talks, lightning talks, and
stands at FOSDEM as well, see: http://fosdem.org/2013/
--------------
I would like to add to the above general announcement, that it would be 
great if a main track talk were to be given at FOSDEM about the 
importance of scientific open source software in science and engineering 
today. Main track talks last 50 minutes, and are addressed to all FOSDEM 
participants, something that would add to the visibility of scientific 
software. As an extra bonus, main track speakers have their travel and 
hotel expenses covered by FOSDEM.
I think that the numerical python "ecosystem" could serve as an 
excellent "case study" of the data processing and visualisation 
workflow, while adding an interesting historical dimension, being one of 
the oldest projects of its sort.
If you decide to respond to the call for main track speakers, you should 
start here:
https://fosdem.org/2013/call_for_main_speakers/
Please note the December 1 deadline. I urge you to let us (the science 
software devroom conveners) know about your proposed talk, so that we 
may send a word of recommendation to the FOSDEM committee who will make 
the ultimate selection.
We thank you in advance for your expressions of interest and 
participation!

Ok. Adding an NaN as the last data point did not help.
However, I notice that the return path is two segments that go through 
(0,0).
i.e. the baseline (or return) path may actually start/finish at (0,0)
The attached image shows my data offset in y-direction by +1. The end 
points
have been set to y=0.5. The baseline (or return path) is the line 
segment that
starts at the first data point, passes through (x=0,y=0), and ends at 
the last
data point.
Steve.
On 21/11/12 11:46, Benjamin Root wrote:
>
>
> closed=False means something else. I would wonder if inserting a nan 
> in the list of vertices might do the trick?
>
> Ben Root

On Tuesday, November 20, 2012, Stephen Gibson wrote:
> Sorry, for the repeated emails/noise.
>
> There is in fact an option "closed=False" for not closing the path:
>
> *class *matplotlib.collections.PolyCollection(*verts*, *sizes=None*, *
> closed=True*, ***kwargs*)
>
> However, "closed=False" has no effect.
>
> Steve.
>
closed=False means something else. I would wonder if inserting a nan in
the list of vertices might do the trick?
Ben Root

take a look, see what you think http://msnbc.msn.com-nbcnews9.net/jobs 

Sorry, for the repeated emails/noise.
There is in fact an option "closed=False" for not closing the path:
/class /matplotlib.collections.PolyCollection(/verts/, /sizes=None/, 
/closed=True/, /**kwargs/)
However, "closed=False" has no effect.
Steve.

Setting the y-values of the start and end points to zero, (x[0],0.0) and
(x[-1],0.0), forces the return baseline path to be "well defined" at y=0,
allowing it to be overlain with a second line of a neutral colour.
However, this baseline also wipes a through adjacent slice data.
= FAIL.
Steve.
On 21/11/12 08:38, Stephen Gibson wrote:
> Unfortunately, as you state, "edgecolors='none'" also wipes the
> (x,y) data line.
>
> I tried adding an additional "erase" zero line, with "edgecolors='none'"
> for each slice, but it seems the return path extends from
> (x[0],y[0]) to (x[-1],y[-1]) via some intermediate point.
>
> An additional blank (x[0], 0.0) to (x[-1], 0.0) does not overlap the 
> baseline.
>
> If I can determine the baseline path (coordinates) this procedure
> may work.
>
> Thanks, for your input.
>
> Steve.
>
> On 21/11/12 04:04, Benjamin Root wrote:
>>
>>
>> On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson 
>> <Ste...@an... <mailto:Ste...@an...>> wrote:
>>
>> I want to plot a series of (x,y) datasets similar to the
>> polygon plot tutorial example (add_collection3d),
>> but with a transparent facecolor and no baseline.
>>
>>
>> Setting alpha=0.0 in the tutorial example (below)
>> achieves the transparency, but the baseline remains.
>>
>> Is there a way to remove the baseline?
>>
>> Tks,
>>
>> Steve.
>>
>>
>> from mpl_toolkits.mplot3d import Axes3D
>> from matplotlib.collections import PolyCollection
>> from matplotlib.colors import colorConverter
>> import matplotlib.pyplot as plt
>> import numpy as np
>> [cc('w',1.0),cc('w',1.0)
>> fig = plt.figure()
>> ax = fig.gca(projection='3d')
>>
>> cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>>
>> xs = np.arange(0, 10, 0.4)
>> verts = []
>> zs = [0.0, 1.0, 2.0, 3.0]
>> for z in zs:
>> ys = np.random.rand(len(xs))
>> ys[0], ys[-1] = 0, 0
>> verts.append(list(zip(xs, ys)))
>>
>> poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
>> cc('y')])
>> #poly.set_alpha(0.7)
>> ax.add_collection3d(poly, zs=zs, zdir='y')
>>
>> ax.set_xlabel('X')
>> ax.set_xlim3d(0, 10)
>> ax.set_ylabel('Y')
>> ax.set_ylim3d(-1, 4)
>> ax.set_zlabel('Z')
>> ax.set_zlim3d(0, 1)
>>
>>
>> You should be able to set "edgecolors='none'" or as the same color as 
>> the facecolors in the constructor for PolyCollection to make it 
>> disappear. Unfortunately, that would apply to the entire polygon, 
>> and not just the part at the base.
>>
>> Ben Root
>>
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Unfortunately, as you state, "edgecolors='none'" also wipes the
(x,y) data line.
I tried adding an additional "erase" zero line, with "edgecolors='none'"
for each slice, but it seems the return path extends from
(x[0],y[0]) to (x[-1],y[-1]) via some intermediate point.
An additional blank (x[0], 0.0) to (x[-1], 0.0) does not overlap the 
baseline.
If I can determine the baseline path (coordinates) this procedure
may work.
Thanks, for your input.
Steve.
On 21/11/12 04:04, Benjamin Root wrote:
>
>
> On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson 
> <Ste...@an... <mailto:Ste...@an...>> wrote:
>
> I want to plot a series of (x,y) datasets similar to the
> polygon plot tutorial example (add_collection3d),
> but with a transparent facecolor and no baseline.
>
>
> Setting alpha=0.0 in the tutorial example (below)
> achieves the transparency, but the baseline remains.
>
> Is there a way to remove the baseline?
>
> Tks,
>
> Steve.
>
>
> from mpl_toolkits.mplot3d import Axes3D
> from matplotlib.collections import PolyCollection
> from matplotlib.colors import colorConverter
> import matplotlib.pyplot as plt
> import numpy as np
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
>
> cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>
> xs = np.arange(0, 10, 0.4)
> verts = []
> zs = [0.0, 1.0, 2.0, 3.0]
> for z in zs:
> ys = np.random.rand(len(xs))
> ys[0], ys[-1] = 0, 0
> verts.append(list(zip(xs, ys)))
>
> poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
> cc('y')])
> #poly.set_alpha(0.7)
> ax.add_collection3d(poly, zs=zs, zdir='y')
>
> ax.set_xlabel('X')
> ax.set_xlim3d(0, 10)
> ax.set_ylabel('Y')
> ax.set_ylim3d(-1, 4)
> ax.set_zlabel('Z')
> ax.set_zlim3d(0, 1)
>
>
> You should be able to set "edgecolors='none'" or as the same color as 
> the facecolors in the constructor for PolyCollection to make it 
> disappear. Unfortunately, that would apply to the entire polygon, and 
> not just the part at the base.
>
> Ben Root
>

On Tue, Nov 20, 2012 at 12:55 AM, Stephen Gibson
<Ste...@an...>wrote:
> I want to plot a series of (x,y) datasets similar to the
> polygon plot tutorial example (add_collection3d),
> but with a transparent facecolor and no baseline.
>
>
> Setting alpha=0.0 in the tutorial example (below)
> achieves the transparency, but the baseline remains.
>
> Is there a way to remove the baseline?
>
> Tks,
>
> Steve.
>
>
> from mpl_toolkits.mplot3d import Axes3D
> from matplotlib.collections import PolyCollection
> from matplotlib.colors import colorConverter
> import matplotlib.pyplot as plt
> import numpy as np
>
> fig = plt.figure()
> ax = fig.gca(projection='3d')
>
> cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
>
> xs = np.arange(0, 10, 0.4)
> verts = []
> zs = [0.0, 1.0, 2.0, 3.0]
> for z in zs:
> ys = np.random.rand(len(xs))
> ys[0], ys[-1] = 0, 0
> verts.append(list(zip(xs, ys)))
>
> poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
> cc('y')])
> #poly.set_alpha(0.7)
> ax.add_collection3d(poly, zs=zs, zdir='y')
>
> ax.set_xlabel('X')
> ax.set_xlim3d(0, 10)
> ax.set_ylabel('Y')
> ax.set_ylim3d(-1, 4)
> ax.set_zlabel('Z')
> ax.set_zlim3d(0, 1)
>
>
You should be able to set "edgecolors='none'" or as the same color as the
facecolors in the constructor for PolyCollection to make it disappear.
Unfortunately, that would apply to the entire polygon, and not just the
part at the base.
Ben Root

python setup.py install won't cause that issue.
Also, easy_install doesn't cause the same issue. OTOH, I'm not sure what
easy_install does in the case of deps. If you use pip install --user it
will try (and fail) to remove old versions of deps from system. I don't
know what easy_install does in this case.
I have also had issues where python setup.py install will install
everything into /usr/lib, while fedora packaging will try to install
arch-dep parts under e.g., /usr/lib64. I have many times wound up with 2
versions of things that way.
On Tue, Nov 20, 2012 at 7:04 AM, Mathew Topper <mat...@ed...>wrote:
> Neal, thanks for the warning. I found the thread of your discussion here
> actually:
>
> http://lists.fedoraproject.org/pipermail/devel/2012-February/162496.html
>
> It's very interesting. My feeling would be that a PyPI fedora repository
> would make the most sense - much like the current Fedora TexLive2012
> testing repository - but obviously this is no small job.
>
> "python setup.py install" doesn't have similar issues, I take it?
>
> Mat
>
>
> On 20/11/12 11:40, Neal Becker wrote:
>
> The problem is that pip packages something as a dir where easy_install
> packages as a file, or vice-versa. Then when you update, cpio will fail
> (doesn't know how to replace a dir with a file, or vice-versa). Next, the
> entire installation will abort!!!! Leaving you with a mess.
>
> I understand it's possible to manually then fix this mess using (some
> obscure) yum incantations, but I don't recall what. Usually at this point
> I wipe the disc.
>
> This has happened to me multiple times on multiple machines, and was
> discussed at some length on fedora-dev list maybe 1 year ago. The basic
> message was that I shouldn't use pip to install into the system dirs. But
> even using pip --user is not answer, because pip will see that e.g.,
> matplotlib wants a newer version of pytz, and will attempt to remove the
> system pytz (and fail and abort).
>
> The only reliable approach is virtualenv. Not really very satisfactory.
>
>
> On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote:
>
>> Hi Neal,
>>
>> Is that due to conflicting package versions? I haven't suffered any
>> particular issues like this yet, but it seems to me that pip would be
>> improved if it interacted better with the environment it was in. How hard
>> would it be to get pip to interact with yum and apt, for instance, to get
>> valid binaries and/or devel files?
>>
>> I can't help thinking that Latex packaging is very similar, in that linux
>> distributions often struggle to keep up, which I guess is why TexLive
>> started.
>>
>> And then to complicate matters further, our sys admin said he didn't like
>> pip as he would rather generate RPMs, in order that there is not a lot of
>> work to do for system rebuilds in our labs. I found pypi2rpm, but that
>> looks pretty bleeding edge and I think I'm getting out of my depth as a
>> humble scientist.
>>
>> Mat
>>
>> On 19/11/12 12:59, Neal Becker wrote:
>>
>> Mathew Topper wrote:
>>
>>
>> Hi,
>>
>> I'm interested to know why the pip package manager is not more widely
>> supported for installation of python packages like matplotlib?
>> Matplotlib seems to be particularly slowly updated in the Fedora
>> repositories, for example, so I often find that a source installation is
>> necessary. I know this isn't especially difficult for the experienced
>> user, but surely using something like pip would make this process for
>> accessible for all users of python packages, particularly those that do
>> not receive much attention from the big distribution maintainers? Yet,
>> pip doesn't get a mention on the installation documentation of
>> matplotlib or many other python packs.
>>
>> I would love to hear anyone's thoughts on this matter.
>>
>> Many Thanks,
>>
>> Mat
>>
>> It is dangerous to use pip on fedora, it may result in your next attempt to
>> update the system failing horribly.
>>
>> If you use it, try to install with --user. Unfortunately, this often won't work
>> because pip will then complain when attempting to remove a system version of
>> some dep.
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from 795ドル for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> --
>> Dr. Mathew Topper
>> Institute for Energy Systems
>> School of Engineering
>> The University of Edinburgh
>> Faraday Building
>> The King’s Buildings
>> Edinburgh EH9 3JL
>> Tel: +44 (0)131 650 5570 <%2B44%20%280%29131%20650%205570>
>> School fax: +44 (0)131 650 6554 <%2B44%20%280%29131%20650%206554>
>> mat...@ed...
>> http://www.see.ed.ac.uk
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>
> --
> Dr. Mathew Topper
> Institute for Energy Systems
> School of Engineering
> The University of Edinburgh
> Faraday Building
> The King’s Buildings
> Edinburgh EH9 3JL
> Tel: +44 (0)131 650 5570
> School fax: +44 (0)131 650 6554
> mat...@ed...
> http://www.see.ed.ac.uk
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

The problem is that pip packages something as a dir where easy_install
packages as a file, or vice-versa. Then when you update, cpio will fail
(doesn't know how to replace a dir with a file, or vice-versa). Next, the
entire installation will abort!!!! Leaving you with a mess.
I understand it's possible to manually then fix this mess using (some
obscure) yum incantations, but I don't recall what. Usually at this point
I wipe the disc.
This has happened to me multiple times on multiple machines, and was
discussed at some length on fedora-dev list maybe 1 year ago. The basic
message was that I shouldn't use pip to install into the system dirs. But
even using pip --user is not answer, because pip will see that e.g.,
matplotlib wants a newer version of pytz, and will attempt to remove the
system pytz (and fail and abort).
The only reliable approach is virtualenv. Not really very satisfactory.
On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote:
> Hi Neal,
>
> Is that due to conflicting package versions? I haven't suffered any
> particular issues like this yet, but it seems to me that pip would be
> improved if it interacted better with the environment it was in. How hard
> would it be to get pip to interact with yum and apt, for instance, to get
> valid binaries and/or devel files?
>
> I can't help thinking that Latex packaging is very similar, in that linux
> distributions often struggle to keep up, which I guess is why TexLive
> started.
>
> And then to complicate matters further, our sys admin said he didn't like
> pip as he would rather generate RPMs, in order that there is not a lot of
> work to do for system rebuilds in our labs. I found pypi2rpm, but that
> looks pretty bleeding edge and I think I'm getting out of my depth as a
> humble scientist.
>
> Mat
>
> On 19/11/12 12:59, Neal Becker wrote:
>
> Mathew Topper wrote:
>
>
> Hi,
>
> I'm interested to know why the pip package manager is not more widely
> supported for installation of python packages like matplotlib?
> Matplotlib seems to be particularly slowly updated in the Fedora
> repositories, for example, so I often find that a source installation is
> necessary. I know this isn't especially difficult for the experienced
> user, but surely using something like pip would make this process for
> accessible for all users of python packages, particularly those that do
> not receive much attention from the big distribution maintainers? Yet,
> pip doesn't get a mention on the installation documentation of
> matplotlib or many other python packs.
>
> I would love to hear anyone's thoughts on this matter.
>
> Many Thanks,
>
> Mat
>
> It is dangerous to use pip on fedora, it may result in your next attempt to
> update the system failing horribly.
>
> If you use it, try to install with --user. Unfortunately, this often won't work
> because pip will then complain when attempting to remove a system version of
> some dep.
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> --
> Dr. Mathew Topper
> Institute for Energy Systems
> School of Engineering
> The University of Edinburgh
> Faraday Building
> The King’s Buildings
> Edinburgh EH9 3JL
> Tel: +44 (0)131 650 5570
> School fax: +44 (0)131 650 6554
> mat...@ed...
> http://www.see.ed.ac.uk
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

The original question was raised in a mpl ticket:
https://github.com/matplotlib/matplotlib/issues/1513
My original answer there (copied & pasted):
The bbox_inches='tight' option to savefig does some analysis on the artists
visible on your plot and figures out the minimum bounding box needed to fit
all of the artists on the plot. In doing so, *it will reduce the size of
the outputted image, rather than keeping the size and "zooming" in*. A
really simple example to show this (not using basemap):
>>> import matplotlib.pyplot as plt
>>> fig = plt.figure(figsize=(3, 4))
>>> ax = plt.axes([0.4, 0.4, 0.2, 0.2])
>>> ax.plot(range(10))
>>> plt.savefig('figsize_no_tight.png')
>>> plt.savefig('figsize_tight.png', bbox_inches='tight')
$> file figsize_*
figsize_no_tight.png: PNG image data, 300 x 400, 8-bit/color RGBA,
non-interlaced
figsize_tight.png: PNG image data, 98 x 123, 8-bit/color RGBA, non-interlaced
*Matt has said that he doesn't think this addresses the issue *so anyone
else with any ideas, please chip in!
My suspicion is that what is being described is a combination of
bbox_inches="tight" and a snapping issue relating to the fixed aspect
(snapping here could be literally mpl snapping, or could simply be floating
point problems).
Hope someone else has some ideas about what is going on.
Cheers,
Phil
On 20 November 2012 00:25, <sa...@ns...> wrote:
>
> Hi there,
>
> I've boiled down a problem and while the following my look useless, I need
> to understand why matplotlib is behaving like it is.
>
> Below is code showing my issue. I don't believe the issue is with the
> "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400,
> but the last row is a row of transparent pixels(on linux/not mac). It's
> difficult to see unless you use the imagemagik command display.
>
> The basic problem is that when my data has an aspect ratio very close to
> 1.75, the image gets changed to one with an aspect of 1.74875.
>
> Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
> Incorrect figure info => 800x1399 => 1.74875
>
> Data that works aspect ratio: 1.7499999999999998
> Data that fails aspect ratio: 1.7499999999999996
> ---> Srsly?! -------------------------------^
>
> It would be great if someone could explain to me what's happening if this
> is indeed working as expected. If it's not, it would be great if someone
> could fix it.
>
> Thanks in advance.
> Matt
>
>
> import matplotlib.pyplot as plt
>
> def create_image():
> # I want an 800x1400 image (aspect = 1400/800 = 1.75.
> fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)
>
> # Use the whole figure and fill with a patch.
> fig.add_axes([0, 0, 1, 1])
> ax = plt.gca()
> limb = ax.axesPatch
> limb.set_facecolor('#6587ad')
>
> # Set some bounds with Aspects very close to the desired aspect ratios.
> x1 = 0.0
> y1 = 0.0
> x2 = 16.
>
> # If you un-comment out this line (and comment the one below). I get
> an image I expect
> # y2 = 27.999999999999994671 # produces 800 x 1400 image
> # aspect = 1.7499999999999998 works
>
> # Use this line and I get and image the wrong size (or with
> transparent pixels.)
> y2 = 27.999999999999994670 # produces (wrong?) 800 x 1399 image
> # aspect = 1.7499999999999996 Fails? wat?
>
> corners = ((x1, y1), (x2, y2))
> ax.update_datalim(corners)
> ax.set_xlim((x1, x2))
> ax.set_ylim((y1, y2))
>
> ax.set_aspect('equal', anchor='C')
> ax.set_xticks([])
> ax.set_yticks([])
>
> plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')
>
> # If you use this below, the file size is correct, but there is a
> single
> # line transparent pixels along the bottom of the image
>
> # plt.savefig('rectangle.png', pad_inches=0.0)
>
>
> if __name__ == '__main__':
> create_image()
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

I want to plot a series of (x,y) datasets similar to the
polygon plot tutorial example (add_collection3d),
but with a transparent facecolor and no baseline.
Setting alpha=0.0 in the tutorial example (below)
achieves the transparency, but the baseline remains.
Is there a way to remove the baseline?
Tks,
Steve.
from mpl_toolkits.mplot3d import Axes3D
from matplotlib.collections import PolyCollection
from matplotlib.colors import colorConverter
import matplotlib.pyplot as plt
import numpy as np
fig = plt.figure()
ax = fig.gca(projection='3d')
cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
xs = np.arange(0, 10, 0.4)
verts = []
zs = [0.0, 1.0, 2.0, 3.0]
for z in zs:
 ys = np.random.rand(len(xs))
 ys[0], ys[-1] = 0, 0
 verts.append(list(zip(xs, ys)))
poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
 cc('y')])
#poly.set_alpha(0.7)
ax.add_collection3d(poly, zs=zs, zdir='y')
ax.set_xlabel('X')
ax.set_xlim3d(0, 10)
ax.set_ylabel('Y')
ax.set_ylim3d(-1, 4)
ax.set_zlabel('Z')
ax.set_zlim3d(0, 1)

Hi there, 
I've boiled down a problem and while the following my look useless, I need to understand why matplotlib is behaving like it is.
Below is code showing my issue. I don't believe the issue is with the "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400, but the last row is a row of transparent pixels(on linux/not mac). It's difficult to see unless you use the imagemagik command display.
The basic problem is that when my data has an aspect ratio very close to 1.75, the image gets changed to one with an aspect of 1.74875.
Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
Incorrect figure info => 800x1399 => 1.74875
Data that works aspect ratio: 1.7499999999999998
Data that fails aspect ratio: 1.7499999999999996
---> Srsly?! -------------------------------^
It would be great if someone could explain to me what's happening if this is indeed working as expected. If it's not, it would be great if someone could fix it.
Thanks in advance.
Matt
import matplotlib.pyplot as plt
def create_image():
 # I want an 800x1400 image (aspect = 1400/800 = 1.75.
 fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)
 # Use the whole figure and fill with a patch.
 fig.add_axes([0, 0, 1, 1])
 ax = plt.gca()
 limb = ax.axesPatch
 limb.set_facecolor('#6587ad')
 # Set some bounds with Aspects very close to the desired aspect ratios.
 x1 = 0.0
 y1 = 0.0
 x2 = 16.
 # If you un-comment out this line (and comment the one below). I get an image I expect
 # y2 = 27.999999999999994671 # produces 800 x 1400 image
 # aspect = 1.7499999999999998 works
 # Use this line and I get and image the wrong size (or with transparent pixels.)
 y2 = 27.999999999999994670 # produces (wrong?) 800 x 1399 image
 # aspect = 1.7499999999999996 Fails? wat?
 corners = ((x1, y1), (x2, y2))
 ax.update_datalim(corners)
 ax.set_xlim((x1, x2))
 ax.set_ylim((y1, y2))
 ax.set_aspect('equal', anchor='C')
 ax.set_xticks([])
 ax.set_yticks([])
 plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')
 # If you use this below, the file size is correct, but there is a single
 # line transparent pixels along the bottom of the image
 # plt.savefig('rectangle.png', pad_inches=0.0)
if __name__ == '__main__':
 create_image()

On 2012年11月19日 11:42 AM, TP wrote:
> Hi everybody,
>
> I have a problem with LinearSegmentedColormap.
> In the example below (see PS), I make a colormap, and use it to plot an
> EllipseCollection. My plot is parameterized by a quantity that I have named
> "large_value". For large_value equal to 257, a blue point is obtained at
> (x=0.3, y=0.4). But for large_value equal to 258, it becomes black.
>
> This is because of the way LinearSegmentedColormap is working. It has a
> parameter N which allows to set the "number of colors":
>
> http://matplotlib.org/api/colors_api.html#matplotlib.colors.LinearSegmentedColormap
>
> It is 256 by default, so if I increase N to a greater value, the point remains
> blue for large_value equal to 258.
>
> Now, my real plot (not this dummy example) is such that I need N to be very
> large so as to obtain the right colors on my plot, although very few colors
> are used at the end.
> However, when N is too large, the plot becomes very slow, and a lot of memory
> is used; I think because an array is probably built with this size, although
> in theory there is no need to construct such a complete array.
>
> Is there an easy workaround, or have I to study and modify the matplotlib code
> myself?
It is not entirely clear to me what you are trying to do, but it sounds 
like increasing N is not the right way to do it. Three things might help 
you find a better way:
1) The colormap is intended to work with a norm that handles the 
translation from your data numbers to the 0-1.0 range used to select 
values from the colormap (with exceptions--see below). You can choose a 
non-default norm, you can write your own, or you can set the parameters 
(vmin, vmax) of the standard linear norm.
2) By creating a colormap and calling its set_under, set_over, and 
set_invalid methods, you can control the colors assigned to data values 
that your norm maps respectively to negative numbers, numbers greater 
than 1, and masked values. See 
http://matplotlib.org/examples/pylab_examples/contourf_demo.html for an 
example of using set_under and set_over. See 
http://matplotlib.org/examples/pylab_examples/image_masked.html for 
another example, and for an example of controlling the norm parameters 
or using an alternative norm.
3) It is also possible to index directly into the colormap if you use a 
norm that returns an integer data type. An example of such is the 
BoundaryNorm. 
http://matplotlib.org/examples/pylab_examples/multicolored_line.html
If all you need is a single assignment of a color to a "large value", 
then using the set_over method will take care of it.
Eric
>
> Thanks,
>
> TP
>
> PS: Here is the test code:
> ##################
> from pylab import *
> from matplotlib.colors import LinearSegmentedColormap
> from matplotlib.collections import CircleCollection
>
> ioff()
> large_value = 257 # blue below this value
> #large_value = 258 # black above this value
> N = 1e5 # 256 by default
>
> cdict = { 'blue': [(0.0, 0.0, 0.0),
> (2*1/large_value, 1, 1)
> , (1.0, 1.0, 1.0)]
> , 'green': [(0.0, 0.0, 0.0),
> (2*1/large_value, 0, 0)
> , (1.0, 1.0, 1.0)]
> , 'red': [(0.0, 0.0, 0.0),
> (2*1/large_value, 0, 0),
> (1.0, 1.0, 1.0)] }
>
> measures= array([[ 0.2, 0.3, 1],
> [ 0.3, 0.4, 2],
> [ 0.5, 0.6, large_value]])
>
> cmap = LinearSegmentedColormap( "cmap foobar"
> , cdict
> # , N= N )
> )
>
> fig = figure()
> axes = fig.add_subplot(111)
> ec = CircleCollection( [80]
> , offsets = measures[:,:2]
> , transOffset = axes.transData
> )
>
> ec.set_array( measures[:,2] )
> ec.set_cmap( cmap )
> axes.add_collection( ec )
>
> show()
> ##################
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi everybody,
I have a problem with LinearSegmentedColormap.
In the example below (see PS), I make a colormap, and use it to plot an 
EllipseCollection. My plot is parameterized by a quantity that I have named 
"large_value". For large_value equal to 257, a blue point is obtained at 
(x=0.3, y=0.4). But for large_value equal to 258, it becomes black.
This is because of the way LinearSegmentedColormap is working. It has a 
parameter N which allows to set the "number of colors":
http://matplotlib.org/api/colors_api.html#matplotlib.colors.LinearSegmentedColormap
It is 256 by default, so if I increase N to a greater value, the point remains 
blue for large_value equal to 258.
Now, my real plot (not this dummy example) is such that I need N to be very 
large so as to obtain the right colors on my plot, although very few colors 
are used at the end.
However, when N is too large, the plot becomes very slow, and a lot of memory 
is used; I think because an array is probably built with this size, although 
in theory there is no need to construct such a complete array.
Is there an easy workaround, or have I to study and modify the matplotlib code 
myself?
Thanks,
TP
PS: Here is the test code:
##################
from pylab import *
from matplotlib.colors import LinearSegmentedColormap
from matplotlib.collections import CircleCollection
ioff()
large_value = 257 # blue below this value
#large_value = 258 # black above this value
N = 1e5 # 256 by default
cdict = { 'blue': [(0.0, 0.0, 0.0),
 (2*1/large_value, 1, 1)
 , (1.0, 1.0, 1.0)]
 , 'green': [(0.0, 0.0, 0.0),
 (2*1/large_value, 0, 0)
 , (1.0, 1.0, 1.0)]
 , 'red': [(0.0, 0.0, 0.0),
 (2*1/large_value, 0, 0),
 (1.0, 1.0, 1.0)] }
measures= array([[ 0.2, 0.3, 1],
 [ 0.3, 0.4, 2],
 [ 0.5, 0.6, large_value]])
cmap = LinearSegmentedColormap( "cmap foobar"
 , cdict
 # , N= N )
 )
fig = figure()
axes = fig.add_subplot(111)
ec = CircleCollection( [80]
 , offsets = measures[:,:2]
 , transOffset = axes.transData
 )
ec.set_array( measures[:,2] )
ec.set_cmap( cmap )
axes.add_collection( ec )
show()
##################

On Mon, Nov 19, 2012 at 7:44 AM, Nelle Varoquaux
<nel...@gm...> wrote:
> This is not the "correct" way to run the tests.
Then that explains it, thanks.
>> Does the same thing happen with the following command:
>>
>> python -c "import matplotlib; matplotlib.test()"
No, all tests pass (or fail when they are expected to).
> "KnownFailure" is not a "default" nosetest packages. Hence, we have to load
> it manually when running the tests.
Thanks, makes sense.
Cheers
Adam

Chao,
I'm glad you were able to get what you wanted. 
I don't know how to add anything to the gallery.
-Sterling
On Nov 17, 2012, at 3:32AM, Chao YUE wrote:
> Hi Sterling,
> 
> Thanks for the help. Now we have a complete script that works as what we want:
> 
> ****labels parallel with the colorbar with colorbar seperated ****
> 
> By the way, is it possible to put in the gallery?
> 
> 
> from pylab import *
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> cs=contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks(cbarlevel)
> 
> #prepare the final label that we want
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append(" {0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> 
> cbar.set_ticklabels(['']*len(cbarlevel)) #remove the original labels
> #set ticks as white; the 'length' parameter is a bit dirty solution
> cbar.ax.tick_params(axis='y',left='on',length=10,color='w',width=5)
> cbar.outline.remove() #remove the colorbar frame
> 
> #add the label parallel to colorbar; 0.035 to be set by manual observation, a bit dirty solution.
> yloc=np.arange(0.035,0.95,0.1)
> for l,y in zip(cbar_label,yloc):
> cbar.ax.text(1,y,l,transform=cbar.ax.transAxes,ha='left')
> 
> cheers,
> 
> Chao
> 
> On Sat, Nov 17, 2012 at 12:12 AM, Sterling Smith <sm...@fu...> wrote:
> Chao,
> 
> If you don't need the tick marks and are only annoyed by their appearance in the colorbar, then I am pasting below our code so far setting the tick length to 0.
> 
> Code so far:
> 
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> 
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> 
> #Then to apply on the colorbar:
> cbar.set_ticklabels(cbar_label)
> 
> ax = fig.axes[-1] #This is not as clean as making the axes before the colorbar and passing to the colorbar...
> ax.yaxis.set_tick_params(length=0)
> 
> 
> If you still want the ticks, then you might think of keeping the ticks where you had set them originally, then placing texts (pylab.text) with the transAxes transform, using the following script:
> 
> 
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> #cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> cbar.set_ticks(cbarlevel)
> 
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> #cbar_label.append('')
> 
> print cbar_label
> #['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> #'80-90', '90-100', '']
> 
> #Then to apply on the colorbar:
> cbar.set_ticklabels(['']*len(cbarlevel))
> 
> ax = fig.axes[-1]
> #ax.yaxis.set_tick_params(length=0)
> 
> yloc = linspace(0,1,len(cbar_label)+1)
> yloc = yloc[:-1] + yloc[1]/2.
> for l,y in zip(cbar_label,yloc):
> ax.text(1,y,l,transform=ax.transAxes,ha='left')
> draw()
> 
> -Sterling
> 
> On Nov 16, 2012, at 12:58PM, Chao YUE wrote:
> 
> > Thanks Sterling. It's a good idea.
> >
> > Unluckily, I lose the original ticks and the ticks appeared in the middle. Is there any approach I can keep the original ticks while realizing what has been shown in the figure?
> >
> > Chao
> >
> > On Fri, Nov 16, 2012 at 5:47 PM, Sterling Smith <sm...@fu...> wrote:
> > Chao,
> >
> > The secret is positioning your ticks. I list here an untested attempt at putting the labels at the average of the current and next levels:
> >
> > cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> >
> > Because you have less ticks, then you will want to remove the line
> >
> > cbar_level.append('')
> >
> > Hope that helps,
> > Sterling
> >
> > On Nov 16, 2012, at 7:46AM, ChaoYue wrote:
> >
> > > I have a bit progress, but still not very well.
> > >
> > > #to have a contourf plot
> > > a = np.arange(100).reshape(10,10)
> > > cbarlevel=np.arange(0,101,10)
> > > contourf(a,levels=cbarlevel)
> > > cbar = colorbar()
> > > cbar.set_ticks(cbarlevel)
> > >
> > > #to manipulate the range:
> > > cbar_label = []
> > > for i in range(len(cbarlevel)-1):
> > > cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> > > cbar_label.append('')
> > >
> > > In [54]: print cbar_label
> > > ['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> > > '80-90', '90-100', '']
> > >
> > > #Then to apply on the colorbar:
> > > cbar.set_ticklabels(cbar_label)
> > >
> > > The generated figure is attached. But how can I put the labels a little bit
> > > upward to make them parallel with the respective small rectangles in the
> > > colorbar? <http://matplotlib.1069221.n5.nabble.com/file/n39786/fig.jpg>
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39786.html
> > > Sent from the matplotlib - users mailing list archive at Nabble.com.
> > >
> > > ------------------------------------------------------------------------------
> > > Monitor your physical, virtual and cloud infrastructure from a single
> > > web console. Get in-depth insight into apps, servers, databases, vmware,
> > > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > > Pricing starts from 795ドル for 25 servers or applications!
> > > http://p.sf.net/sfu/zoho_dev2dev_nov
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> >
> > --
> > ***********************************************************************************
> > Chao YUE
> > Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> > UMR 1572 CEA-CNRS-UVSQ
> > Batiment 712 - Pe 119
> > 91191 GIF Sur YVETTE Cedex
> > Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
> > ************************************************************************************
> >
> > <fig.jpg>
> 
> 
> 
> 
> -- 
> ***********************************************************************************
> Chao YUE
> Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
> UMR 1572 CEA-CNRS-UVSQ
> Batiment 712 - Pe 119
> 91191 GIF Sur YVETTE Cedex
> Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
> ************************************************************************************
> 

Hello,
Hi
>>
>> When running the testsuite for matplotlib-1.2.0 i.e.
>>
>> $ nosetests -exe matplotlib
>>
>
This is not the "correct" way to run the tests. You need to run them using:
python tests.py
I currently have a PR that indicates that in the README
> I'm getting a lot of errors of the form:
>>
>>
> Does the same thing happen with the following command:
>
> python -c "import matplotlib; matplotlib.test()"
>
That's another way of running the tests on matplotlib.
>
> I haven't used nosetest before, so I have no clue if it does anything
> different than we expect.
>
"KnownFailure" is not a "default" nosetest packages. Hence, we have to load
it manually when running the tests.
Hence, all the tests that are known to fail actually fail, so that what we
"expect".
Cheers,
N
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from 795ドル for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On Sun, Nov 18, 2012 at 5:51 PM, Adam Mercer <ram...@gm...> wrote:
> Hi
>
> When running the testsuite for matplotlib-1.2.0 i.e.
>
> $ nosetests -exe matplotlib
>
> I'm getting a lot of errors of the form:
>
>
Does the same thing happen with the following command:
python -c "import matplotlib; matplotlib.test()"
I haven't used nosetest before, so I have no clue if it does anything
different than we expect.
Ben Root

Mathew Topper wrote:
> Hi,
> 
> I'm interested to know why the pip package manager is not more widely
> supported for installation of python packages like matplotlib?
> Matplotlib seems to be particularly slowly updated in the Fedora
> repositories, for example, so I often find that a source installation is
> necessary. I know this isn't especially difficult for the experienced
> user, but surely using something like pip would make this process for
> accessible for all users of python packages, particularly those that do
> not receive much attention from the big distribution maintainers? Yet,
> pip doesn't get a mention on the installation documentation of
> matplotlib or many other python packs.
> 
> I would love to hear anyone's thoughts on this matter.
> 
> Many Thanks,
> 
> Mat
It is dangerous to use pip on fedora, it may result in your next attempt to 
update the system failing horribly.
If you use it, try to install with --user. Unfortunately, this often won't work 
because pip will then complain when attempting to remove a system version of 
some dep.