SourceForge logo
SourceForge logo
Menu

matplotlib-users — Discussion related to using matplotlib

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
(20)
2
(16)
3
(9)
4
(12)
5
(14)
6
(22)
7
(17)
8
(33)
9
(26)
10
(32)
11
(47)
12
(26)
13
(7)
14
(24)
15
(44)
16
(42)
17
(22)
18
(31)
19
(8)
20
(4)
21
(15)
22
(27)
23
(41)
24
(33)
25
(31)
26
(24)
27
(10)
28
(20)






Showing results of 620

<< < 1 2 3 4 .. 25 > >> (Page 2 of 25)
From: John H. <jd...@gm...> - 2010年02月27日 02:27:36
On Fri, Feb 26, 2010 at 6:35 PM, mikey <abc...@go...> wrote:
> Sorry a rather stupid question as there are '.'s available. Although I
> wouldn't mind knowing if it's possible to tinker with the sizes of
> 'o's and '.'s.
See the "markersize" parameter
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.plot
JDH
From: Gökhan S. <gok...@gm...> - 2010年02月27日 02:27:12
On Fri, Feb 26, 2010 at 6:29 PM, mikey <abc...@go...> wrote:
> Hi there,
>
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
>
> Regards,
>
> Mikey
>
>
Hey,
Try:
I[1]: plt.plot(range(100), "o", markersize=100)
I[2]: plt.plot(range(100), "o", markersize=1)
I[3]: plt.figure(); plt.plot(range(100), "o", ms=1)
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Gökhan
From: <PH...@Ge...> - 2010年02月27日 02:12:38
> -----Original Message-----
> From: mikey [mailto:abc...@go...]
> Sent: Friday, February 26, 2010 4:29 PM
> To: mat...@li...
> Subject: [Matplotlib-users] Change the size of the plotted 'o's ?
> 
> Hi there,
> 
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
Mike,
There are a couple of ways. See below:
# untested, might have typos ~~~~
import numpy as np
import matplotlib.pyplot as pl
x = np.random.randn(20)
fig = pl.figure()
ax = pl.add_subplot(1,1,1)
# you can specify the marker size two ways directly:
ax.plot(x, 'ko', markersize=4) # size in points
ax.plot(x, 'bs', ms=4) % ms is just an alias for markersize
# or you can specify it after the plotting:
X = ax.plot(x, 'ko') # X is a *list* of line2d objects...
X[0].set_markersize(4) # set_ms works too
# or...
pl.setp(Y, markersize=4) # again, ms works.
# ~~~~~~~~
For a list of all the properties you can tweak, type:
pl.getp(<object>)
HTH,
-paul
From: mikey <abc...@go...> - 2010年02月27日 01:23:58
Hi there,
I've just made script for displaying discrete data clustered in boxes
on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
seem a reasonable size on screen but when I render it to file they
look huge so I'd like to reduce their size. Does anyone know how this
is done?
Regards,
Mikey
From: mikey <abc...@go...> - 2010年02月27日 01:06:58
Sorry a rather stupid question as there are '.'s available. Although I
wouldn't mind knowing if it's possible to tinker with the sizes of
'o's and '.'s.
Thanks,
Mikey
On 27 February 2010 00:29, mikey <abc...@go...> wrote:
> Hi there,
>
> I've just made script for displaying discrete data clustered in boxes
> on my graph. The plots are plotted with plt.plot(x,y,'o') and the 'o's
> seem a reasonable size on screen but when I render it to file they
> look huge so I'd like to reduce their size. Does anyone know how this
> is done?
>
> Regards,
>
> Mikey
>
From: Friedrich R. <fri...@gm...> - 2010年02月26日 23:16:43
> I also agree with Reinier. I want my 3d plots to look as close as possible to my 2d plots. Because mplot3d uses so much of the same matplotlib core, this is trivial. As Friedrich mentioned, the mplot3d code is actually pretty small. To me, that is a great feature.  I found the mplot3d code very accessible.
Yes, I agree that it's really readable. But I didn't understand the
sorting algorithm in plot_surface().
> I do agree that there is still much work to be done in mplot3d. But I think starting from scratch is a waste of time.
Well, I see ... When I write code "from scratch" as I often do, I mean
to open a new file and to copy old code only if it useful or
necessary. So I don't want to break the old code. I in fact think
the current code is doing good work. But to my perception, it
nevetheless needs some additional concepts like the global "surface
space" and another sorting algorithm.
> FYI, I looked into using mayavi2 before settling on mplot3d. Mayavi can create some stunning graphics, but I found that it is very restrictive in its plotting options. Take for example the 3d scatter plot. They combined the size and color parameter. Getting around this strange restriction took me quite some time. (Installation for me was also a pain due to VTK).
That's important information, at least for me. I was so impressed by
mayavi, that I was near to be stopped from all enthusiasm for mplot3d.
 But I see, there would be some use. The arguments you gave are
