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
(4) |
2
(13) |
3
(4) |
4
(6) |
5
(6) |
6
|
|
7
|
8
(6) |
9
(2) |
10
(2) |
11
(3) |
12
(3) |
13
(2) |
|
14
(2) |
15
(2) |
16
(6) |
17
(8) |
18
(10) |
19
(17) |
20
(8) |
|
21
(4) |
22
(10) |
23
(7) |
24
(7) |
25
(8) |
26
(11) |
27
(5) |
|
28
|
29
(5) |
30
|
31
(4) |
|
|
|
|
From: Alan I. <ai...@am...> - 2006-05-31 17:41:10
|
On Wed, 31 May 2006, Louis Pecora wrote: > Is this good matplotlib behavior? I think so. It is Python behavior. You are using a mutable object, and the plot of this object changes when you chage the object. > Is it necessary to use new variables for each call of > plot? No. Just assign a new object to the name, rather than changing the existing object. hth, Alan Isaac |
|
From: Louis P. <pe...@an...> - 2006-05-31 17:28:20
|
I have some simple code (I've cut it down a lot, but kept the problem)
that tries to plot two sets of data using the same variables. It
appears that re-using the variables from the first plot for the second
plot affects the first plot. In fact the two plots become identical. I
am guessing that the variables used in the 1st plot are pointed to by
other matplotlib internal variables (but not plotted until Show() is
called -- a guess on my part). In Python fashion when I change a
variable in preparation for the 2nd plot, the values in the 1st plot
change, too.
Here is sample code based on some code sent to me by Jeremy O'Donoghue
as an example of how to embed matplotlib in wxPython. The problem is in
the method plot_data in the PlotFigure class. Note how x and y are
reused for the 2nd plot. The output should be an 'X' shape, but only
one line shows up, the 2nd plot line. If you add new variables to do
the 2nd plot (e.g. u=zeroes((2,),Float), v=zeroes((2,),Float)) and
replace the x and y in the 2nd plot with those variables, then it works
correctly.
Is this good matplotlib behavior? Is it necessary to use new variables
for each call of plot?
I am using wxPython wx-2.6-mac-unicode, matplotlib 0.82, Python 2.4,
on a Macintosh Powerbook G4, OS X 10.4
--------------------------------- The code (self contained as run from
BBEdit through the Terminal):
#!/usr/local/bin/pythonw
from Numeric import *
import matplotlib
matplotlib.use('WX')
from matplotlib.backends.backend_wx import Toolbar, FigureCanvasWx,\
FigureManager
from matplotlib.figure import Figure
from matplotlib.axes import Subplot
import matplotlib.numerix as numpy
import wx
class PlotFigure(wx.Frame):
def __init__(self):
wx.Frame.__init__(self, None, -1, "Test embedded wx.Figure")
self.fig = Figure((10,8), 75)
self.canvas = FigureCanvasWx(self, -1, self.fig)
self.toolbar = Toolbar(self.canvas)
self.toolbar.Realize()
# On Windows, default frame size behaviour is incorrect
# you don't need this under Linux
tw, th = self.toolbar.GetSizeTuple()
fw, fh = self.canvas.GetSizeTuple()
self.toolbar.SetSize(wx.Size(fw, th))
# Create a figure manager to manage things
self.figmgr = FigureManager(self.canvas, 1, self)
# Now put all into a sizer
sizer = wx.BoxSizer(wx.VERTICAL)
# This way of adding to sizer allows resizing
sizer.Add(self.canvas, 1, wx.LEFT|wx.TOP|wx.GROW)
# Best to allow the toolbar to resize!
sizer.Add(self.toolbar, 0, wx.GROW)
self.SetSizer(sizer)
self.Fit()
# *** HERE'S THE PROBLEM PART ***
def plot_data(self):
# Use ths line if using a toolbar
a = self.fig.add_subplot(111)
# Or this one if there is no toolbar
#a = Subplot(self.fig, 111)
x=zeros((2,),Float)
y=zeros((2,),Float)
# 1st Plot .................
x[0]= 1.0
y[0]= 1.0
x[1]=-1.0
y[1]=-1.0
a.plot(x,y)
# 2nd Plot .................
x[0]=-1.0
y[0]= 1.0
x[1]= 1.0
y[1]=-1.0
a.plot(x,y)
self.toolbar.update()
def GetToolBar(self):
# You will need to override GetToolBar if you are using an
# unmanaged toolbar in your frame
return self.toolbar
if __name__ == '__main__':
# Plot
app = wx.PySimpleApp(0)
frame = PlotFigure()
frame.plot_data()
frame.Show()
app.MainLoop()
--
Cheers,
Lou Pecora
Code 6362
Naval Research Lab
Washington, DC 20375
USA
Ph: +202-767-6002
email: pe...@an...
|
|
From: leau2001 <lea...@fr...> - 2006-05-31 09:17:00
|
Hi, i try to use the plot_date function and i have some problems, is
anybody can help me
My program :
First to show it's ok to run if i just used the only plot function
> from pylab import *
> import marshal
> import time
> import string
>
> lst_date=[]
> points=[]
> belos=[['2', '2', '2', '2', '2', '2', '2', '54', '125', '169', '224',
> '245', '245', '245', '325', '325', '325', '453', '486', '521', '521',
> '521', '8596', '9566', '9848', '10064'], [1148378715.6400001,
> 1148379045.312, 1148379057.7179999, 1148379069.375, 1148379331.921,
> 1148390222.3280001, 1148390265.2650001, 1148396382.562,
> 1148464116.609, 1148481671.6559999, 1148534908.2520001,
> 1148551483.8299999, 1148573370.8770001, 1148589279.517,
> 1148625453.8429999, 1148640384.5150001, 1148659451.25, 1148709552.921,
> 1148740419.375, 1148799935.5780001, 1148827804.0, 1148886086.109,
> 1148915795.984, 1148972914.8429999, 1149001049.671,
> 1149053926.7650001], ['2:349:7', '2:349:7', '2:349:7', '2:349:7',
> '2:349:7', '2:349:7', '2:349:7', '3:56:5', '3:56:5', '3:56:5', '3:56:5']]
>
> point=belos[0]
> dt_date=belos[1]
>
>
> for j in dt_date:
> date=time.ctime(j)
> lst_date.append(date)
>
> print lst_date
>
>
> for i in point:
> a=int(i)
> points.append(a)
>
> print belos
> print point
> print len(point)
> print len(lst_date)
> #plot (date, point, 'ro')
> #show()
>
> #plot_date(dt_date, points, '', xdate=True, ydate=False)
> plot(dt_date, points, '',)
> #savefig('secondfig.png')
> show()
The i try with the plot_date function and i got on error:
> Traceback (most recent call last):
> File "C:\Python24\uni_22\belos_stat.py", line 32, in -toplevel-
> plot_date(dt_date, points, '', xdate=True, ydate=False)
> File "C:\Python24\Lib\site-packages\matplotlib\pylab.py", line 2039,
> in plot_date
> ret = gca().plot_date(*args, **kwargs)
> File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 2830,
> in plot_date
> self.autoscale_view()
> File "C:\Python24\Lib\site-packages\matplotlib\axes.py", line 815,
> in autoscale_view
> self.set_xlim(locator.autoscale())
> File "C:\Python24\Lib\site-packages\matplotlib\dates.py", line 537,
> in autoscale
> dmin, dmax = self.datalim_to_dt()
> File "C:\Python24\Lib\site-packages\matplotlib\dates.py", line 403,
> in datalim_to_dt
> return num2date(dmin, self.tz), num2date(dmax, self.tz)
> File "C:\Python24\Lib\site-packages\matplotlib\dates.py", line 205,
> in num2date
> if not iterable(x): return _from_ordinalf(x, tz)
> File "C:\Python24\Lib\site-packages\matplotlib\dates.py", line 154,
> in _from_ordinalf
> dt = datetime.datetime.fromordinal(ix)
> ValueError: year is out of range
i want the x axis show me the date on this format : Tue May 23 12:05:15
2006', 'Tue May 23 12:10:45 2006', 'Tue May 23 12:10:57 2006 etc...
Thx for answer
|
|
From: <dd...@ja...> - 2006-05-31 02:10:46
|
On Friday 26 May 2006 11:08 am, Michael McNeil Forbes wrote:
> I am having some problems with the axes frame being clipped.
>
>
> Consider the following:
>
> from pylab import *
> fill([0,1,1,0],[0,0,1,1],facecolor=(1,1,1),edgecolor=(1,1,1))
> axis([-1,1,-1,1])
> gca().get_frame().set_linewidth(20)
> show()
I've had the same problem as you. My crude hack was to slightly extend the
xlim and ylim as in
xlim(xmin-xclip, xmax+xclip)
ylim(ymin-yclip, ymax+yclip)
where xclip and yclip are small values (about 0.5% of the x and y ranges).
|
|
From: Andrew S. <str...@as...> - 2006-05-29 18:37:45
|
Eric, This works great and fixes all the issues I saw. Thanks much. I didn't see the anomaly you mentioned. PS My ISP (dreamhost.com)'s email server is SpamCop's blackhole, which means SourceForge will reject it from the mailing list unless they've resolved the issue already. Eric Firing wrote: >Andrew, > >I have committed another revision of the aspect-ratio handling. It seems to work pretty well, and I think pan/zoom work in a reasonable fashion now. Many times in the past, however, I have thought that aspect-ratio handling was working adequately, and every time someone has found a major bug. This time is probably no exception. > >There can be some anomalies when the window is resized quickly--that is, grabbing a window corner and slinging it around with axis('equal') can cause some incorrect choices of the view limits. I haven't figured out why. Although I certainly would like to understand and fix it, it is not a top priority at the moment because I don't think it is a major problem in practice. > > |
|
From: Eric F. <ef...@ha...> - 2006-05-29 18:11:59
|
Andrew,
I have committed another revision of the aspect-ratio handling. It seems to work pretty well, and I think pan/zoom work in a reasonable fashion now. Many times in the past, however, I have thought that aspect-ratio handling was working adequately, and every time someone has found a major bug. This time is probably no exception.
There can be some anomalies when the window is resized quickly--that is, grabbing a window corner and slinging it around with axis('equal') can cause some incorrect choices of the view limits. I haven't figured out why. Although I certainly would like to understand and fix it, it is not a top priority at the moment because I don't think it is a major problem in practice.
Eric
----- Original Message -----
From: Andrew Straw <str...@as...>
Date: Saturday, May 27, 2006 12:07 pm
Subject: Re: [Matplotlib-users] autoscale and "equal aspect" mode
To: Eric Firing <ef...@ha...>, mat...@li...
> I'm having trouble with axis('equal') myself -- I'm happy to take a
> lookin the source, but maybe it's a simple and easy bug. The issue I'm
> having is readily apparent with examples/axis_equal_demo.py --
> using the
> pan/zoom mode and holding the right-mouse button down to zoom, I
> noticeseveral issues:
>
> 1) moving left-and-right seems to affect the position, not the zoom
> level2) moving up seems to zoom in (as expected)
> 3) moving down zooms out as expected, but past a certain point,
> only the
> vertical axis gets re-scaled and breaking the equal-aspect.
>
> Eric Firing wrote:
>
> > Mike,
> >
> > I thought all the aspect handling was finally working correctly. If
> > you generate a simple example, I will take a look. The simpler the
> > better, of course. I presume you are working with a recent svn
> version.>
> > Eric
> >
> > Michael P. Mossey wrote:
> >
> >> I'm using this aspect mode:
> >>
> >> axes.set_aspect( 'equal', adjustable='datalim' )
> >>
> >> With several xy line plots on the axes, autoscaling doesn't seem to
> >> occur properly. It cuts off part of the data. Is this a known
> issue?>> I don't have a simple script to replicate it---I'll have
> to pull that
> >> out of a larger program---but just wanted to check if it is
> known. I
> >> don't see anything in the bug tracker.
> >>
> >> Mike
> >>
>
>
|
|
From: David H. <dav...@gm...> - 2006-05-29 16:35:32
|
Hum, I did, but it is still pretty rough. I did some changes to it a while ago t= o use objects and it still isn't complete. I'll try to get the class in working order by the weekend. Cheers, David |
|
From: Charlie M. <cw...@gm...> - 2006-05-29 13:28:07
|
The 0.87.2 release requires numpy-0.9.6. - Charlie On 5/29/06, Uri Nix <Ur...@zo...> wrote: > > > Hi, > > I'm using Python 2.4.1, numpy-0.9.8, and matplotlib-0.87.2 on a Windo= ws > XP computer. > Problem is that any attempt to import pylab results in a crash. > Using "python -v", the culprit seems to be the following line: > > # > c:\Python24\lib\site-packages\matplotlib\_transforms.pyc > matches > c:\Python24\lib\site-packages\matplotlib\_transforms.py > import matplotlib._transforms # precompiled from > c:\Python24\lib\site-packages\matplotlib\_transforms.pyc > > Any ideas and solutions to this issue? > > Cheers, > Uri |
|
From: Uri N. <Ur...@zo...> - 2006-05-29 05:46:46
|
Hi,
=20
I'm using Python 2.4.1, numpy-0.9.8, and matplotlib-0.87.2 on a
Windows XP computer.
Problem is that any attempt to import pylab results in a crash.
Using "python -v", the culprit seems to be the following line:
=20
# c:\Python24\lib\site-packages\matplotlib\_transforms.pyc matches
c:\Python24\lib\site-packages\matplotlib\_transforms.py
import matplotlib._transforms # precompiled from
c:\Python24\lib\site-packages\matplotlib\_transforms.pyc
Any ideas and solutions to this issue?
=20
Cheers,
Uri
|
|
From: Eric F. <ef...@ha...> - 2006-05-27 23:35:37
|
Andrew,
Sure enough. I did not pay a lot of attention to the zoom part of
pan/zoom mode with fixed aspect ratio because it doesn't make much sense
to me--it is trying to change the aspect ratio, while the aspect-ratio
code is desperately trying to keep the aspect ratio fixed. The solution
is probably to redefine what the right-button-event does in the fixed
aspect ratio case. It should either be disabled, or arranged so that
motion to the right and/or up zooms in and to the left and/or down zooms
out. What do you think it should do?
Left-button pan is definitely broken for horizontal motion.
I think what we have is not a single simple bug, but a whole set of
bugs. It seems to be difficult to fix one thing related to aspect-ratio
handling without breaking something else for interactive drawing. That
probably means the overall design is bad. When I can, I will take
another look and see if I can patch it up, but it won't be right away.
If you can find a solution, that would be great.
Eric
Andrew Straw wrote:
> I'm having trouble with axis('equal') myself -- I'm happy to take a look
> in the source, but maybe it's a simple and easy bug. The issue I'm
> having is readily apparent with examples/axis_equal_demo.py -- using the
> pan/zoom mode and holding the right-mouse button down to zoom, I notice
> several issues:
>
> 1) moving left-and-right seems to affect the position, not the zoom level
> 2) moving up seems to zoom in (as expected)
> 3) moving down zooms out as expected, but past a certain point, only the
> vertical axis gets re-scaled and breaking the equal-aspect.
>
> Eric Firing wrote:
>
>
>>Mike,
>>
>>I thought all the aspect handling was finally working correctly. If
>>you generate a simple example, I will take a look. The simpler the
>>better, of course. I presume you are working with a recent svn version.
>>
>>Eric
>>
>>Michael P. Mossey wrote:
>>
>>
>>>I'm using this aspect mode:
>>>
>>> axes.set_aspect( 'equal', adjustable='datalim' )
>>>
>>>With several xy line plots on the axes, autoscaling doesn't seem to
>>>occur properly. It cuts off part of the data. Is this a known issue?
>>>I don't have a simple script to replicate it---I'll have to pull that
>>>out of a larger program---but just wanted to check if it is known. I
>>>don't see anything in the bug tracker.
>>>
>>>Mike
>>>
>
>
|
|
From: John H. <jdh...@ac...> - 2006-05-27 17:37:58
|
>>>>> "Jochen" == Jochen Voss <li...@se...> writes:
Jochen> By the way: does anybody know how to move a patch in
Jochen> matplotlib? set_data works for lines, but what works for
Jochen> patches?
This should be easier, but here's an example with a regular polygon --
it is quite easy to generalize this to any patch...
Use the blit techniques described on the animation wiki if you want to
make this significantly more efficient
from matplotlib.patches import RegularPolygon
from pylab import figure, show, nx
class MyPoly(RegularPolygon):
def __init__(self, *args, **kwargs):
RegularPolygon.__init__(self, *args, **kwargs)
self.offsetx = 0
self.offsety = 0
self.x, self.y = map(nx.array, zip(*RegularPolygon.get_verts(self)))
def get_verts(self):
x = self.x + self.offsetx
y = self.y + self.offsety
return zip(x, y)
poly = MyPoly(xy=(1,1), numVertices=6, radius=5)
fig = figure()
ax = fig.add_subplot(111, xlim=(-100, 100), ylim=(-100, 100), autoscale_on=False)
ax.add_patch(poly)
def start(event):
fig.canvas.mpl_disconnect(start.cid)
randn = nx.mlab.randn
for i in range(200):
poly.offsetx += 2*randn()
poly.offsety += 2*randn()
fig.canvas.draw()
start.cid = fig.canvas.mpl_connect('draw_event', start)
show()
|
|
From: Jochen V. <li...@se...> - 2006-05-27 13:26:15
|
Hi Andrew, On Fri, May 26, 2006 at 11:42:07AM -0700, Andrew Straw wrote: > Wishing that in 2006 we as a human race could come up with a better,=20 > open video format, ... I think most of the problems is caused by software patents. It is just not safe for Linux distributions etc. to integrate video encoders, so all the solutions which exist are hidden away somewhere, are not well integrated into the system, and also not too well tested. By the way: does anybody know how to move a patch in matplotlib? set_data works for lines, but what works for patches? Many thanks, Jochen --=20 http://seehuhn.de/ |
|
From: Jochen V. <li...@se...> - 2006-05-27 13:20:49
|
Hi Alan,
On Fri, May 26, 2006 at 12:26:07PM -0400, Alan G Isaac wrote:
> How are you turning your PNGs into an animation?
Sorry about the slow answer. I just used mencoder:
mencoder 'mf://oc/*.png' -mf type=3Dpng:fps=3D12 -ovc lavc -lavcopts vc=
odec=3Dmpeg4 -o ocean.avi
All the best,
Jochen
--=20
http://seehuhn.de/
|
|
From: Alan G I. <ai...@am...> - 2006-05-27 00:38:43
|
On Fri, 26 May 2006, Andrew Straw apparently wrote: > ffmpeg -hq -b 8000 -f mpeg2video -r 30 -i frame%03d.png movie.mpeg" > * it seems very fragile -- changing the frame rate or the > codec usually breaks one of the above points OK. Thanks for the information and warning. Did you experiment with MNG, or is support just not there yet? (And will the next PIL be supporting MNG?) Cheers, Alan Isaac |
|
From: Andrew S. <str...@as...> - 2006-05-26 18:42:24
|
I use the following on Debian Sarge linux (both x86_64 and i686, although I hope/think it would work on any architecture and hopefully any linux distro): "ffmpeg -hq -b 8000 -f mpeg2video -r 30 -i frame%03d.png movie.mpeg" You may now skip the rest of this email, which is an uncalled-for venting-of-frustration. Unfortunately, it seems bazillions of software companies think they can make bazillions of dollars by releasing yet another codec encumbered by more-or-less (but usually more) restrictive licensing conditions, leaving only lowest-common denominator codecs available for those of us who prefer to work without such restrictions. I sought long and hard to do something better than the above, but I can say this about the above command: * it produces movies that play in Windows (including PowerPoint, which isn't a given, even if it plays in Windows Media Player -- c'mon Microsoft, this is 2006, we should be able to play movies in our presentations), Mac OS X, and linux (Debian sarge, amd64 and i386, at least) * it seems to work with a standard Debian setup, and doesn't require using DLLs imported from some Windows system to to the encoding * it seems very fragile -- changing the frame rate or the codec usually breaks one of the above points * mpeg2 is probably also burdened by some licensing restrictions which I'm unaware of * on some Windows boxes/programs, white backgrounds get displayed as gray for some reason Wishing that in 2006 we as a human race could come up with a better, open video format, but willing to accept even minor improvements to the above script, Andrew Alan G Isaac wrote: >How are you turning your PNGs into an animation? > >Thanks, >Alan Isaac > >PS I know about >http://www.pymolwiki.org/index.php/Category%3ASoftware_Movies > > |
|
From: Robert K. <rob...@gm...> - 2006-05-26 18:40:16
|
hu...@ya... wrote: > Hi, > > just a small question about histogram. I saw that the result of the hist > function from pylab and histogram from numpy+scipy can be slightly different > when the array is big and with real data (not integer). I'll probably told > something stupid but perhaps that will be good to have consistancies between > both function, won't it? There are lots of different, equally valid ways to construct a histogram. pylab.hist() and scipy.stats.histogram() probably use different algorithms. It's probably not worth changing one just to match the other. Much better would be to provide a broader interface to let the user twiddle the various knobs he would like to twiddle. I believe David Huard posted an improved histogram class that implements a number of useful features. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco |
|
From: <hu...@ya...> - 2006-05-26 18:27:11
|
Here a sample:
the data are in the file data.dat join.
In [1]: import pylab
In [2]: import scipy
In [3]: import scipy.stats
In [4]: data1,data2=pylab.load('data.dat',unpack=True)
In [5]: pylab.hist(data1,20)
(Out[5]:
array([ 4, 6, 23, 52, 90, 128, 184, 244, 283, 293, 297, 330, 321,
231, 188, 140, 94, 48, 29, 15]),
array([ 0.00998046, 0.01054459, 0.01110872, 0.01167285, 0.01223698,
0.01280111, 0.01336524, 0.01392937, 0.0144935 , 0.01505763,
0.01562176, 0.01618589, 0.01675002, 0.01731415, 0.01787828,
0.01844241, 0.01900654, 0.01957067, 0.0201348 , 0.02069894]),
<a list of 20 Patch objects>)
In [6]: scipy.stats.histogram(data1,20)
Out[6]:
(array([ 1, 7, 17, 43, 75, 126, 185, 248, 303, 302, 314, 353, 315,
241, 178, 145, 70, 51, 20, 6]),
0.0096835454084847374,
0.00059382155039052636,
0)
> humufr> Hi, just a small question about histogram. I saw that the
> humufr> result of the hist function from pylab and histogram from
> humufr> numpy+scipy can be slightly different when the array is
> humufr> big and with real data (not integer). I'll probably told
> humufr> something stupid but perhaps that will be good to have
> humufr> consistancies between both function, won't it?
>
> Complete example, please...
>
> JDH
>
>
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
|
|
From: Christopher B. <Chr...@no...> - 2006-05-26 18:06:11
|
Allan Noriel Estrella wrote: > can you give the url of wxmpl and Mplot, i had a hard time googling for > them That's rare, but I had trouble too, some of the google links are dead, but I found this for wxmpl: http://agni.phys.iit.edu/~kmcivor/wxmpl/ and this (just the files) for Mplot: http://cars9.uchicago.edu/~newville/Python/MPlot/ If you search this list, you'll see discussion of the differences between them, but I'll try this short synopsis (Kevin and Matt, please correct as needed) wxmpl is designed to make it a bit easier to embed matplotlib in a a wxPython app. Once you've got a PlotPanel (or PlotFrame), you do your plotting with the matplotlib OO API (and some of pylab) Mplot is designed to provide a plotting window that the end-user of the application can interact with, doing at least some manipulation of the plot. It provides and alternative API for plotting that is easy to use, but not feature-complete. Note that I haven't Mplot, so I may have that a bit wrong. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: John H. <jdh...@ac...> - 2006-05-26 16:23:16
|
>>>>> "humufr" == humufr <hu...@ya...> writes:
humufr> Hi, just a small question about histogram. I saw that the
humufr> result of the hist function from pylab and histogram from
humufr> numpy+scipy can be slightly different when the array is
humufr> big and with real data (not integer). I'll probably told
humufr> something stupid but perhaps that will be good to have
humufr> consistancies between both function, won't it?
Complete example, please...
JDH
|
|
From: <hu...@ya...> - 2006-05-26 16:19:04
|
Hi, just a small question about histogram. I saw that the result of the hist function from pylab and histogram from numpy+scipy can be slightly different when the array is big and with real data (not integer). I'll probably told something stupid but perhaps that will be good to have consistancies between both function, won't it? N. |
|
From: Alan G I. <ai...@am...> - 2006-05-26 16:18:53
|
How are you turning your PNGs into an animation? Thanks, Alan Isaac PS I know about http://www.pymolwiki.org/index.php/Category%3ASoftware_Movies |
|
From: Christopher B. <Chr...@no...> - 2006-05-26 16:17:40
|
Bryan Cole wrote:
> To accomplish similar goals, I embed a matplotlib panel (including
> toolbar) in a wxPython application
If you do this, be sure to take a look at wxmpl and/or Mplot , they make
it a bit easier to embed MPL in wxPython.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...
|
|
From: Alan G I. <ai...@am...> - 2006-05-26 15:00:27
|
On Fri, 26 May 2006, Giandomenico Sica apparently wrote:
> Insert a number: 4
> Couples: [[4, 3], [4, 2], [4, 1], [3, 2], [3, 1], [2, 1]]
> What I'd like to do is drawing with Matplotlib a graph having as nodes
> 1, 2, 3, 4 and as edges among the nodes the above couples.
n = input("Insert a number" )
a = reversed(range(1,n+1))
coppie = [[i,j] for i in a for j in range(1,i)]
print coppie
G = NX.Graph()
for edge in coppie:
G.add_edge(*edge)
print G.edges()
NX.draw(G)
pylab.savefig(r'c:\temp\temp.eps')
hth,
Alan Isaac
|
|
From: Giandomenico S. <gia...@po...> - 2006-05-26 11:02:47
|
Hello, I'm new in Matplotlib and am writing in order to ask a help. I've developed a little software with Python that, by inserting a number, calculate a list of couples. Example Insert a number: 4 Couples: [[4, 3], [4, 2], [4, 1], [3, 2], [3, 1], [2, 1]] What I'd like to do is drawing with Matplotlib a graph having as nodes 1, 2, 3, 4 and as edges among the nodes the above couples. (sample drawing: https://networkx.lanl.gov/) Can you help me to make this operation please? My code at the present is the following one. n = input("Insert a number" ) a = range(n) p = 0 q = 1 coppie = [] coppia = [] while len(a) - p != 1: coppia.append(len(a) - p) coppia.append(len(a) - p - q) coppie.append(coppia) coppia = [] if len(a) - p - q != 0: q = q + 1 if len(a) - p - q == 0: p = p + 1 q = 1 print coppie I suppose it is quite easy but in spite of this have some difficulty. Really many thanks for the help! Best, Nico |
|
From: Michael M. F. <mf...@nt...> - 2006-05-26 02:15:10
|
I am having some problems with the axes frame being clipped. Consider the following: from pylab import * fill([0,1,1,0],[0,0,1,1],facecolor=(1,1,1),edgecolor=(1,1,1)) axis([-1,1,-1,1]) gca().get_frame().set_linewidth(20) show() I have made the frame thick to emphasize the problem: When I plot things, they overwrite part of the frame which looks bad. What is the simplest/best way to avoid this? I would like the axes frame to be drawn only outside of the actual plot area, but I cannot figure out how to achieve this. (It seems like this might also be desirable default behaviour...). Otherwise, I would settle for the frame being drawn over top of the plot so that it is smooth. A crude hack would be to plot a blank rectangle. It should also be possible to use clipping somehow, but I do not have much experience with that. Is there a simple solution? Thanks for any help, Michael |