You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(16) |
2
(22) |
3
(28) |
4
(17) |
5
(17) |
6
(7) |
|
7
|
8
(15) |
9
(28) |
10
(26) |
11
(28) |
12
(19) |
13
(5) |
|
14
(3) |
15
(21) |
16
(28) |
17
(11) |
18
(18) |
19
(6) |
20
(5) |
|
21
(18) |
22
(11) |
23
(22) |
24
(28) |
25
(17) |
26
(17) |
27
(7) |
|
28
(16) |
29
(24) |
30
(25) |
31
(14) |
|
|
|
|
From: klukas <kl...@wi...> - 2010-03-17 20:33:46
|
I'm guessing this is currently impossible with the current mplot3d functionality, but I was wondering if there was any way I could generate a 3d graph with r, phi, z coordinates rather than x, y, z? The point is that I want to make a figure that looks like the following: http://upload.wikimedia.org/wikipedia/commons/7/7b/Mexican_hat_potential_polar.svg Using the x, y, z system, I end up with something that has long tails like this: http://upload.wikimedia.org/wikipedia/commons/4/44/Mecanismo_de_Higgs_PH.png If I try to artificially cut off the data beyond some radius, I end up with jagged edges that are not at all visually appealing. I would appreciate any crazy ideas you can come up with. Thanks, Jeff P.S. Code to produce the ugly jaggedness is included below: ------------------------------------------------------- from mpl_toolkits.mplot3d import Axes3D import matplotlib import numpy as np from matplotlib import cm from matplotlib import pyplot as plt step = 0.04 maxval = 1.0 fig = plt.figure() ax = Axes3D(fig) X = np.arange(-maxval, maxval, step) Y = np.arange(-maxval, maxval, step) X, Y = np.meshgrid(X, Y) R = np.sqrt(X**2 + Y**2) Z = ((R**2 - 1)**2) * (R < 1.25) ax.plot_surface(X, Y, Z, rstride=1, cstride=1, cmap=cm.jet) ax.set_zlim3d(0, 1) #plt.setp(ax.get_xticklabels(), visible=False) 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() -- View this message in context: http://old.nabble.com/Polar-3D-plot--tp27937798p27937798.html Sent from the matplotlib - users mailing list archive at Nabble.com. |
|
From: David <ld...@gm...> - 2010-03-17 20:17:16
|
Dear Michael,
I deeply appreciate your help with this!
On 17/03/10 20:34, Michael Droettboom wrote:
>> I have tried
>>
>> import matplotlib
>> matplotlib.use('GtkCairo')
>>
>> as you suggested, but they had no effect whatsoever. Even the error
>> output is the same.
> I'm surprised that isn't having any effect. The Cairo backend should not
> be running any code in backend_ps.py -- where the source of the error
> is. If you put "backend: GtkCairo" in your matplotlibrc, does that work?
No, in fact, after adding that line to matplotlibrc the CJK isn't even
rendered in the png anymore! *
My error message has changed:
In [1]: run dea.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:614:
DeprecationWarning: Use the new widget gtk.Tooltip
self.tooltips = gtk.Tooltips()
(this with "backend: GtkCairo" in matplotlibrc and the following two
lines in my dea.py:
import matplotlib
matplotlib.use('GtkCairo')
Incidentally, if I uncomment those two lines, then the (Western) font of
my graph actually changes.
> What version of matplotlib are you running?
In [2]: matplotlib.__version__
Out[2]: '0.99.0'
>> Note: in line 327 and 328 of the matplotlibrc I have added
>>
>> ps.fonttype=42
>> pdf.fonttype=42
I haven taken those out again, because I got an error message.
I continue to be at a loss!
David
* I had the same problem yesterday, I solved it by reinstalling a backup
of matplotlibrc. Weird.
>>
>> whereas I have uncommented
>>
>> pdf.fonttype : 3
>>
>> Any ideas? I would most welcome any hint and suggestion!
> I don't think these settings will resolve the problem -- either font
> type (42 or 3) still expects glyph names.
>
> Mike
>>
>>
>>
>>
>> On 17/03/10 04:15, Michael Droettboom wrote:
>>> The font you are using (SimHei) does not have any glyph names -- these
>>> are used in the Postscript backend to refer to glyphs outside of the
>>> ASCII range. More specifically, it looks like it has at least one
>>> invalid glyph name (glyph names can only contain ASCII characters) --
>>> loading it in FontForge complains about this. I haven't come across such
>>> a font before, but maybe that's common in CJK fonts. I don't know. I'm
>>> looking through the spec to find a way that glyphs can be referenced
>>> without a name, but I'm not finding one. Note, the PDF backend has the
>>> same issue.
>>>
>>> Do you have the same problem if you remove "SimHei" from the
>>> font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
>>> to find an online download of SimHei to test with, but not Adobe Song
>>> Std).
>>>
>>> As a workaround, the Cairo backend seems to handle this font just fine.
>>> You can add
>>>
>>> import matplotlib
>>> matplotlib.use('GtkCairo')
>>>
>>> to the top of your script.
>>>
>>> Mike
>>>
>>> David wrote:
>>>> Hello everybody,
>>>>
>>>> I have a final problem with my graph. As a last step I produce an
>>>> *.eps file that I use in conjunction with LaTeX.
>>>>
>>>> Here is the last part of my code:
>>>>
>>>> # plt.title('Title')
>>>> xlab = plt.xlabel(u'输入 1')
>>>> #xlab.set_position((0.2, 0.1))
>>>> ylab = plt.ylabel(u'输入 2')
>>>> plt.grid(True)
>>>> plt.subplots_adjust(bottom=0.2)
>>>> plt.show()
>>>> plt.savefig('dea.eps')
>>>>
>>>>
>>>> plt.show() produces the correct output,
>>>>
>>>> but
>>>>
>>>> plt.savefig('dea.eps') produces an error (the error message is
>>>> attached).
>>>>
>>>> The error is clearly linked to the Chinese, as it runs through if I
>>>> take the Chinese out of the code.
>>>> Also, plt.savefig('dea.png') works fine.
>>>>
>>>> Could anyone indicate where I would have to look for the mistake? The
>>>> matplotlibrc should be fine, but I am not sure.
>>>>
>>>> Your help would be greatly appreciated!
>>>>
>>>> Many thanks,
>>>>
>>>> David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> Download Intel® 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-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>
|
|
From: Ilya S. <ily...@al...> - 2010-03-17 20:10:36
|
Is it possible to serialize a figure constructed in matplotlib/pyplot, so that you could quickly load it and then save it in new formats and/or interactively explore it? thanks, ilya |
|
From: Friedrich R. <fri...@gm...> - 2010-03-17 18:18:28
|
Maybe:
from matplotlib import pyplot as plt
figureOne = plt.figure()
axesOne = figureOne.add_axes([0, 0, 1, 1])
axesOne.plot([-1, 1], [-2, 2])
axesOne.plot([-2, 2], [-1, 1])
axesOne.set_xlim((-3, 3))
axesOne.set_ylim((-3, 3))
figureOne.set_figwidth(2)
figureOne.set_figheight(2)
plt.savefig("Friedrich.png")
Friedrich
|
|
From: <tom...@gm...> - 2010-03-17 17:20:10
|
Hi everyone, Is there a straightforward way for me to ensure that my data is centered: allways present on the figure? I'm plotting the results from complicated geometrical calculations and I need high dpi so that I can debug the code. I've recorded the session in a log file and I've modified the ipython logfile into a script. The result is here: http://img87.imageshack.us/img87/8306/interfaceprojections.png and the script is here: http://pastebin.com/3dkfNDuk As you see, in the image, a part of the rectangle is missing. It is actually sort of a rectangle shaped set of finite volumes. What I'm looking for is to have the whole rectangle (or any other shape) visible on the axes of the figure, with a properly scaled axes ratio ('equal' in the script). And to reduce the output, could it be possible to plot just the diagram, without the remaining whitespace? It seems that when I use figureOne.set_figheight(number) figureOne.set_figwidth(number) it stands for the figure, but not for the axes. I'm interested just in the axes since it's the only subplot. Any advice? I looked in the user guide but I didn't find anything so far... I'll keep looking. Thank you in advance, Tomislav |
|
From: John H. <jd...@gm...> - 2010-03-17 14:05:45
|
On Wed, Mar 17, 2010 at 4:10 AM, Matthias Michler <Mat...@gm...> wrote: > once more I'd like to ask for comments about my feature request and proposed > patch. > Should I post it at the 'feature request' or 'patch' tracker? > > Thanks in advance for any comments. Hey Matthias -- This should be placed on the patch tracker, and you can respond back to this list with a link to the patch. I'll review it when I get a minute. Thanks for following up and for making patches against branch and HEAD. JDH |
|
From: Michael D. <md...@st...> - 2010-03-17 12:34:38
|
David wrote:
> Dear Michael,
>
> thanks for your input. So far, though, no luck.
>
> I have deleted "SimHei" in matplotlibrc, and I can then continue
> generating CJK characters. The png is generated, the eps is not. Thus,
> no change. The error output is also the same:
>
> RuntimeError: Face has no glyph names
> WARNING: Failure executing file: <dea.py>
>
> I have tried
>
> import matplotlib
> matplotlib.use('GtkCairo')
>
> as you suggested, but they had no effect whatsoever. Even the error
> output is the same.
I'm surprised that isn't having any effect. The Cairo backend should
not be running any code in backend_ps.py -- where the source of the
error is. If you put "backend: GtkCairo" in your matplotlibrc, does
that work?
What version of matplotlib are you running?
>
> I attach my code, maybe that gives a hint.
>
> Note: in line 327 and 328 of the matplotlibrc I have added
>
> ps.fonttype=42
> pdf.fonttype=42
>
> whereas I have uncommented
>
> pdf.fonttype : 3
>
> Any ideas? I would most welcome any hint and suggestion!
I don't think these settings will resolve the problem -- either font
type (42 or 3) still expects glyph names.
Mike
>
>
>
>
> On 17/03/10 04:15, Michael Droettboom wrote:
>> The font you are using (SimHei) does not have any glyph names -- these
>> are used in the Postscript backend to refer to glyphs outside of the
>> ASCII range. More specifically, it looks like it has at least one
>> invalid glyph name (glyph names can only contain ASCII characters) --
>> loading it in FontForge complains about this. I haven't come across such
>> a font before, but maybe that's common in CJK fonts. I don't know. I'm
>> looking through the spec to find a way that glyphs can be referenced
>> without a name, but I'm not finding one. Note, the PDF backend has the
>> same issue.
>>
>> Do you have the same problem if you remove "SimHei" from the
>> font.sans-serif list and thus use "Adobe Song Std" instead? (I was able
>> to find an online download of SimHei to test with, but not Adobe Song
>> Std).
>>
>> As a workaround, the Cairo backend seems to handle this font just fine.
>> You can add
>>
>> import matplotlib
>> matplotlib.use('GtkCairo')
>>
>> to the top of your script.
>>
>> Mike
>>
>> David wrote:
>>> Hello everybody,
>>>
>>> I have a final problem with my graph. As a last step I produce an
>>> *.eps file that I use in conjunction with LaTeX.
>>>
>>> Here is the last part of my code:
>>>
>>> # plt.title('Title')
>>> xlab = plt.xlabel(u'输入 1')
>>> #xlab.set_position((0.2, 0.1))
>>> ylab = plt.ylabel(u'输入 2')
>>> plt.grid(True)
>>> plt.subplots_adjust(bottom=0.2)
>>> plt.show()
>>> plt.savefig('dea.eps')
>>>
>>>
>>> plt.show() produces the correct output,
>>>
>>> but
>>>
>>> plt.savefig('dea.eps') produces an error (the error message is
>>> attached).
>>>
>>> The error is clearly linked to the Chinese, as it runs through if I
>>> take the Chinese out of the code.
>>> Also, plt.savefig('dea.png') works fine.
>>>
>>> Could anyone indicate where I would have to look for the mistake? The
>>> matplotlibrc should be fine, but I am not sure.
>>>
>>> Your help would be greatly appreciated!
>>>
>>> Many thanks,
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Download Intel® 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-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>
> ------------------------------------------------------------------------
>
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
|
|
From: Josh H. <jh...@vn...> - 2010-03-17 05:51:17
|
Gökhan SEVER-2 wrote: > > Oh these busy chemical compound plots :) Are those results of gas > chromatography analysis? > > Something like below produces a nice fully plotted output here. Could you > give it a try? > > import matplotlib.pyplot as plt > plt.plot(range(100)) > locs, labels = plt.xticks(range(100), range(100)) > plt.setp(labels, rotation=90, fontsize=7) > plt.show() > > > -- > Gökhan > Gokhan, Your suggestion works great. I guess the MaxNLocator approach I have been using will place __up__to__ N ticks but not necessarily N ticks? And yes, these chemical profiles are from GCMS and other devices/techniques. I added upper X axis tick labels so you know a given chemical species' name and number; I chose to only have one legend to keep the clutter down as much as possible; I position the upper X axis labels in or outside the plot depending on whether the plot title exists. Luckily, I don't imagine having to deal with more species than 105 any time soon. Thanks again! Here is the improved plot (sorry for the pink background, I am not sure why it is showing up that way): http://old.nabble.com/file/p27927991/PMF2BasecaseProfiles.jpeg ----- Josh Hemann Statistical Advisor http://www.vni.com/ Visual Numerics jhemann at vni dizzot com -- View this message in context: http://old.nabble.com/Is-there-a-maximum-number-of-x-tickmarks--tp27924845p27927991.html Sent from the matplotlib - users mailing list archive at Nabble.com. |
|
From: David S. <dav...@gm...> - 2010-03-17 03:54:32
|
Eric, Thank you, thank you, thank you. This not only fixes the problem I reported with with FixedLocator(..) but also another one where I was using MultipleLocator(..) and getting the same problem issue with dropping first and last contours. The later isn't as easy to work-around but your change fixed it. David Smith On Sat, Mar 13, 2010 at 12:30 PM, Eric Firing <ef...@ha...> wrote: > David Smith wrote: > >> This is a bug report. >> >> I am using matplotlib 0.99.1 on Windows. When using contour with the >> keyword >> argument locator=ticker.FixedLocator(levels), the plot is always dropping >> the first >> and last contour level. If there are less than 3 levels, contour.py >> throws an >> exception. >> >> My workaround is to duplicate the first and last levels when using the >> fixed locator: e.g. my argument becomes >> >> locator=FixedLocator( [levels[0]] + levels + [levels[-1]] ) >> >> I have traced the problem to the last line in contour.py, method >> _autolev() which >> strips the first and last levels if the contours are not filled: >> >> return lev[1:-1] >> >> This line occurs at line 682 in my version of contour.py which came with >> the 0.991 installation. >> >> I realize that I could specify the levels in the argument V and this does >> work. However >> this code is embedded in GUI-ness which allows the user to choose how the >> contours >> are selected. Passing the locator seems to be the best option code-wise. >> > > I committed a small change to svn trunk (r8190) that I think will handle > your use case without fouling anything else up. > > Eric > > >> Thank you, >> >> Dave Smith >> >> |