already quite strong. I think the possibility to plot 2d things in 3d
context like a stack of curves using the matplotlib style seems to be
quite a good thing, isn't it?
I would like to tell some "fresh look" onto the problem just coming
into my mind. What about turning matplotlib itself into the 3D
rendering engine? This would maybe be like a fork. But it would
leave all matplotlib commands intact, putting the layer like this:
matplotlib
------------------
3D rendering engine
------------------
backend
Instead of:
3D rendering engine
--------------------
matplotlib
--------------------
backend.
I mean, the matplotlib would create some kind of plotting commands,
either 2d or 3d. The 3d ones would be translated into 2d camera space
by the intersecting layer. 2d ones would be promoted to the 3d camera
space before being projected into the 2d camera space. This is a raw
idea, I'm shure, so please don't kill me for it. When it turns out to
be without substance, I would not be offended.
How feasible would this be?
Friedrich
P.S.: But it would maybe simplify the sorting much. The 3D engine
stores the projected polygons with z information (z as the depth from
the camera). When another polygon arrives, it will be cut /after
projection/ into pieces based on the polygons in front of it, and be
drawn upon all polygons behind. The weel again?
P.P.S.: I'm very un-self-confident about this ideas. But I read, in
OSS one should also publish half-baken ideas, even when they do not
compile ...
From: brianjpetersen <bri...@gm...> - 2010年02月26日 23:14:54
Hi All,
I'm a new matplotlib user on a Windows XP machine running mpl0.99.0 under
Python 2.5. I'm using the default rc file.
While reading through the excellent matplotlib "how-to" tutorial
(http://matplotlib.sourceforge.net/faq/howto_faq.html), I came across two
useful scripts: one to save a figure with a transparent background, and one
to resize axes automatically so that labels aren't cut off. I was able to
run both these examples given on the "how-to" successfully.
However, I ran into trouble when trying to combine them as follows:
=====
import matplotlib.pyplot as plt
import matplotlib.transforms as mtransforms
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot(range(10))
ax.set_yticks((2,5,7))
labels = ax.set_yticklabels(('really, really, really', 'long', 'labels'))
def on_draw(event):
 bboxes = []
 for label in labels:
 bbox = label.get_window_extent()
 # the figure transform goes from relative coords->pixels and we
 # want the inverse of that
 bboxi = bbox.inverse_transformed(fig.transFigure)
 bboxes.append(bboxi)
 # this is the bbox that bounds all the bboxes, again in relative
 # figure coords
 bbox = mtransforms.Bbox.union(bboxes)
 if fig.subplotpars.left < bbox.width:
 # we need to move it over
 fig.subplots_adjust(left=1.1*bbox.width) # pad a little
 fig.canvas.draw()
 
 return False
fig.canvas.mpl_connect('draw_event', on_draw)
plt.savefig('test.png', transparent=True)
=====
In this case, the saved png file is transparent, but the original set of
axes, labels, and plot are visible as well (basically, I have two identical
plots shifted over one another on a transparent background).
Is there a way to suppress the original output (something akin to
"fig.canvas.erase()" or "fig.canvas.clear()", but I can't seem to figure it
out) so that the output png only shows the shifted axes and not both sets?
Thanks in advance!
Brian
-- 
View this message in context: http://old.nabble.com/Transparency-with-fig.canvas.mpl_connect-tp27724532p27724532.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
From: Gökhan S. <gok...@gm...> - 2010年02月26日 23:08:26
Thanks again. I didn't know it was complete :)
For the second idea you mean something as generic as plotting such markers?
plt.plot(range(10), linestyle='None', marker=u'(注記) ')
On Fri, Feb 26, 2010 at 2:56 PM, Michael Droettboom <md...@st...> wrote:
> SVN trunk has support for mathtext as symbol markers --
>
> plot(range(10), linestyle='None', marker=r'$\clubsuit$')
>
> We could support arbitrary (non-math) text, too, fairly easily. We just
> need to invent a syntax for it.
>
> Mike
>
> Gökhan Sever wrote:
>
>> Thanks Mike. The Greek symbols become visible when I make the changes as
>> you suggested. DejaVu Sans has been installed in my system (Fedora 12). We
>> might put a note on the documentation stating to get wider Unicode coverage
>> people could install additional fonts --DejaVu Sans being one of them
>> instead of shipping the fonts with matplotlib.
>>
>> With my working unicode example, now I have three ways to show u^-2 on
>> labels. See the code at:
>> http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py
>>
>> Not heavy Latex users like me might find unicode fonts much easier to
>> create their labels. Especially using units like #/cm^3.
>>
>> There are so many nice looking symbols in the DejaVu Sans samples at
>> http://dejavu.sf.net/samples/DejaVuSans.pdf
>> Is it possible in matplotlib to use those symbols as replacement for
>> regular markers while plotting? I recall someone was asking about using
>> Latex symbols as markers, but not sure about the fate of his question.
>>
>> Thanks
>>
>> On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <md...@st...<mailto:
>> md...@st...>> wrote:
>>
>> Thanks for the reminder. Sorry this fell through the cracks.
>>
>> The reason this worked for me and not for you is that I had set
>> (and later forgotten) font.sans-serif to the following:
>>
>> font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida
>> Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,
>> sans-serif
>>
>> DejaVu Sans is the successor to Vera Sans that includes much
>> larger Unicode coverage, including the Greek characters here.
>> Vera Sans (at least the version shipped with matplotlib) does not
>> include these characters.
>>
>> It's an open question whether we want to ship the larger DejaVu
>> fonts with matplotlib (and annoy the distro packagers even further
>> who already dislike some of matplotlib's redundancy). A less
>> disruptive change may be to change the rc defaults to put DejaVu
>> in front of Vera, even though we don't ship DejaVu. This will
>> help the majority of Linux users on modern distros (where DejaVu
>> is almost always installed by default, I suspect), and still have
>> our own Vera as a fallback (albeit with a more limited character
>> set). Especially since DejaVu and Vera are basically the same
>> font, and substituting one for the other would not change the
>> appearance of plots, I think this a reasonably safe thing to do --
>> but I'd appreciate feedback in case I haven't thought through all
>> the issues.
>>
>> Mike
>>
>> Gökhan Sever wrote:
>>
>>
>>
>> On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom
>> <md...@st... <mailto:md...@st...>
>> <mailto:md...@st... <mailto:md...@st...>>> wrote:
>>
>> On 01/28/2010 08:08 PM, Gökhan Sever wrote:
>>
>> #!/usr/bin/python
>> # -*- coding: utf-8 -*-
>>
>> from pylab import *
>>
>> plot([1]*5)
>> xlabel(u'μ = 50')
>> ylabel(u'σ = 1.5')
>>
>> show()
>>
>> It works for me. Can you provide a screenshot and the
>> output from
>> matplotlib with "verbose.level : debug-annoying" in your
>> matplotlibrc?
>>
>> Mike
>>
>>
>> Mike,
>>
>> Attached are the outputs. Which font do you activated in your
>> matplotlibrc? Currently non-active in mine.
>>
>>
>> -- Gökhan
>>
>> ------------------------------------------------------------------------
>>
>>
>> -- Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>
>>
>> --
>> Gökhan
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Gökhan
From: Ben A. <BAx...@co...> - 2010年02月26日 22:30:09
I also agree with Reinier. I want my 3d plots to look as close as possible to my 2d plots. Because mplot3d uses so much of the same matplotlib core, this is trivial. As Friedrich mentioned, the mplot3d code is actually pretty small. To me, that is a great feature. I found the mplot3d code very accessible.
I do agree that there is still much work to be done in mplot3d. But I think starting from scratch is a waste of time.
FYI, I looked into using mayavi2 before settling on mplot3d. Mayavi can create some stunning graphics, but I found that it is very restrictive in its plotting options. Take for example the 3d scatter plot. They combined the size and color parameter. Getting around this strange restriction took me quite some time. (Installation for me was also a pain due to VTK).
-Ben
-----Original Message-----
From: Jakub Nowacki [mailto:j.s...@go...] 
Sent: Friday, February 26, 2010 12:01 PM
To: matplotlib-users
Subject: Re: [Matplotlib-users] mplot3d stays?
Dear all,
I don't know if creating full blown 3d library makes much sense. I think Reinier is right here that the current mplot3d creates quite satisfactory outcome with matplotlib look-and-feel we all like. In general, there are 3d libraries/packages out there (VTK, Mayavi2 etc.), which do most of the stuff one would need. The problem is many times using is not that trivial. Also, the installation process is usually much more complex, eg. setting up mayavi2 on snow leopard took me several days. 
I asked the question in the first place because in many cases I need rather simple 3d plotting tool, without al the massive rendering capabilities etc. Since I use matplotlib anyway, it would be nice to use the same tool and not be forced to install and learn something new just to plot not very complicated surface. Hence, I think the main goal here should be to have a relatively simple but usable plotting tool with matplotlib look-an-feel. 
BTW I didn't know that my simple question would generate such a discussion. :)
Best wishes,
Jakub
------------------------------------------------------------------------------
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-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
From: jamgood96 <jam...@gm...> - 2010年02月26日 21:30:17
Each time I try to run a script, it just keeps printing, "The time is: The
time is: Fri Feb 26 13:27:08 2010". over and over. I believe I installed all
the packages correctly, but honesty was a bit overwhelmed. I've tried
attaching a screen shot of what is happening.
Thanks in advance!
http://old.nabble.com/file/p27723602/Screen%2Bshot%2B2010-02-26%2Bat%2B1.27.18%2BPM.jpeg 
-- 
View this message in context: http://old.nabble.com/The-time-is%3A-....-tp27723602p27723602.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
From: Michael D. <md...@st...> - 2010年02月26日 20:56:19
SVN trunk has support for mathtext as symbol markers --
 plot(range(10), linestyle='None', marker=r'$\clubsuit$')
We could support arbitrary (non-math) text, too, fairly easily. We just 
need to invent a syntax for it.
Mike
Gökhan Sever wrote:
> Thanks Mike. The Greek symbols become visible when I make the changes 
> as you suggested. DejaVu Sans has been installed in my system (Fedora 
> 12). We might put a note on the documentation stating to get wider 
> Unicode coverage people could install additional fonts --DejaVu Sans 
> being one of them instead of shipping the fonts with matplotlib.
>
> With my working unicode example, now I have three ways to show u^-2 on 
> labels. See the code at: 
> http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py
>
> Not heavy Latex users like me might find unicode fonts much easier to 
> create their labels. Especially using units like #/cm^3.
>
> There are so many nice looking symbols in the DejaVu Sans samples at 
> http://dejavu.sf.net/samples/DejaVuSans.pdf
> Is it possible in matplotlib to use those symbols as replacement for 
> regular markers while plotting? I recall someone was asking about 
> using Latex symbols as markers, but not sure about the fate of his 
> question.
>
> Thanks
>
> On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> Thanks for the reminder. Sorry this fell through the cracks.
>
> The reason this worked for me and not for you is that I had set
> (and later forgotten) font.sans-serif to the following:
>
> font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida
> Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde,
> sans-serif
>
> DejaVu Sans is the successor to Vera Sans that includes much
> larger Unicode coverage, including the Greek characters here.
> Vera Sans (at least the version shipped with matplotlib) does not
> include these characters.
>
> It's an open question whether we want to ship the larger DejaVu
> fonts with matplotlib (and annoy the distro packagers even further
> who already dislike some of matplotlib's redundancy). A less
> disruptive change may be to change the rc defaults to put DejaVu
> in front of Vera, even though we don't ship DejaVu. This will
> help the majority of Linux users on modern distros (where DejaVu
> is almost always installed by default, I suspect), and still have
> our own Vera as a fallback (albeit with a more limited character
> set). Especially since DejaVu and Vera are basically the same
> font, and substituting one for the other would not change the
> appearance of plots, I think this a reasonably safe thing to do --
> but I'd appreciate feedback in case I haven't thought through all
> the issues.
>
> Mike
>
> Gökhan Sever wrote:
>
>
>
> On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom
> <md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>> wrote:
>
> On 01/28/2010 08:08 PM, Gökhan Sever wrote:
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
>
> from pylab import *
>
> plot([1]*5)
> xlabel(u'μ = 50')
> ylabel(u'σ = 1.5')
>
> show()
>
> It works for me. Can you provide a screenshot and the
> output from
> matplotlib with "verbose.level : debug-annoying" in your
> matplotlibrc?
>
> Mike
>
>
> Mike,
>
> Attached are the outputs. Which font do you activated in your
> matplotlibrc? Currently non-active in mine.
>
>
> -- 
> Gökhan
> ------------------------------------------------------------------------
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
>
> -- 
> Gökhan
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
From: Gökhan S. <gok...@gm...> - 2010年02月26日 18:31:35
Thanks Mike. The Greek symbols become visible when I make the changes as you
suggested. DejaVu Sans has been installed in my system (Fedora 12). We might
put a note on the documentation stating to get wider Unicode coverage people
could install additional fonts --DejaVu Sans being one of them instead of
shipping the fonts with matplotlib.
With my working unicode example, now I have three ways to show u^-2 on
labels. See the code at:
http://code.google.com/p/ccnworks/source/browse/trunk/various/threemus.py
Not heavy Latex users like me might find unicode fonts much easier to create
their labels. Especially using units like #/cm^3.
There are so many nice looking symbols in the DejaVu Sans samples at
http://dejavu.sf.net/samples/DejaVuSans.pdf
Is it possible in matplotlib to use those symbols as replacement for regular
markers while plotting? I recall someone was asking about using Latex
symbols as markers, but not sure about the fate of his question.
Thanks
On Fri, Feb 26, 2010 at 10:13 AM, Michael Droettboom <md...@st...>wrote:
> Thanks for the reminder. Sorry this fell through the cracks.
>
> The reason this worked for me and not for you is that I had set (and later
> forgotten) font.sans-serif to the following:
>
> font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida Grande,
> Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif
>
> DejaVu Sans is the successor to Vera Sans that includes much larger Unicode
> coverage, including the Greek characters here. Vera Sans (at least the
> version shipped with matplotlib) does not include these characters.
>
> It's an open question whether we want to ship the larger DejaVu fonts with
> matplotlib (and annoy the distro packagers even further who already dislike
> some of matplotlib's redundancy). A less disruptive change may be to change
> the rc defaults to put DejaVu in front of Vera, even though we don't ship
> DejaVu. This will help the majority of Linux users on modern distros (where
> DejaVu is almost always installed by default, I suspect), and still have our
> own Vera as a fallback (albeit with a more limited character set).
> Especially since DejaVu and Vera are basically the same font, and
> substituting one for the other would not change the appearance of plots, I
> think this a reasonably safe thing to do -- but I'd appreciate feedback in
> case I haven't thought through all the issues.
>
> Mike
>
> Gökhan Sever wrote:
>
>>
>>
>> On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom <md...@st...<mailto:
>> md...@st...>> wrote:
>>
>> On 01/28/2010 08:08 PM, Gökhan Sever wrote:
>>
>> #!/usr/bin/python
>> # -*- coding: utf-8 -*-
>>
>> from pylab import *
>>
>> plot([1]*5)
>> xlabel(u'μ = 50')
>> ylabel(u'σ = 1.5')
>>
>> show()
>>
>> It works for me. Can you provide a screenshot and the output from
>> matplotlib with "verbose.level : debug-annoying" in your matplotlibrc?
>>
>> Mike
>>
>>
>> Mike,
>>
>> Attached are the outputs. Which font do you activated in your
>> matplotlibrc? Currently non-active in mine.
>>
>>
>> --
>> Gökhan
>> ------------------------------------------------------------------------
>>
>>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
Gökhan
From: Wai Y. T. <tun...@ya...> - 2010年02月26日 17:14:35
I managed to generated the chart I want by twisting the hist() function. I 
chart and source code can be found here:
http://tungwaiyip.info/blog/2010/02/26/visualization_using_variable_width_bar_chart
If you have any comment on my method it will be greatly appriciated.
Wai Yip
> I want to plat a column graph with variable width. The size of both axis
> have meaning. The Y-axis is the density. The X-axis is the size. Let's 
> say
> it is a graph of world population by country. Say China has 1 billion
> people occupying an area of 10000 km2. And Japan has 0.1 billion people
> occupying an area 500 km2. So their density is 1 billion / 10000 and 0.1
> billion / 500 respectively. The chart should show Japan's column twice as
> high as China but much narrower. And the area of each column reflects the
> population.
>
> My question is how do I plot a column graph with variable width? The
> closest I can find is in the histogram in the second example below
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/histogram_demo_extended.html
>
> I'm quite new to matplotlib. Thanks for your help.
>
> Wai Yip
>
>
> ------------------------------------------------------------------------------
> 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
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Jakub N. <j.s...@go...> - 2010年02月26日 17:01:08
Dear all,
I don't know if creating full blown 3d library makes much sense. I think Reinier is right here that the current mplot3d creates quite satisfactory outcome with matplotlib look-and-feel we all like. In general, there are 3d libraries/packages out there (VTK, Mayavi2 etc.), which do most of the stuff one would need. The problem is many times using is not that trivial. Also, the installation process is usually much more complex, eg. setting up mayavi2 on snow leopard took me several days. 
I asked the question in the first place because in many cases I need rather simple 3d plotting tool, without al the massive rendering capabilities etc. Since I use matplotlib anyway, it would be nice to use the same tool and not be forced to install and learn something new just to plot not very complicated surface. Hence, I think the main goal here should be to have a relatively simple but usable plotting tool with matplotlib look-an-feel. 
BTW I didn't know that my simple question would generate such a discussion. :)
Best wishes,
Jakub
From: John H. <jd...@gm...> - 2010年02月26日 16:45:27
On Fri, Feb 26, 2010 at 9:47 AM, mikey <abc...@go...> wrote:
> Hi there,
>
> Just wondering if anyone knows how to do a pixel offset in matplotlib?
>
> I've tried running the example in
> http://www.scipy.org/Cookbook/Matplotlib/Transformations#line-58 but
There is an "official" transformations tutorial now in the mpl docs
which is updated to the current API
http://matplotlib.sourceforge.net/users/transforms_tutorial.html
JDH
From: Michael D. <md...@st...> - 2010年02月26日 16:26:42
offset_copy is still available, but unfortunately doesn't work with the 
cookbook example because of a bug that was inadvertently introduced into 
matplotlib.
The bug is that offset_copy should have been defined as:
 def offset_copy(trans, fig=None, x=0.0, y=0.0, units='inches'):
instead of:
 def offset_copy(trans, fig, x=0.0, y=0.0, units='inches'):
That is, the "fig" argument was originally optional, and in July 2008 I 
accidentally was made it "required".
This will be fixed in the next release of matplotlib -- in the meantime 
the workaround to get the Cookbook recipe to work is to call offset_copy 
like this:
 return offset_copy(ax.transData, None, x=x, y=y, units='dots')
If that change doesn't fix the recipe for you, please send a full 
traceback of the error so we can diagnose the problem. (FWIW -- I don't 
have edit privileges for the cookbook page, or I would go in and fix 
this...)
Cheers,
Mike
mikey wrote:
> Hi there,
>
> Just wondering if anyone knows how to do a pixel offset in matplotlib?
>
> I've tried running the example in
> http://www.scipy.org/Cookbook/Matplotlib/Transformations#line-58 but
> it appears to have been trashed by changes to the api. The functions
> in the no-offset_copy function version don't exist any more and their
> replacements don't work the same way, and the offset_copy function is
> not available. (At least I am assuming it is because of updates rather
> then my copy of Matplotlib being out of date: 0.99.1.1) This is a very
> useful function if you're doing discrete data plots like I am and you
> want uniform clusters of points.
>
> Thanks for your time.
>
> Regards,
>
>
> Mikey
>
> ------------------------------------------------------------------------------
> 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-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: Michael D. <md...@st...> - 2010年02月26日 16:13:53
Thanks for the reminder. Sorry this fell through the cracks.
The reason this worked for me and not for you is that I had set (and 
later forgotten) font.sans-serif to the following:
 font.sans-serif : DejaVu Sans, Bitstream Vera Sans, Lucida 
Grande, Verdana, Geneva, Lucid, Arial, Helvetica, Avant Garde, sans-serif
DejaVu Sans is the successor to Vera Sans that includes much larger 
Unicode coverage, including the Greek characters here. Vera Sans (at 
least the version shipped with matplotlib) does not include these 
characters.
It's an open question whether we want to ship the larger DejaVu fonts 
with matplotlib (and annoy the distro packagers even further who already 
dislike some of matplotlib's redundancy). A less disruptive change may 
be to change the rc defaults to put DejaVu in front of Vera, even though 
we don't ship DejaVu. This will help the majority of Linux users on 
modern distros (where DejaVu is almost always installed by default, I 
suspect), and still have our own Vera as a fallback (albeit with a more 
limited character set). Especially since DejaVu and Vera are basically 
the same font, and substituting one for the other would not change the 
appearance of plots, I think this a reasonably safe thing to do -- but 
I'd appreciate feedback in case I haven't thought through all the issues.
Mike
Gökhan Sever wrote:
>
>
> On Fri, Jan 29, 2010 at 7:43 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> On 01/28/2010 08:08 PM, Gökhan Sever wrote:
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
>
> from pylab import *
>
> plot([1]*5)
> xlabel(u'μ = 50')
> ylabel(u'σ = 1.5')
>
> show()
>
> It works for me. Can you provide a screenshot and the output from
> matplotlib with "verbose.level : debug-annoying" in your matplotlibrc?
>
> Mike
>
>
> Mike,
>
> Attached are the outputs. Which font do you activated in your 
> matplotlibrc? Currently non-active in mine.
>
>
> -- 
> Gökhan
> ------------------------------------------------------------------------
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
From: mikey <abc...@go...> - 2010年02月26日 15:47:47
Hi there,
Just wondering if anyone knows how to do a pixel offset in matplotlib?
I've tried running the example in
http://www.scipy.org/Cookbook/Matplotlib/Transformations#line-58 but
it appears to have been trashed by changes to the api. The functions
in the no-offset_copy function version don't exist any more and their
replacements don't work the same way, and the offset_copy function is
not available. (At least I am assuming it is because of updates rather
then my copy of Matplotlib being out of date: 0.99.1.1) This is a very
useful function if you're doing discrete data plots like I am and you
want uniform clusters of points.
Thanks for your time.
Regards,
Mikey
From: Michael D. <md...@st...> - 2010年02月26日 15:45:09
LB wrote:
> Hi,
>
> I would like to make a local install of matplotlib under Linux, but 
> I've got 2 problems :
>
> 1) I didn't find how to setup the build to use the PGI C compiler.
> I tried python setup buil --help-compiler but there seems to be no 
> preconfigured options for this compiler, and the default doesn't work 
> (see log2, below)
> How should I configure this ?
Python's distutils doesn't include support for the PGI compiler. Does 
PGI offer a gcc commandline compatibility mode (like icc does?). If 
not, you may need to look into providing a custom compiler class for PGI 
-- the distutils mailing list may be able to help you more than this one.
>
> 2) I have a problem with the configuration of gtk dependencies.
> Theses dependencies are also locally installed and the setup.py script 
> didn't find them (see log1 below)
> But, the strange thing is that, if I modify the setup.py script and 
> add "import gtk" on the top of it, the configuration seems to run 
> nicely (see log2).
> Indded, it seems that "import gtk" works in setup.py but doesn't in 
> setupext.py, which is very weird to me
>
> Have you got any ideas on how to solve this ?
That indeed is strange. Are you doing anything special with your 
PYTHONPATH environment variable, using virtualenv (or similar) that 
might have an impact on your Python environment during compilation?
Mike
>
> [ log1 ]
> > python setup.py build
> ============================================================================
> BUILDING MATPLOTLIB
> matplotlib: 0.98.0
> python: 2.5.2 |EPD Py25 4.1.30101| (r252:60911, Dec 19 
> 2008,
> 17:15:55) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
> platform: linux2
>
> REQUIRED DEPENDENCIES
> numpy: 1.1.1
> freetype2: 9.10.3
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: 1.2.10
> Tkinter: no
> * Using default library and include 
> directories for
> * Tcl and Tk because a Tk window failed to open.
> * You may need to define DISPLAY for Tk to work so
> * that setup can determine where your 
> libraries are
> * located. Tkinter present, but header files 
> are not
> * found. You may need to install development
> * packages.
> wxPython: 2.8.7.1
> * WxAgg extension not required for wxPython >= 2.8
> Gtk+: no
> * Building for Gtk+ requires pygtk; you must 
> be able
> * to "import gtk" in your build/install 
> environment
> Qt: no
> Qt4: no
> Cairo: no
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> datetime: present, version unknown
> dateutil: 1.4
> pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
> dvipng: 1.5
> ghostscript: 8.15.2
> latex: 3.141592
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
> configobj: 4.5.3
> enthought.traits: 3.0.3
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> [/log1]
>
>
>
> [log2]
> > python setup.py build
> ============================================================================
> BUILDING MATPLOTLIB
> matplotlib: 0.98.0
> python: 2.5.2 |EPD Py25 4.1.30101| (r252:60911, Dec 19 
> 2008,
> 17:15:55) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
> platform: linux2
>
> REQUIRED DEPENDENCIES
> numpy: 1.1.1
> freetype2: 9.10.3
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: 1.2.10
> Tkinter: no
> * Using default library and include 
> directories for
> * Tcl and Tk because a Tk window failed to open.
> * You may need to define DISPLAY for Tk to work so
> * that setup can determine where your 
> libraries are
> * located. Tkinter present, but header files 
> are not
> * found. You may need to install development
> * packages.
> wxPython: 2.8.7.1
> * WxAgg extension not required for wxPython >= 2.8
> Gtk+: gtk+: 2.10.14, glib: 2.22.4, pygtk: 2.10.6,
> pygobject: 2.12.3
> Qt: no
> Qt4: no
> Cairo: 1.4.0
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
> datetime: present, version unknown
> dateutil: 1.4
> pytz: 2008c
>
> OPTIONAL USETEX DEPENDENCIES
> dvipng: 1.5
> ghostscript: 8.15.2
> latex: 3.141592
>
> EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
> configobj: 4.5.3
> enthought.traits: 3.0.3
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> running build
> running build_py
> copying lib/matplotlib/mpl-data/matplotlibrc -> 
> build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> copying lib/matplotlib/mpl-data/matplotlib.conf -> 
> build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> running build_ext
> building 'matplotlib.ft2font' extension
> pgcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall 
> -Wstrict-prototypes -fPIC -I/usr/include/freetype2 
> -I/usr/local/include -I/usr/include -I. 
> -I/OutilsGroupe/EPD/include/python2.5 -c src/ft2font.cpp -o 
> build/temp.linux-x86_64-2.5/src/ft2font.o
> pgcc-Error-Unknown switch: -fno-strict-aliasing
> pgcc-Error-Unknown switch: -fwrapv
> pgcc-Error-Unknown switch: -Wall
> pgcc-Error-Unknown switch: -Wstrict-prototypes
> error: command 'pgcc' failed with exit status 1
> [/log2]
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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-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: Alan G I. <ala...@gm...> - 2010年02月26日 15:08:31
On 2/26/2010 3:04 AM, Friedrich Romstedt wrote:
> I need a physical rendering engine with light
> sources and reflectance/transmittance simulation
http://en.wikipedia.org/wiki/POV-Ray ?
Alan Isaac
From: Reinier H. <re...@he...> - 2010年02月26日 14:40:02
Dear all,
One of the great advantages of the current mplot3d design is that it
produces complete vector based graphics with the same look-and-feel as
your 2d plots. Integration with OpenGL will certainly change this, as
the rendering will always give you (as far as I know) a bitmap. I
think this is what matlab does, and I consider it a major weakness. I
therefore believe that the mplot3d approach is good for what it is
designed for (which means not being a complete 3d rendering engine).
The drawback, of course, is that you have to do more 3d stuff
yourself. There are some good reasons why some problems are *very*
hard to solve, but others are doable, such as z-ordering all the
polygons (and perhaps splitting them if that's required). Gouraud
shading is something else that should be possible. Getting dashed 3d
lines z-sorted in a good-looking way sounds very hard to me, but for
solid lines it should be ok.
As a comment to a previous post, by Gael if I'm not mistaken: mplot3d
internally has all info in 3d. In the end you have to go 2d somewhere,
and I personally think that we do this at the correct level.
Let me mention some more areas of improvement. Currently the Axis3D
code does some magic to draw the axes lines and ticks in the correct
location. It would be better to rewrite this class to use actual
Line3D instances to reduce duplicate code.
This brings me to my last remark, which is about the fact that Axes3D
currently inherits from Axes. The reason why this was is of course to
reduce code duplication. However, I can see why this can be very
confusing to the user since it is indeed not clear what is and what is
not supposed to work. I need to think a bit about the solution; indeed
it might be better to not inherit from Axes. But do not call that all
too soon, since Axes is still doing some work under the hood. On the
other hand, many of the functions probably don't really make sense.
I think restarting from scratch is almost never a good plan...
Cheers,
Reinier
PS: John, I would be interested in mentoring a gsoc student.
On Thu, Feb 25, 2010 at 7:26 PM, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
> [...]
>>
>> It looks like we have enough 3D projects to justify a google summer of
>> code student. Would those of you with an interest in mplot3d and some
>> knowledge of the internals be interested in helping mentor a student?
>>
>
> http://www.mail-archive.com/mat...@li.../msg01343.html
>
> Is it time for some re-thinking of the approach to 3-D? I am a
> bystander, but I have the uneasy sense that trying to turn mplot3d into
> a first-class 3-D plotting tool may be a misapplication of effort.
> Might the effort be more productive if applied to mayavi, or built on
> mayavi, so that the 3-D engine is already taken care of?
>
> Eric
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Reinier Heeres
Tel: +31 6 10852639
From: LB <bra...@gm...> - 2010年02月26日 14:02:44
Hi,
I would like to make a local install of matplotlib under Linux, but I've got
2 problems :
1) I didn't find how to setup the build to use the PGI C compiler.
I tried python setup buil --help-compiler but there seems to be no
preconfigured options for this compiler, and the default doesn't work (see
log2, below)
How should I configure this ?
2) I have a problem with the configuration of gtk dependencies.
Theses dependencies are also locally installed and the setup.py script
didn't find them (see log1 below)
But, the strange thing is that, if I modify the setup.py script and add
"import gtk" on the top of it, the configuration seems to run nicely (see
log2).
Indded, it seems that "import gtk" works in setup.py but doesn't in
setupext.py, which is very weird to me
Have you got any ideas on how to solve this ?
[ log1 ]
> python setup.py build
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.0
 python: 2.5.2 |EPD Py25 4.1.30101| (r252:60911, Dec 19 2008,
 17:15:55) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.1
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.10
 Tkinter: no
 * Using default library and include directories for
 * Tcl and Tk because a Tk window failed to open.
 * You may need to define DISPLAY for Tk to work so
 * that setup can determine where your libraries are
 * located. Tkinter present, but header files are not
 * found. You may need to install development
 * packages.
 wxPython: 2.8.7.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Qt: no
 Qt4: no
 Cairo: no
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: 1.4
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: 1.5
 ghostscript: 8.15.2
 latex: 3.141592
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.5.3
 enthought.traits: 3.0.3
[Edit setup.cfg to suppress the above messages]
============================================================================
[/log1]
[log2]
> python setup.py build
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.0
 python: 2.5.2 |EPD Py25 4.1.30101| (r252:60911, Dec 19 2008,
 17:15:55) [GCC 4.1.2 20071124 (Red Hat 4.1.2-42)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.1
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.10
 Tkinter: no
 * Using default library and include directories for
 * Tcl and Tk because a Tk window failed to open.
 * You may need to define DISPLAY for Tk to work so
 * that setup can determine where your libraries are
 * located. Tkinter present, but header files are not
 * found. You may need to install development
 * packages.
 wxPython: 2.8.7.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: gtk+: 2.10.14, glib: 2.22.4, pygtk: 2.10.6,
 pygobject: 2.12.3
 Qt: no
 Qt4: no
 Cairo: 1.4.0
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: 1.4
 pytz: 2008c
OPTIONAL USETEX DEPENDENCIES
 dvipng: 1.5
 ghostscript: 8.15.2
 latex: 3.141592
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.5.3
 enthought.traits: 3.0.3
[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc ->
build/lib.linux-x86_64-2.5/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf ->
build/lib.linux-x86_64-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib.ft2font' extension
pgcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-fPIC -I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
-I/OutilsGroupe/EPD/include/python2.5 -c src/ft2font.cpp -o
build/temp.linux-x86_64-2.5/src/ft2font.o
pgcc-Error-Unknown switch: -fno-strict-aliasing
pgcc-Error-Unknown switch: -fwrapv
pgcc-Error-Unknown switch: -Wall
pgcc-Error-Unknown switch: -Wstrict-prototypes
error: command 'pgcc' failed with exit status 1
[/log2]
From: Freddie W. <fr...@wi...> - 2010年02月26日 10:34:56
Hi all,
While playing around with the TeX support in matplotlib (rc('text', 
usetex=True)) and the PDF backend I noticed an interesting phenomena whereby 
the summation symbol in my plot was rendered at a larger size than regular TeX 
would produce.
Taking the following example as my basis 
http://matplotlib.sourceforge.net/examples/pylab_examples/tex_demo.html I 
created a PDF and compared it, in Evince to a PDF with an equivalent math 
section created by LaTeX.
Overlaying the two PDFs results in the following: 
http://freddie.witherden.org/drop/matplotlibtex.png The bottom is the output 
from matplotlib while the top LaTeX. For some reason the summation symbol is 
larger in matplotlib than in LaTeX.
I have seemingly confirmed this with latex + dvipdfm and pdflatex.
Does anyone know what might be causing this? The document font sizes are the 
same and I tried to match the LaTeX file as closely as possible to the one used 
internally by matplotlib.
Polemically yours, Freddie.
From: Friedrich R. <fri...@gm...> - 2010年02月26日 08:04:57
2010年2月26日 Gael Varoquaux <gae...@no...>:
> What Eric was most probably talking about is the newer versions of
> Mayavi, that we tend to call 'mayavi2', even though we are now up to
> version 3, in particular the mlab interface:
>
> http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/mlab.html
>
> which is demoed in the examples:
> http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/examples.html
>
> I believe that Mayavi does take care of the task you are interested in.
> It has its limitation and annoyances, but a lot of people use it quite
> efficiently to do 3D plotting, for simple problems to very complex ones.
Wow, that's really impressive! I admit that adding 3D plotting
capability to matplotlib would be like reinventing the wheel, and it
would be a quite rectangular-shaped wheel.
But, unfortunately, I need a physical rendering engine with light
sources and reflectance/transmittance simulation from real measured
data anyway, and the 3D rendering engine will be a byproduct. But, I
think, it would be more easy to use Agg directly as the backend rather
than going via matplotlib, although it may be an option.
Friedrich
From: Friedrich R. <fri...@gm...> - 2010年02月26日 07:28:16
2010年2月26日 Andrew Charles <ac...@gm...>:
> Aye, now that I read the docstring with a rested pair of eyes it's
> clear that xout and yout are meshgrids (rank 2 arrays). Thanks,
> problem solved.
For convenience, I recently heard about numpy.meshgrid, which does the
job for you. See its __doc__, but it's fairly easy: numpy.meshgrid(x,
y).
Friedrich
37 messages has been excluded from this view by a project administrator.

Showing results of 620

<< < 1 2 3 4 .. 25 > >> (Page 2 of 25)
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /