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
(8) |
3
(2) |
4
(7) |
5
(17) |
6
(20) |
7
(17) |
8
(18) |
9
(7) |
10
(4) |
11
(9) |
12
(20) |
13
(20) |
14
(17) |
15
(8) |
16
(2) |
17
(4) |
18
(4) |
19
(13) |
20
(4) |
21
(16) |
22
(9) |
23
(1) |
24
(5) |
25
(8) |
26
(13) |
27
(25) |
28
(25) |
29
(14) |
30
(10) |
31
(1) |
|
|
|
|
|
|
>>>>> "Bob" == Bob Ippolito <bo...@re...> writes: Bob> On Jun 17, 2005, at 4:09 PM, John Hunter wrote: >>>>>>> "Chris" == Chris Barker <Chr...@no...> writes: >>>>>>> >> >>> Using data_files in this manner at all is usually the wrong >>> thing to do anyway. Python packages should really put the >>> files they need into the package, not some semi-random >>> location on the filesystem. >>> >> Chris> I tend to trust Bob in these matters. What is the logic for Chris> putting all that stuff outside of the package directory? >> I was just following the lead of the distutils documentation >> circa 2003 which is when this section of setup.py written. >> Since distutils had a slot for data_files, I put my data files >> there, which seems reasonable even in hindsight. I'm not >> opposed to putting them somewhere else, especially if someone >> explains the why and how. I do try and preserve compatibility >> with older python versions, so 2.4 only solutions are not a >> good choice at the moment. Bob> Python 2.4 distutils has the functionality built-in, Bob> otherwise you can get it from setuptools (in the Python CVS Bob> sandbox, or from Bob> <http://peak.telecommunity.com/DevCenter/PythonEggs>). There Bob> have been various other hacks throughout the years to do it, Bob> but setuptools is the standard now. Bob> py2app uses setuptools when building itself, and it is Bob> certainly Python 2.3 compatible. Hi Bob, Sorry for the delay getting back on this. I am starting to look at setuptools and have read over (quickly) http://peak.telecommunity.com/DevCenter/PythonEggs A couple of questions: * Are you recommending using the full PythonEggs suite, or just the parts in the default setuptools that comes with python2.4 ? I notice for example, that pkg_resources is not available in Python 2.4.1 setuptools. This is not a huge problem, since it is fairly easy to install/upgrade. Just wondering. * It is not clear to me what the "right" way is to distribute/install data files (eg fonts). You suggest above that the data_files directive is not the right way and that the data files should be placed in the package. I naively tried package_data with from setuptools import setup setup(name="matplotlib", ...snip... package_data = { 'matplotlib.fonts' : glob.glob('fonts/afm/*.afm'), }, package_dir = {'': 'lib'}, ) where fonts/afm in the relative path has a bunch of *.afm fonts, but no files were added to site-packages/matplotlib/fonts/ when I did a 'sudo python setup.py install'. I read over the py2app setup at http://svn.red-bean.com/bob/py2app/trunk/setup.py but still was unsure how to proceed. The PythonEgg resource documentation spends a fair amount of space on how to "access" resources, but I missed how to specify them for the distribution (http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources) So that is a long-winded way of asking "how should data files be placed in the package for distribution?" Thanks, JDH
>>>>> "Torsten" =3D=3D Torsten Bronger <br...@ph...> wr= ites: Torsten> Hall=F6chen! John Hunter <jdh...@ac...> Torsten> writes: >>>>>>> "Torsten" =3D=3D Torsten Bronger >>>>>>> <br...@ph...> writes: >> Torsten> 2. The above loop is the last part of my program. The Torsten> program terminates with >> Torsten> Fatal Python error: PyEval_RestoreThread: NULL tstate >> Torsten> Apparently, this is done by my improper handling of Torsten> matplotlib. What's going wrong? >> This is an annoyance we haven't been able to get rid of in all >> use cases. animation using pylab and tkagg is one of the >> places. I assume you are using the tkagg backend? Torsten> Yes. >> If you search the mailing list archives for >> PyEval_RestoreThread, you'll see this in many contexts. For >> any semi-serious animation work, I suggest you not use the >> matplotlib/interactive mode shown in anim.py but rather use >> your GUI's idle handling or timer mechanism as in >> examples/anim_tk.py or examples/dyamic_image_gtkagg.py. Torsten> Thanks, I'll do. >> [...] >>=20 Torsten> 3. How can I achieve that dynamic autoscaling of the Torsten> y-axis? As noted in the source, "gcf().autoscale_view" Torsten> has no effect. >> This is not legal matplotlib code -- I assume you mean >> gca().autoscale_view(). Torsten> Yes, sorry. >> In the absence of more information it is hard top diagnose what >> the problem is. Torsten> Here is a complete example: OK, that helps. The update of the data limits happens when you call plot and friends (technically plot calls ax.add_line which calls ax.update_datalim_numerix) . If you manually set the xdata or ydata on the line object, you need to manually update the Axes datalim with ax =3D gca() for i in range(2*cycles): voltages =3D number_of_values * [i % 2 + 3] y_values[i * number_of_values : (i+1) * number_of_values] =3D \ voltages line.set_ydata(y_values) ax.update_datalim_numerix(x_values, y_values) ax.autoscale_view() draw() time.sleep(1) JDH
Hi, I am putting together a system model that uses wxpython sliders and buttons for controls. I would like to use notebook tabs/windows for different sections and have one notebook window for plotting. I have hunted through the matplotlib examples but have not found any that use something other than a wxFrame. I apologize for not digging deep to solve the problem, but if someone had an example or an explanation of what is necessary, I would greatly appreciate it. Thanks, Pat ODonnell
On Sat, 2005年07月02日 at 09:59 -0500, John Hunter wrote: [...] > Also, we have to balance inconvenience of package developers with > inconvenience of users. Given a choice, I tend to inconvenience the > power users, because they are more able and willing to deal with it. Its not just a tradeoff between package developers and users because if you make things easy for package developers you also make things easier for users (who use those packages) since they are now able to install from the package instead of using cvs or a tar or zip file. > That said, I think there is a compromise solution which may satisfy > everyone. Following Chris Barker's suggestion, we can create a zip > file or tarball of matplotlib deps, which has the src of all of the > prereqs (except python and numerix) in it, and rewrite the setup to > have a proper configure, checking for each prereq and issuing a kind > error like "you are missing the freetype prereq, please install it or > download http://someserver.com/mpldeps.zip and unzip it in this dir. > This would keep the matplotlib distro (and CVS updates) as light as > possible while making it easier to compile mpl on OSX and some linux > distros. Of course, to do this right requires a fair amount of > effort, but I am all for it. I worked for a while trying to use the > distutils configure functionality (which can test for include headers, > libs and the like) but was unsuccessful. The question that stumped me > was how to properly communicate the results of the config process to > the build process. I posted this to c.l.python but got no answer: > http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/97cbe06f5efa58c0/18a015cba8bf2bd0?q=author:jdh...@ac...+group:comp.lang.python+distutils&rnum=1&hl=en#18a015cba8bf2bd0 A light cvs with a zipfile of dependencies seems like a good idea. Maybe there was no response to the distutils question because nobody knows how to do it, or because distutils is not powerful enough to support it very well. Or just because nobody else writes Python packages with as many dependencies as matplotlib! The Python source code (and PyGTK) use gnu autotools (autoconf, automake, etc) to configure and install themselves. Its more powerful than distutils and is used by many C projects, but can be used for Python too. Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Steve Chaplin wrote: > On Fri, 2005年07月01日 at 20:28 -0700, > mat...@li... wrote: > >>Eric Emsellem wrote: >> >>>Hi, >>>a short report on 2 minor problems I face with matplotlib: >>> >>>- I tried to save a figure in gif. It gave me back an error message >>>saying that basically this is not supported. This is fine of course. >>>However, then the plot window crashed, and then the whole Ipython >>>session. It would be useful then to have this error not affecting the >>>session in this way if possible. >> >>I can see the problem in the GTK backend, but all other backends I tried under >>linux (TkAgg, QtAgg and WXAgg) all behave correctly. This seems like a bug in >>the GTK backend to me: it puts out to the screen an error message box, but the >>OK button in that box is unresponsive. Eventually the window manager just >>kills the window, which brings the whole python process down with it. >> >>I don't know the backends enough to know what the right solution should be here. > > > I think this is an example where the IPython method of using threads to > interactively execute gtk commands does not work. > A minimal example that gives the same problem: > > $ ipython -gthread > In [1]: import gtk > In [2]: md=gtk.MessageDialog(buttons=gtk.BUTTONS_CLOSE, > message_format="message") > In [3]: md.run() > > gtk_dialog_run() blocks in a recursive main loop until the dialog either > emits the response signal, or is destroyed. > This gives the effect of a modal dialog. It works fine from within a GTK > program, but gives problems when used through IPython. Mmh, I just don't know enough about GTK to consider what the right approach should be. Is this something that ipython should handle differently? I'll gladly incorporate any fixes, if I knew what they need to be :) Cheers, f
On Fri, 2005年07月01日 at 20:28 -0700, mat...@li... wrote: > Eric Emsellem wrote: > > Hi, > > a short report on 2 minor problems I face with matplotlib: > > > > - I tried to save a figure in gif. It gave me back an error message > > saying that basically this is not supported. This is fine of course. > > However, then the plot window crashed, and then the whole Ipython > > session. It would be useful then to have this error not affecting the > > session in this way if possible. > > I can see the problem in the GTK backend, but all other backends I tried under > linux (TkAgg, QtAgg and WXAgg) all behave correctly. This seems like a bug in > the GTK backend to me: it puts out to the screen an error message box, but the > OK button in that box is unresponsive. Eventually the window manager just > kills the window, which brings the whole python process down with it. > > I don't know the backends enough to know what the right solution should be here. I think this is an example where the IPython method of using threads to interactively execute gtk commands does not work. A minimal example that gives the same problem: $ ipython -gthread In [1]: import gtk In [2]: md=gtk.MessageDialog(buttons=gtk.BUTTONS_CLOSE, message_format="message") In [3]: md.run() gtk_dialog_run() blocks in a recursive main loop until the dialog either emits the response signal, or is destroyed. This gives the effect of a modal dialog. It works fine from within a GTK program, but gives problems when used through IPython. Regards Steve Send instant messages to your online friends http://au.messenger.yahoo.com
Hallöchen! John Hunter <jdh...@ac...> writes: >>>>>> "Torsten" == Torsten Bronger <br...@ph...> writes: > > Torsten> 2. The above loop is the last part of my program. The > Torsten> program terminates with > > Torsten> Fatal Python error: PyEval_RestoreThread: NULL > Torsten> tstate > > Torsten> Apparently, this is done by my improper handling of > Torsten> matplotlib. What's going wrong? > > This is an annoyance we haven't been able to get rid of in all use > cases. animation using pylab and tkagg is one of the places. I > assume you are using the tkagg backend? Yes. > If you search the mailing list archives for PyEval_RestoreThread, > you'll see this in many contexts. For any semi-serious animation > work, I suggest you not use the matplotlib/interactive mode shown > in anim.py but rather use your GUI's idle handling or timer > mechanism as in examples/anim_tk.py or > examples/dyamic_image_gtkagg.py. Thanks, I'll do. > [...] > > Torsten> 3. How can I achieve that dynamic autoscaling of the > Torsten> y-axis? As noted in the source, "gcf().autoscale_view" > Torsten> has no effect. > > This is not legal matplotlib code -- I assume you mean > gca().autoscale_view(). Yes, sorry. > In the absence of more information it is hard top diagnose what > the problem is. Here is a complete example: #---------------------------------------------------------- from pylab import * import time ion() cycles = 10 number_of_values = 100 total_number_values = 2 * cycles * number_of_values x_values = arange(0, 2 * cycles, 1.0 / number_of_values) y_values = total_number_values * [0.0] line, = plot(x_values, y_values) for i in range(2*cycles): voltages = number_of_values * [i % 2 + 3] y_values[i * number_of_values : (i+1) * number_of_values] = \ voltages line.set_ydata(y_values) gca().autoscale_view() draw() time.sleep(1) #---------------------------------------------------------- Here, no autoscaling happens. Tschö, Torsten. -- Torsten Bronger, aquisgrana, europa vetus
===== Original message from John Hunter | 2005年7月05日: > This was just a suggestion of an interface that could be implemented, > not one that exists. The interface would be > axvline(x=0, noupdate=True) it is a good idea. what about (in this case) grid(x=[0], y=[0]) to control grid lines separate from xtic and ytic settings? > I agree -- could you add a feature request to the sourceforge site > with a description of the problem and a link to this thread? will do. :)
>>>>> "Torsten" == Torsten Bronger <br...@ph...> writes: Torsten> 2. The above loop is the last part of my program. The Torsten> program terminates with Torsten> Fatal Python error: PyEval_RestoreThread: NULL Torsten> tstate Torsten> Apparently, this is done by my improper handling of Torsten> matplotlib. What's going wrong? This is an annoyance we haven't been able to get rid of in all use cases. animation using pylab and tkagg is one of the places. I assume you are using the tkagg backend? If you search the mailing list archives for PyEval_RestoreThread, you'll see this in many contexts. For any semi-serious animation work, I suggest you not use the matplotlib/interactive mode shown in anim.py but rather use your GUI's idle handling or timer mechanism as in examples/anim_tk.py or examples/dyamic_image_gtkagg.py. Note that the gtkagg backend runs fine on windows and is the fastest for animation, though installing the GTK runtime and pygtk takes a bit more time. Torsten> 3. How can I achieve that dynamic autoscaling of the Torsten> y-axis? As noted in the source, "gcf().autoscale_view" Torsten> has no effect. This is not legal matplotlib code -- I assume you mean gca().autoscale_view(). In the absence of more information it is hard top diagnose what the problem is. gca().autoscale_view() followed by a draw command should rescale the axes to include all the data in x and y. If you want to have only the y axis autoscaled and not the x axis, I suggest writing a custom tick locator for the xaxis which returns fixed axis ranges and ticks, and use whatever ticker you want for the yaxis (eg the default). See examples/custom_ticker.py, http://matplotlib.sourceforge.net/matplotlib.ticker.html and Chapter 5 of the users guide. JDH
>>>>> "Christian" == Christian Meesters <mee...@un...> writes: Christian> Hi I'm trying to plot some error-bars in my GUI making Christian> use of the WXAgg-backend. My code looks like this: if Christian> parent.error_bar: Christian> a.errorbar(x.ichannel,x.intensity,x.intensity_error,ecolor='k') Christian> Now, I can plot the error bars in any arbitrary color, Christian> but the my actually black-on-white data are colored Christian> blue upon adding error-bars this way. What I want is Christian> that everything (data and their errors) is plotted Christian> black. Can anybody tell how to achieve this behavior? This is actually covered in the errorbar docstring, but subtly, so I'll elaborate here (and update the errorbar docs with this example) def errorbar(self, x, y, yerr=None, xerr=None, fmt='b-', ecolor=None, capsize=3, barsabove=False, **kwargs): """ ERRORBAR(x, y, yerr=None, xerr=None, fmt='b-', ecolor=None, capsize=3, barsabove=False) Plot x versus y with error deltas in yerr and xerr. Vertical errorbars are plotted if yerr is not None Horizontal errorbars are plotted if xerr is not None ....snip.....snip....snip ===> kwargs are passed on to the plot command for the markers So you can add additional key=value pairs to control the errorbar markers. For example, this code makes big red squares with thick green edges >>> x,y,yerr = rand(3,10) >>> errorbar(x, y, yerr, marker='s', mfc='red', mec='green', ms=20, mew=4) As you may know, mfc, mec, ms and mew are aliases for the longer property names, markerfacecolor, markeredgecolor, markersize and markeredgewith. For more information on which properties are settable (and their aliases), you can use the setp function >>> setp(Line2D) alpha: float antialiased or aa: [True | False] clip_box: a matplotlib.transform.Bbox instance clip_on: [True | False] color or c: any matplotlib color - see help(colors) dash_capstyle: ['butt' | 'round' | 'projecting'] dash_joinstyle: ['miter' | 'round' | 'bevel'] dashes: sequence of on/off ink in points data: (array xdata, array ydata) data_clipping: [True | False] figure: a matplotlib.figure.Figure instance label: any string linestyle or ls: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' ] linewidth or lw: float value in points lod: [True | False] marker: [ '+' | ',' | '.' | '1' | '2' | '3' | '4' | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd' | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|' ] markeredgecolor or mec: any matplotlib color - see help(colors) markeredgewidth or mew: float value in points markerfacecolor or mfc: any matplotlib color - see help(colors) markersize or ms: float solid_capstyle: ['butt' | 'round' | 'projecting'] solid_joinstyle: ['miter' | 'round' | 'bevel'] transform: a matplotlib.transform transformation instance visible: [True | False] xclip: (xmin, xmax) xdata: array yclip: (ymin, ymax) ydata: array zorder: any number In the API, setp is defined in matplotlib.artist and Line2D in matplotlib.lines. Cheers! JDH
>>>>> "Vidar" == Vidar Gundersen <vid...@37...> writes: Vidar> ===== Original message from John Hunter | 2005年7月04日: >> One could add a kwarg to the various plot commands like >> noupdate to suppress updating the datalim, Vidar> example? This was just a suggestion of an interface that could be implemented, not one that exists. The interface would be # do not update the data limits which control autoscaling axvline(x=0, noupdate=True) >> Basically, you would like to add string symbol markers to >> scatter, and have them colored with colormaps and support >> variable sizeing as well, right? Vidar> yes. i think it would be a useful addition to pylab. I agree -- could you add a feature request to the sourceforge site with a description of the problem and a link to this thread? Vidar> making the plot window smaller, each marker are constant in Vidar> size, taking up a larger area when reducing the plot area. Vidar> (this is not a big issue though.) I see. Yes there are times when you want the size of your markers to be in data coordinates rather than in physical coordinates. This can introduce other headaches, though. >> for gline in ax.get_xgridlines(): xmin, xmax = >> gline.get_xdata() # both should be the same >> gline.set_visible(xmin==0.0) # visible only at x==0 Vidar> it didn't work at all. i started out with ax = gca(), Vidar> started with grids turned on and off. There are two problems here. One is that you may need to control for floating point inaccuracies and so want to test for "close to" zero. This is trivial. The more subtle one has to do with how mpl manages ticks and gridlines. These are created dynamically as needed, often at draw time. So if interactive mode is off, the actual tick locations may not be updated until draw time, which is why the call to gline.set_visible(closeto(ymin,0.0)) # visible only at y==0 isn't behaving properly. I consider this to be a bug, but I'll have to think a little bit about the way to fix it. Feel free to file a bug report on the sf site to help remind me :-) In the meantime, here is a workaround which manipulates the interactive and draw state directly, as described at http://matplotlib.sourceforge.net/installing.html from pylab import arange, ion, draw, rand, figure, show # turn interactive mode on ion() fig = figure() ax = fig.add_subplot(111) ax.plot(rand(100)-0.5, rand(100)-0.5, 'go') ax.set_xlim((-0.5, 0.5)) ax.set_xticks(arange(-0.5, 0.51, 0.1)) ax.grid(True) def closeto(x, y, eps=1e-10): 'return true if x close to y with some tolerance eps' return abs(x-y)<eps # force a draw to create the ticks and gridlines draw() # now turn off all the grids except at zero for gline in ax.get_xgridlines(): xmin, xmax = gline.get_xdata() # both should be the same gline.set_visible(closeto(xmin,0.0)) # visible only at x==0 for gline in ax.get_ygridlines(): ymin, ymax = gline.get_ydata() # both should be the same gline.set_visible(closeto(ymin,0.0)) # visible only at y==0 draw() # force a redraw show()
===== Original message from John Hunter | 2005年7月04日: > One could add a kwarg to the various plot commands like > noupdate to suppress updating the datalim, example? > Basically, you would like to add string symbol markers to > scatter, and have them colored with colormaps and support > variable sizeing as well, right? yes. i think it would be a useful addition to pylab. Vidar: > what approach do you recommend for scaling the marker size > relative to axis ranges and figure size? John: > I'm not sure what you are after here. marker sizes are in points, so > you can pick the physical sizes you want. making the plot window smaller, each marker are constant in size, taking up a larger area when reducing the plot area. (this is not a big issue though.) > for gline in ax.get_xgridlines(): > xmin, xmax = gline.get_xdata() # both should be the same > gline.set_visible(xmin==0.0) # visible only at x==0 it didn't work at all. i started out with ax = gca(), started with grids turned on and off.
On Monday 04 July 2005 16:24, John Hunter wrote: > >>>>> "Jesper" == Jesper Larsen <jl...@dm...> writes: > >> 2) How do I make a CheckButtons class with only one button? The > >> example below fails with a "TypeError: unsubscriptable object". > > Jesper> I still don't know the answer to this problem. > > This was fixed in revision 1.15 of widgets.py in CVS, available at > > > http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/ >widgets.py?rev=1.15&view=log > > You should be able to just drop the updated file in > site-packages/matplotlib. Thanks John, I works fine now but I think you need to switch lines 269 and 270 in widgets.py (and maybe 272 and 273 for aestetic reasons). dy is referenced before it is used when you have more than one check button. Cheers, Jesper
Hi I'm trying to plot some error-bars in my GUI making use of the WXAgg-backend. My code looks like this: if parent.error_bar: a.errorbar(x.ichannel,x.intensity,x.intensity_error,ecolor='k') Now, I can plot the error bars in any arbitrary color, but the my actually black-on-white data are colored blue upon adding error-bars this way. What I want is that everything (data and their errors) is plotted black. Can anybody tell how to achieve this behavior? TIA Christian
Torsten, > > I visualize experimental data in quasi-realtime while it's acquired. > The x-axis is fixed right from the beginning. However, the y-axis > must be autoscaled depending on the data that's coming in. > > So far, I do the following on Windows: > > #-------------------------------------------------- > ion() > > NaN = 0.0 > > x_values = arange(0, 2 * zyklen, 1.0 / number_of_values) > y_values = total_number_of_values * [NaN] > line, = plot(x_values, y_values) ..... > > I have three questions: > > 1. On Linux, I can say NaN=float("NaN"), which suppresses plot > points in an area where no plot exists so far. On Windows, I seem > to be forced to set the un-measures interval to "0". This is > uglier, is there a better way? This looks to me like a place where you should try using masked arrays instead of NaN. NaN is not uniformly supported in Python and numerix, but masked arrays, in both numarray and Numeric, can accomplish the same thing and more. See masked_demo.py in the mpl examples subdirectory, and see http://stsdas.stsci.edu/numarray/numarray-1.3.html/module-numarray.ma.html for an explanation of masked arrays. Eric
Hi Tim, On Monday 04 July 2005 10:26 pm, Tim Leslie wrote: > Hi all, > > Currently when plotting data with large numbers, the scale on each axis is > done in scientific notation, so for example you might get ticks of 1, 2, 3 > then a x10^5 to indicate that it's actually 100000, 200000, 300000. > > While this is a rather nice feature, I find it quite difficult to wrap my > head around numbers which aren't of the form x10^(3n). Is there some way > to change the default behaviour so that in the example above it would give > 100, 200, 300 x10^3, etc? I think your suggestion is a good one. Try replacing ticker.ScalarFormatter._set_orderOfMagnitude with this: def _set_orderOfMagnitude(self,range): # if scientific notation is to be used, find the appropriate exponent # if using a numerical offset, find the exponent after applying the offset locs = absolute(self.locs) if self.offset: self.orderOfMagnitude = math.floor(math.log10(range)/3)*3 else: if locs[0] > locs[-1]: val = locs[0] else: val = locs[-1] if val == 0: oom = 0 else: self.orderOfMagnitude = math.floor(math.log10(val)/3)*3 I'm deep in the process of writing my thesis, and won't have time to test it. Would you? Darren
Hi all, Currently when plotting data with large numbers, the scale on each axis is done in scientific notation, so for example you might get ticks of 1, 2, 3 then a x10^5 to indicate that it's actually 100000, 200000, 300000. While this is a rather nice feature, I find it quite difficult to wrap my head around numbers which aren't of the form x10^(3n). Is there some way to change the default behaviour so that in the example above it would give 100, 200, 300 x10^3, etc? Cheers, Tim Leslie