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
(2) |
2
(8) |
3
(8) |
4
(3) |
5
(15) |
6
(11) |
7
(4) |
|
8
|
9
(3) |
10
(21) |
11
(5) |
12
(7) |
13
(10) |
14
(12) |
|
15
(3) |
16
(4) |
17
(16) |
18
(20) |
19
(11) |
20
(9) |
21
(1) |
|
22
|
23
(15) |
24
(11) |
25
(1) |
26
(9) |
27
(5) |
28
|
|
29
(1) |
30
|
31
(6) |
|
|
|
|
|
From: Michael D. <md...@st...> - 2007-07-18 12:04:37
|
mark starnes wrote: > Hi Mike, thanks for responding. > > I spent most of last night with this, re-installing Python using SuSE's > package manager, re-installing matplotlib the same way. No joy. I > tried downloading the matplotlib source and found that when I attempted > to install, setup.py claimed I didn't have gtk available as a Python > import. Checking this, I found it to be true although the installation > directories are present. Re-installing gtk and things that depended on > it had no effect - it still wont import. > > Checking another machine, I found it worked ok with gtk, pylab and > anything else I could test. The file versions and directory structures > were the same. > > Following your UCS2 / UCS4 comments and a scroogle search, I found this: > > http://copia.ogbuji.net/blog/2006-01-09/Confusion_ > > sys.maxunicode is set to 65535 on the non-working installation. > sys.unicode is set to 1114111 on the working installation! How did they > become different? How can I get them to match? > The one that returns 65535 is 16-bit UCS2. That probably was built from source, since most Linux distributions ship Python as UCS4. > Checking sys.prefix on both installations shows the working machine to > be '/usr', the non working, '/usr/local'. > That's another good data point. The non-working one was built from source, and not from an installed SuSE package. > $ whereis python > Generates thirteen results on the working installation, one of which > refers to a /local/ type entry. The non-working installation shows > fifteen entries, five of which contain '/local/. > What's most important is what comes first, because that's what will run when you simply type 'python'. (And sys.prefix tells you that, too). These are all clues without a definitive answer, but I'd put my money on: you have a source-built Python sitting around in /usr/local which can not access and is incompatible with all of the package-installed stuff you have. > To be honest, I'm lost. I'd like to remove Python and re-install it, > with all the modules I'm now using. Removing it with SuSE's package > manager generates all sorts of problems with dependencies. Updating it > has no effect. Is there a way to convince the system to start afresh > (assuming that's the best approach), maybe removing the local settings? > There's probably hundreds of crucial things that depend on Python, which is why removing it causes all of the dependency problems. I almost feel guilty saying this, but if you don't want to keep anything you've built from source (including non-Python stuff), you could *backup* and then remove your /usr/local folder. I can't stress the backup part enough ;) Then you should (most likely) only be dealing with stuff installed from SuSE packages. Uninstalling things built from source is usually not directly possible without using a tool like checkinstall. You may also want to make sure that the PYTHONPATH environment variable isn't set to anything. That will affect where Python libraries are loaded from, and if you want to be in a "default" situation, it should be unset. Cheers, Mike > > Michael Droettboom wrote: > >> I recently ran into a similar problem myself building stuff from source, >> but I'm not sure of the specifics with SuSE and their packages etc. >> >> Python can be configured in two ways -- with two-byte (UCS2) or >> four-byte (UCS4) Unicode characters. Apparently the default for a >> source installation of Python is UCS2, but many (most) Linux >> distributions build it for UCS4. Python extensions built for one >> configuration can not be used with a Python built for the other >> configuration. >> >> When Python extensions are built, if all goes well, they will match the >> configuration of the Python interpreter. It looks like somehow you have >> a mismatch between matplotlib and your Python interpreter. >> >> If you installed everything from packages, I would expect them all to >> match (unless SuSE's quality control has really gone down as of late >> ;). Perhaps something is still around from when you built things from >> source. Did you at any point build your own Python? >> >> On a number of Linux distributions (probably including SuSE, but I don't >> know for sure), things installed from source are under the /usr/local >> tree. To diagnose this, you could see if anything is getting pulled in >> from there (rather than from the packaged stuff, which wouldn't be under >> /usr/local). For instance "whereis python", will tell you which python >> is being used. When you import a Python module, you can use __file__ to >> see where it was imported from. For example: >> >> >>>>> import pylab >>>>> pylab.__file__ >>>>> >> Hope that at least offers some next steps for tracking this down. >> >> Cheers, >> Mike >> >> mark starnes wrote: >> >>> Hi everyone, >>> >>> I'm running Suse10.2 and installing packages using Yast (after much pain >>> trying to install Numpy and Scipy without it!). After installing (and >>> re-installing) Matplotlib in this way, I get the error, >>> >>> ImportError: matplotlib/ft2font.so: undefined symbol: >>> PyUnicodeUCS4_GetSize >>> >>> when I attempt to import pylab. >>> >>> Can anybody help me fix this? I couldn't find any help on the >>> matplotlib site and my .matplotlib directory is empty. >>> >>> Oh, I'm also a bit new to Linux - please be patient! >>> >>> Thanks in advance, >>> >>> Mark. >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >>> >> |
|
From: mark s. <m.s...@im...> - 2007-07-18 11:46:44
|
Further to the last post, I've also noticed strange behavior when importing distutils. >>> import distutils as d >>> dir(d) ['__builtins__', '__doc__', '__file__', '__name__', '__path__', '__revision__', '__version__'] >>> d.__file__ '/usr/local/lib/python2.5/distutils/__init__.pyc' Maybe this is linked to my other problems...... Cheers, Mark. mark starnes wrote: > Hi Mike, thanks for responding. > > I spent most of last night with this, re-installing Python using SuSE's > package manager, re-installing matplotlib the same way. No joy. I > tried downloading the matplotlib source and found that when I attempted > to install, setup.py claimed I didn't have gtk available as a Python > import. Checking this, I found it to be true although the installation > directories are present. Re-installing gtk and things that depended on > it had no effect - it still wont import. > > Checking another machine, I found it worked ok with gtk, pylab and > anything else I could test. The file versions and directory structures > were the same. > > Following your UCS2 / UCS4 comments and a scroogle search, I found this: > > http://copia.ogbuji.net/blog/2006-01-09/Confusion_ > > sys.maxunicode is set to 65535 on the non-working installation. > sys.unicode is set to 1114111 on the working installation! How did they > become different? How can I get them to match? > > Following the link, a comment is made on > http://copia.ogbuji.net/blog/2005-08-04/alt_unicod about site.py. > >>>> import site >>>> site.__file__ b # thanks for the tip Mike! > > showed the working installation to point to > > '/usr/lib/python2.5/site.pyc' > > The non-working to > > '/usr/local/lib/python2.5.site.pyc' > > local? Maybe that's one of the leftovers from the source experiments I > was doing. > > Checking sys.prefix on both installations shows the working machine to > be '/usr', the non working, '/usr/local'. > > $ whereis python > Generates thirteen results on the working installation, one of which > refers to a /local/ type entry. The non-working installation shows > fifteen entries, five of which contain '/local/. > > To be honest, I'm lost. I'd like to remove Python and re-install it, > with all the modules I'm now using. Removing it with SuSE's package > manager generates all sorts of problems with dependencies. Updating it > has no effect. Is there a way to convince the system to start afresh > (assuming that's the best approach), maybe removing the local settings? > > Thanks for your patience. > > Best regards, > > Mark. > > > Michael Droettboom wrote: >> I recently ran into a similar problem myself building stuff from source, >> but I'm not sure of the specifics with SuSE and their packages etc. >> >> Python can be configured in two ways -- with two-byte (UCS2) or >> four-byte (UCS4) Unicode characters. Apparently the default for a >> source installation of Python is UCS2, but many (most) Linux >> distributions build it for UCS4. Python extensions built for one >> configuration can not be used with a Python built for the other >> configuration. >> >> When Python extensions are built, if all goes well, they will match the >> configuration of the Python interpreter. It looks like somehow you have >> a mismatch between matplotlib and your Python interpreter. >> >> If you installed everything from packages, I would expect them all to >> match (unless SuSE's quality control has really gone down as of late >> ;). Perhaps something is still around from when you built things from >> source. Did you at any point build your own Python? >> >> On a number of Linux distributions (probably including SuSE, but I don't >> know for sure), things installed from source are under the /usr/local >> tree. To diagnose this, you could see if anything is getting pulled in >> from there (rather than from the packaged stuff, which wouldn't be under >> /usr/local). For instance "whereis python", will tell you which python >> is being used. When you import a Python module, you can use __file__ to >> see where it was imported from. For example: >> >>>>> import pylab >>>>> pylab.__file__ >> Hope that at least offers some next steps for tracking this down. >> >> Cheers, >> Mike >> >> mark starnes wrote: >>> Hi everyone, >>> >>> I'm running Suse10.2 and installing packages using Yast (after much pain >>> trying to install Numpy and Scipy without it!). After installing (and >>> re-installing) Matplotlib in this way, I get the error, >>> >>> ImportError: matplotlib/ft2font.so: undefined symbol: >>> PyUnicodeUCS4_GetSize >>> >>> when I attempt to import pylab. >>> >>> Can anybody help me fix this? I couldn't find any help on the >>> matplotlib site and my .matplotlib directory is empty. >>> >>> Oh, I'm also a bit new to Linux - please be patient! >>> >>> Thanks in advance, >>> >>> Mark. >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Matplotlib-users mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >>> >> > |
|
From: Ben N. <be...@re...> - 2007-07-18 11:35:41
|
Hi, I wrote: > I was wondering, though, whether there'd be any support for some work > which tidied up the near-duplicate code in axes.py. which produced a couple of replies. I think this is probably more of a matplotlib-devel topic than a -users one, so I'll post a reply over there. Ben. |
|
From: Darren D. <dd...@co...> - 2007-07-18 11:11:19
|
On Wednesday 18 July 2007 6:56:18 am Armando Serrano Lombillo wrote:
> Yes!
> matplotlib is beautiful. Thanks everybody for your help.
Here is another way, with numpy arrays:
data[data==0]=nan
plot(data)
> On 7/18/07, Angus McMorland <am...@gm...> wrote:
> > Hi Armando,
> >
> > On 18/07/07, Armando Serrano Lombillo <ars...@gm...> wrote:
> > > Hello, I have a question.
> > >
> > > Let's say I have the following data:
> > > [1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
> > > which I want to plot, but I want to omit the zeros, so I would like to
> >
> > do
> >
> > > something like:
> > > plot(range(1,6), [1,3,6,1,2], 'b')
> > > plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
> > > plot(range(30,36), [1,3,5,6,7,8], 'b')
> > > savefig('filtered.eps')
> > >
> > > Is there an elegant way of doing this?
> >
> > Do masked arrays achieve what you want?
> >
> > from numpy.core import ma
> > data = n.array
> > ([1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8])
> > masked_data = ma.masked_array(data, mask=(dat==0))
> > plot(masked_data)
|
|
From: mark s. <m.s...@im...> - 2007-07-18 11:09:00
|
Hi Mike, thanks for responding. I spent most of last night with this, re-installing Python using SuSE's package manager, re-installing matplotlib the same way. No joy. I tried downloading the matplotlib source and found that when I attempted to install, setup.py claimed I didn't have gtk available as a Python import. Checking this, I found it to be true although the installation directories are present. Re-installing gtk and things that depended on it had no effect - it still wont import. Checking another machine, I found it worked ok with gtk, pylab and anything else I could test. The file versions and directory structures were the same. Following your UCS2 / UCS4 comments and a scroogle search, I found this: http://copia.ogbuji.net/blog/2006-01-09/Confusion_ sys.maxunicode is set to 65535 on the non-working installation. sys.unicode is set to 1114111 on the working installation! How did they become different? How can I get them to match? Following the link, a comment is made on http://copia.ogbuji.net/blog/2005-08-04/alt_unicod about site.py. >>> import site >>> site.__file__ b # thanks for the tip Mike! showed the working installation to point to '/usr/lib/python2.5/site.pyc' The non-working to '/usr/local/lib/python2.5.site.pyc' local? Maybe that's one of the leftovers from the source experiments I was doing. Checking sys.prefix on both installations shows the working machine to be '/usr', the non working, '/usr/local'. $ whereis python Generates thirteen results on the working installation, one of which refers to a /local/ type entry. The non-working installation shows fifteen entries, five of which contain '/local/. To be honest, I'm lost. I'd like to remove Python and re-install it, with all the modules I'm now using. Removing it with SuSE's package manager generates all sorts of problems with dependencies. Updating it has no effect. Is there a way to convince the system to start afresh (assuming that's the best approach), maybe removing the local settings? Thanks for your patience. Best regards, Mark. Michael Droettboom wrote: > I recently ran into a similar problem myself building stuff from source, > but I'm not sure of the specifics with SuSE and their packages etc. > > Python can be configured in two ways -- with two-byte (UCS2) or > four-byte (UCS4) Unicode characters. Apparently the default for a > source installation of Python is UCS2, but many (most) Linux > distributions build it for UCS4. Python extensions built for one > configuration can not be used with a Python built for the other > configuration. > > When Python extensions are built, if all goes well, they will match the > configuration of the Python interpreter. It looks like somehow you have > a mismatch between matplotlib and your Python interpreter. > > If you installed everything from packages, I would expect them all to > match (unless SuSE's quality control has really gone down as of late > ;). Perhaps something is still around from when you built things from > source. Did you at any point build your own Python? > > On a number of Linux distributions (probably including SuSE, but I don't > know for sure), things installed from source are under the /usr/local > tree. To diagnose this, you could see if anything is getting pulled in > from there (rather than from the packaged stuff, which wouldn't be under > /usr/local). For instance "whereis python", will tell you which python > is being used. When you import a Python module, you can use __file__ to > see where it was imported from. For example: > >>>> import pylab >>>> pylab.__file__ > > Hope that at least offers some next steps for tracking this down. > > Cheers, > Mike > > mark starnes wrote: >> Hi everyone, >> >> I'm running Suse10.2 and installing packages using Yast (after much pain >> trying to install Numpy and Scipy without it!). After installing (and >> re-installing) Matplotlib in this way, I get the error, >> >> ImportError: matplotlib/ft2font.so: undefined symbol: >> PyUnicodeUCS4_GetSize >> >> when I attempt to import pylab. >> >> Can anybody help me fix this? I couldn't find any help on the >> matplotlib site and my .matplotlib directory is empty. >> >> Oh, I'm also a bit new to Linux - please be patient! >> >> Thanks in advance, >> >> Mark. >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > > |
|
From: Armando S. L. <ars...@gm...> - 2007-07-18 10:56:20
|
Yes!
matplotlib is beautiful. Thanks everybody for your help.
On 7/18/07, Angus McMorland <am...@gm...> wrote:
>
> Hi Armando,
>
> On 18/07/07, Armando Serrano Lombillo <ars...@gm...> wrote:
> > Hello, I have a question.
> >
> > Let's say I have the following data:
> > [1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
> > which I want to plot, but I want to omit the zeros, so I would like to
> do
> > something like:
> > plot(range(1,6), [1,3,6,1,2], 'b')
> > plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
> > plot(range(30,36), [1,3,5,6,7,8], 'b')
> > savefig('filtered.eps')
> >
> > Is there an elegant way of doing this?
>
> Do masked arrays achieve what you want?
>
> from numpy.core import ma
> data = n.array
> ([1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8])
> masked_data = ma.masked_array(data, mask=(dat==0))
> plot(masked_data)
>
> Angus.
> --
> AJC McMorland, PhD Student
> Physiology, University of Auckland
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
|
|
From: Angus M. <am...@gm...> - 2007-07-18 10:17:35
|
Hi Armando,
On 18/07/07, Armando Serrano Lombillo <ars...@gm...> wrote:
> Hello, I have a question.
>
> Let's say I have the following data:
> [1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
> which I want to plot, but I want to omit the zeros, so I would like to do
> something like:
> plot(range(1,6), [1,3,6,1,2], 'b')
> plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
> plot(range(30,36), [1,3,5,6,7,8], 'b')
> savefig('filtered.eps')
>
> Is there an elegant way of doing this?
Do masked arrays achieve what you want?
from numpy.core import ma
data = n.array([1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8])
masked_data = ma.masked_array(data, mask=(dat==0))
plot(masked_data)
Angus.
--
AJC McMorland, PhD Student
Physiology, University of Auckland
|
|
From: Armando S. L. <ars...@gm...> - 2007-07-18 10:01:17
|
Hello thanks everybody for you fast replies, but unfortunately there's a
problem with all the solutions you propose: they plot a line between each of
the data sets. It is not the same to do:
plot([1,2],[1,1])
plot([7,8],[1,1])
than to do
plot([1,2,7,8],[1,1,1,1])
The first example plots two disjoint segments, while the second plots three
joint segments.
I did code a workaround to plot the data as I wanted but it's something like
20 lines of ugly code and I really think there must be an easier way.
By the way, Angel, my name is Armando not Alejandro. ;)
On 7/18/07, Armando Serrano Lombillo <ars...@gm...> wrote:
>
> Hello, I have a question.
>
> Let's say I have the following data:
> [1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
> which I want to plot, but I want to omit the zeros, so I would like to do
> something like:
> plot(range(1,6), [1,3,6,1,2], 'b')
> plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
> plot(range(30,36), [1,3,5,6,7,8], 'b')
> savefig('filtered.eps')
>
> Is there an elegant way of doing this?
>
> Armando.
>
|
|
From: Antonino I. <tri...@gm...> - 2007-07-18 09:37:46
|
You can do it this way:
data = array(data)
x = arange(len(data))
plot(x[data!=0], data[data!=0])
Regards,
~ Antonio
|
|
From: Angel L. <an...@gm...> - 2007-07-18 09:31:45
|
Even in only one line: plot([i+1 for i in range(len(data)) if data[i]>0], [i for i in data if i>0]) |
|
From: Angel L. <an...@gm...> - 2007-07-18 09:18:43
|
Hola Alejandro,
sure, I think this can do the job:
write a function to calc your X values:
def x(data):
X=[]
c=1
for i in data:
if i>0:
X.append(c)
c+=1
return X
then your data without zeros in a pythonic way:
>>> my_y_data=[i for i in data if i>0]
with data=[1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
then you can plot:
>>> plot(x(data), my_y_data)
Hope I helped !!
Suerte.
Hasta otra.
On 7/18/07, Armando Serrano Lombillo <ars...@gm...> wrote:
> Hello, I have a question.
>
> Let's say I have the following data:
> [1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
> which I want to plot, but I want to omit the zeros, so I would like to do
> something like:
> plot(range(1,6), [1,3,6,1,2], 'b')
> plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
> plot(range(30,36), [1,3,5,6,7,8], 'b')
> savefig('filtered.eps')
>
> Is there an elegant way of doing this?
>
> Armando.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
|
|
From: Armando S. L. <ars...@gm...> - 2007-07-18 08:48:33
|
Hello, I have a question.
Let's say I have the following data:
[1,3,6,1,2,0,0,0,0,1,4,7,9,4,2,4,6,0,0,0,0,0,0,0,0,0,0,0,0,1,3,5,6,7,8]
which I want to plot, but I want to omit the zeros, so I would like to do
something like:
plot(range(1,6), [1,3,6,1,2], 'b')
plot(range(10,18), [1,4,7,9,4,2,4,6], 'b')
plot(range(30,36), [1,3,5,6,7,8], 'b')
savefig('filtered.eps')
Is there an elegant way of doing this?
Armando.
|
|
From: John H. <jd...@gm...> - 2007-07-17 16:45:16
|
On 7/17/07, Chris Fonnesbeck <lis...@ma...> wrote: > For some reason, builds from SVN dont install either pytz > or dateutil (at least not in the right place). Importing pylab > from these builds results in an import error. > > How can I build these so as to convince these modules to > install correctly? This is typically caused when the install process detects that pytz and dateutil are already installed, and so doesn't overright them. My guess is that they were available in your PYTHONPATH at install time but not at run time. So at install time they are detected and not installed, but at run time they cannot be found. If this is the solution, you need to build and run in the same environment, or blow away existing copies of pytz and dateutil whereever they are lurking and then reinstall mpl. Use the __file__ module attr to poke around and see if you can find them. JDH |
|
From: Darren D. <dd...@co...> - 2007-07-17 16:22:01
|
On Tuesday 17 July 2007 12:04:54 pm John Hunter wrote: > > I was wondering, though, whether there'd be any support for some work > > which tidied up the near-duplicate code in axes.py. I've been playing > > Certainly, but probably not using meta-classes. > > > around with an approach using python's metaclass support, which, for > > example, would replace the definitions of the two near-identical > > functions set_xscale() and set_yscale() with the one meta-definition: > > > > @MC_Traited.construct_traited_variants > > def set__AXISLETTER_scale(self, value, base_AXISLETTER_ = 10, > > subs_AXISLETTER_ = None): """ > > SET_%(axis_letter_UC)sSCALE(value, base%(axis_letter)s = 10, > > subs%(axis_letter)s = None) > > I'm disinclined to use python black magic -- I find it makes the code > harder to grok for the typical scientist, and these are our main > developers. Most of these guys are still trying to figure out what a > class is <wink> It's true. That bit of code looks like Perl to me. Darren |
|
From: John H. <jd...@gm...> - 2007-07-17 16:05:01
|
On 7/17/07, Ben North <be...@re...> wrote:
> There is a difference in the behaviour of Axes.hlines() vs
> Axes.vlines(), in that vlines() lets you supply scalars for ymin and
> ymax, whereas hlines() doesn't (for xmin and xmax). The patch below
> fixes that, and also what looks like a separate bug in vlines. There
> are also other differences, around units, but I haven't worked with that
> area of matplotlib so will leave that for others.
Thanks for catching that -- I recently introduced this bug when I
numpified the axes module. Fixed in svn
> I was wondering, though, whether there'd be any support for some work
> which tidied up the near-duplicate code in axes.py. I've been playing
Certainly, but probably not using meta-classes.
> around with an approach using python's metaclass support, which, for
> example, would replace the definitions of the two near-identical
> functions set_xscale() and set_yscale() with the one meta-definition:
>
> @MC_Traited.construct_traited_variants
> def set__AXISLETTER_scale(self, value, base_AXISLETTER_ = 10, subs_AXISLETTER_ = None):
> """
> SET_%(axis_letter_UC)sSCALE(value, base%(axis_letter)s = 10, subs%(axis_letter)s = None)
I'm disinclined to use python black magic -- I find it makes the code
harder to grok for the typical scientist, and these are our main
developers. Most of these guys are still trying to figure out what a
class is <wink>
But there are other ways to reduce code duplication that are not as clever
def set_xscale(self, value, basex = 10, subsx=None):
self._set_scale(axis=self.xaxis,
transfunc=self.transData.get_funcx(),
limfunc=self.get_xlim,
value=value,
base=basex,
subse=subsx)
def set_yscale(self, value, basex = 10, subsx=None):
self._set_scale(axis=self.yaxis,
transfunc=self.transData.get_funcy(),
limfunc=self.get_ylim,
value=value,
base=basey,
subse=subsy)
def _set_scale(self, axis, transfunc, limfunc, value, basex = 10, subsx=None):
assert(value.lower() in ('log', 'linear', ))
if value == 'log':
axis.set_major_locator(mticker.LogLocator(base))
axis.set_major_formatter(mticker.LogFormatterMathtext(base))
axis.set_minor_locator(mticker.LogLocator(base,subsx))
transfunc.set_type(mtrans.LOG10)
minx, maxx = limfunc()
if min(minx, maxx)<=0:
self.autoscale_view()
elif value == 'linear':
axis.set_major_locator(mticker.AutoLocator())
axis.set_major_formatter(mticker.ScalarFormatter())
axis.set_minor_locator(mticker.NullLocator())
axis.set_minor_formatter(mticker.NullFormatter())
transfunc.set_type( mtrans.IDENTITY )
which I definitely encourage. There may be something more elegant
than this, but we only try to be a little clever. Get too clever, and
Darren and Eric will yell at you.
|
|
From: Angel L. <an...@gm...> - 2007-07-17 15:47:27
|
Hello,
I wrote a message some weeks ago about a problem I have with pylab,
but I think I probably did not explained it very well.
I am witting a small application that use tkFileDialog to prompt user
to select a file.
Then reads it and plot the data.
I want that the user could be able to press a key and read another
file, to plot it again together with the previous one(s). The problem
is that the thee graph is not drawn until I resize the window. Even
if I use the draw() method.
Any help will be appreciated.
Thanks in advance.
Angel.
code:
import sys
import os
import time
import tkFileDialog
import pylab
pylab.hold(1)
path='E:\\Nima'
n=0
def click(event):
print 'click on: ', event.xdata, event.ydata
def keyp(event):
global path
if event.key.lower()=='o':
fin = tkFileDialog.askopenfilename(initialdir=path)
path=os.path.split(fin)[0]
plot2(fin)
def plot2(fin):
global myplot
global n
f=file(fin, 'r')
lines=f.readlines()
f.close()
X=[]
Y=[]
for line in lines[1:]:
line=line.replace(',', '.')
X.append(float(line.split('\t')[2]))
Y.append(float(line.split('\t')[5]))
l,=myplot.plot(X, Y, label=os.path.split(fin)[1])
myplot.legend()
if n==0:
print "showing..."
n=1
pylab.show()
l.set_visible(1)
myplot.draw()
if __name__=='__main__':
myplot=pylab.subplot(111)
myplot.grid()
kid=pylab.connect('key_press_event', keyp)
pylab.xlabel('Area [A2/molecule]')
pylab.ylabel('SP [mN/m]')
fin = tkFileDialog.askopenfilename(initialdir=path)
path=os.path.split(fin)[0]
plot2(fin)
|
|
From: Chris F. <lis...@ma...> - 2007-07-17 15:29:03
|
For some reason, builds from SVN dont install either pytz or dateutil (at least not in the right place). Importing pylab from these builds results in an import error. How can I build these so as to convince these modules to install correctly? Thanks. |
|
From: Ben N. <be...@re...> - 2007-07-17 15:27:02
|
Hi,
There is a difference in the behaviour of Axes.hlines() vs
Axes.vlines(), in that vlines() lets you supply scalars for ymin and
ymax, whereas hlines() doesn't (for xmin and xmax). The patch below
fixes that, and also what looks like a separate bug in vlines. There
are also other differences, around units, but I haven't worked with that
area of matplotlib so will leave that for others.
I was wondering, though, whether there'd be any support for some work
which tidied up the near-duplicate code in axes.py. I've been playing
around with an approach using python's metaclass support, which, for
example, would replace the definitions of the two near-identical
functions set_xscale() and set_yscale() with the one meta-definition:
@MC_Traited.construct_traited_variants
def set__AXISLETTER_scale(self, value, base_AXISLETTER_ = 10, subs_AXISLETTER_ = None):
"""
SET_%(axis_letter_UC)sSCALE(value, base%(axis_letter)s = 10, subs%(axis_letter)s = None)
Set the %(axis_letter)s-scaling: 'log' or 'linear'
If value is 'log', the additional kwargs have the following meaning
* base%(axis_letter)s: base of the logarithm
* subs%(axis_letter)s: a sequence of the location of the minor ticks;
None defaults to autosubs, which depend on the number of
decades in the plot. Eg for base 10, subs%(axis_letter)s = (1, 2, 5) will
put minor ticks on 1, 2, 5, 11, 12, 15, 21, ....
To turn off minor ticking, set subs%(axis_letter)s = []
ACCEPTS: ['log' | 'linear']
"""
assert(value.lower() in ('log', 'linear'))
my_axis = _TRAITS_.my_axis(self)
if value == 'log':
my_axis.set_major_locator(LogLocator(base_AXISLETTER_))
my_axis.set_major_formatter(LogFormatterMathtext(base_AXISLETTER_))
my_axis.set_minor_locator(LogLocator(base_AXISLETTER_, subs_AXISLETTER_))
_TRAITS_.get_my_func(self.transData).set_type(LOG10)
minval, maxval = _TRAITS_.get_my_lim(self)
if min(minval, maxval) <= 0:
self.autoscale_view()
elif value == 'linear':
my_axis.set_major_locator(AutoLocator())
my_axis.set_major_formatter(ScalarFormatter())
my_axis.set_minor_locator(NullLocator())
my_axis.set_minor_formatter(NullFormatter())
_TRAITS_.get_my_func(self.transData).set_type(IDENTITY)
I haven't quite worked through the details, but it looks like it would
cut nearly 400 lines off axes.py (while adding c.200 lines of supporting
code), as well as avoid the type of inconsistency seen in hlines/vlines.
If there's interest, I'll post what I've got so far for comments.
Thanks,
Ben.
- - - - 8< - - - -
--- ORIG/axes.py 2007-07-17 15:24:10.367402000 +0100
+++ NEW/axes.py 2007-07-17 15:38:03.705394000 +0100
@@ -2325,6 +2325,11 @@
xmin = asarray(xmin)
xmax = asarray(xmax)
+ if len(xmin)==1:
+ xmin = xmin*ones(y.shape, typecode(y))
+ if len(ymax)==1:
+ xmax = xmax*ones(y.shape, typecode(y))
+
if len(xmin)!=len(y):
raise ValueError, 'xmin and y are unequal sized sequences'
@@ -2418,7 +2423,7 @@
minx = nx.amin(x)
maxx = nx.amax(x)
miny = min(nx.amin(ymin), nx.amin(ymax))
- maxy = max(nx.amax(ymax), nx.amax(ymax))
+ maxy = max(nx.amax(ymin), nx.amax(ymax))
minx, maxx = self.convert_xunits((minx, maxx))
miny, maxy = self.convert_yunits((miny, maxy))
corners = (minx, miny), (maxx, maxy)
|
|
From: John H. <jd...@gm...> - 2007-07-17 15:11:27
|
On 7/17/07, Ben North <be...@re...> wrote: > Hi, > > The normal rectangular Axes class and the derived PolarAxes class both > have set_xlim() and set_ylim() functions, but the rectangular Axes class > has a default value of False for the 'emit' argument, whereas the > PolarAxes version has True. > looked at all callers of set_xlim() so I could well be missing a good > reason why this isn't currently done.) This inconsistency was never intentional, and is fixed in svn. JDH |
|
From: Michael D. <md...@st...> - 2007-07-17 15:02:38
|
I recently ran into a similar problem myself building stuff from source, but I'm not sure of the specifics with SuSE and their packages etc. Python can be configured in two ways -- with two-byte (UCS2) or four-byte (UCS4) Unicode characters. Apparently the default for a source installation of Python is UCS2, but many (most) Linux distributions build it for UCS4. Python extensions built for one configuration can not be used with a Python built for the other configuration. When Python extensions are built, if all goes well, they will match the configuration of the Python interpreter. It looks like somehow you have a mismatch between matplotlib and your Python interpreter. If you installed everything from packages, I would expect them all to match (unless SuSE's quality control has really gone down as of late ;). Perhaps something is still around from when you built things from source. Did you at any point build your own Python? On a number of Linux distributions (probably including SuSE, but I don't know for sure), things installed from source are under the /usr/local tree. To diagnose this, you could see if anything is getting pulled in from there (rather than from the packaged stuff, which wouldn't be under /usr/local). For instance "whereis python", will tell you which python is being used. When you import a Python module, you can use __file__ to see where it was imported from. For example: >>> import pylab >>> pylab.__file__ Hope that at least offers some next steps for tracking this down. Cheers, Mike mark starnes wrote: > Hi everyone, > > I'm running Suse10.2 and installing packages using Yast (after much pain > trying to install Numpy and Scipy without it!). After installing (and > re-installing) Matplotlib in this way, I get the error, > > ImportError: matplotlib/ft2font.so: undefined symbol: PyUnicodeUCS4_GetSize > > when I attempt to import pylab. > > Can anybody help me fix this? I couldn't find any help on the > matplotlib site and my .matplotlib directory is empty. > > Oh, I'm also a bit new to Linux - please be patient! > > Thanks in advance, > > Mark. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
|
From: Ben N. <be...@re...> - 2007-07-17 14:56:57
|
Hi,
The normal rectangular Axes class and the derived PolarAxes class both
have set_xlim() and set_ylim() functions, but the rectangular Axes class
has a default value of False for the 'emit' argument, whereas the
PolarAxes version has True. I had a figure containing three Axes
instances, arranged as one 'main' plot and two subsidiary plots. I
wanted the subsidiary plots to have their x- and y-limits slaved to
changes in the main plot's, but with the current default value of
'emit', I wasn't getting callbacks when I used the navigation toolbar to
pan/zoom around the main plot. Would there be any disadvantage to
changing the default value to True, as in the patch below? (I haven't
looked at all callers of set_xlim() so I could well be missing a good
reason why this isn't currently done.)
Thanks,
Ben.
- - - - 8< - - - -
--- ORIG/axes.py 2007-07-17 15:24:10.367402000 +0100
+++ NEW/axes.py 2007-07-17 15:48:28.708471000 +0100
@@ -1449,7 +1449,7 @@
return self.viewLim.intervalx().get_bounds()
- def set_xlim(self, xmin=None, xmax=None, emit=False, **kwargs):
+ def set_xlim(self, xmin=None, xmax=None, emit=True, **kwargs):
"""
set_xlim(self, *args, **kwargs):
@@ -1573,7 +1573,7 @@
'Get the y axis range [ymin, ymax]'
return self.viewLim.intervaly().get_bounds()
- def set_ylim(self, ymin=None, ymax=None, emit=False, **kwargs):
+ def set_ylim(self, ymin=None, ymax=None, emit=True, **kwargs):
"""
set_ylim(self, *args, **kwargs):
|
|
From: mark s. <m.s...@im...> - 2007-07-17 14:22:15
|
Hi everyone, I'm running Suse10.2 and installing packages using Yast (after much pain trying to install Numpy and Scipy without it!). After installing (and re-installing) Matplotlib in this way, I get the error, ImportError: matplotlib/ft2font.so: undefined symbol: PyUnicodeUCS4_GetSize when I attempt to import pylab. Can anybody help me fix this? I couldn't find any help on the matplotlib site and my .matplotlib directory is empty. Oh, I'm also a bit new to Linux - please be patient! Thanks in advance, Mark. |
|
From: Angel L. <an...@gm...> - 2007-07-17 10:20:21
|
Hello,
I wrote a message some weeks ago about a problem I have with pylab,
but I think I probably did not explained it very well.
I am witting a small application that use tkFileDialog to prompt user
to select a file.
Then reads it and plot the data.
I want that the user could be able to press a key and read another
file, to plot it again together with the previous one(s). The problem
is that the thee graph is not drawn until I resize the window. Even
if I use the draw() method.
Any help will be appreciated.
Thanks in advance.
Angel.
code:
import sys
import os
import time
import tkFileDialog
import pylab
pylab.hold(1)
path='E:\\Nima'
n=0
def click(event):
print 'click on: ', event.xdata, event.ydata
def keyp(event):
global path
if event.key.lower()=='o':
fin = tkFileDialog.askopenfilename(initialdir=path)
path=os.path.split(fin)[0]
plot2(fin)
def plot2(fin):
global myplot
global n
f=file(fin, 'r')
lines=f.readlines()
f.close()
X=[]
Y=[]
for line in lines[1:]:
line=line.replace(',', '.')
X.append(float(line.split('\t')[2]))
Y.append(float(line.split('\t')[5]))
l,=myplot.plot(X, Y, label=os.path.split(fin)[1])
myplot.legend()
if n==0:
print "showing..."
n=1
pylab.show()
l.set_visible(1)
myplot.draw()
if __name__=='__main__':
myplot=pylab.subplot(111)
myplot.grid()
kid=pylab.connect('key_press_event', keyp)
pylab.xlabel('Area [A2/molecule]')
pylab.ylabel('SP [mN/m]')
fin = tkFileDialog.askopenfilename(initialdir=path)
path=os.path.split(fin)[0]
plot2(fin)
|
|
From: Andrew S. <str...@as...> - 2007-07-17 10:10:28
|
Thanks for tracking this down, Ben. Applied in svn as r3547. Ben North wrote: > I've been using matplotlib for a little while and am finding it very > useful. Yesterday, though, I hit a problem: |
|
From: Ben N. <be...@re...> - 2007-07-17 09:35:11
|
Hi,
I've been using matplotlib for a little while and am finding it very
useful. Yesterday, though, I hit a problem:
Because I didn't read the docs properly, I tried to use
matplotlib.transforms.scale_transform
like this:
t = scale_transform(1.0, 2.0)
but then I got a core-dump when trying to use it:
from matplotlib.transforms import scale_transform
t = scale_transform(1.0, 2.0)
print t.xy_tup((1.0, 0.2))
What I should have done was this, which works:
from matplotlib.transforms import scale_transform, Value
t = scale_transform(Value(1.0), Value(2.0))
print t.xy_tup((1.0, 0.2))
The function _transforms_module::new_affine() in _transforms.cpp does
contain checks that its args are LazyValue objects, but it seems to
ignore the results. The following patch (against 0.90.1) makes the
constructor throw a TypeError if it doesn't get what it wants. (It also
fixes a small typo in a separate error string.)
--- ORIG/_transforms.cpp 2007-07-17 10:10:37.443202000 +0100
+++ NEW/_transforms.cpp 2007-07-17 10:11:00.257365000 +0100
@@ -42,7 +42,7 @@
int
LazyValue::compare(const Py::Object &other) {
if (!check(other))
- throw Py::TypeError("Can on compare LazyValues with LazyValues");
+ throw Py::TypeError("Can only compare LazyValues with LazyValues");
LazyValue* pother = static_cast<LazyValue*>(other.ptr());
double valself = val();
double valother = pother->val();
@@ -2116,12 +2116,13 @@
args.verify_length(6);
- LazyValue::check(args[0]);
- LazyValue::check(args[1]);
- LazyValue::check(args[2]);
- LazyValue::check(args[3]);
- LazyValue::check(args[4]);
- LazyValue::check(args[5]);
+ if (!LazyValue::check(args[0])
+ || !LazyValue::check(args[1])
+ || !LazyValue::check(args[2])
+ || !LazyValue::check(args[3])
+ || !LazyValue::check(args[4])
+ || !LazyValue::check(args[5]))
+ throw Py::TypeError("Affine(a, b, c, d, tx, ty) expected 6 LazyValue args");
LazyValue* a = static_cast<LazyValue*>(args[0].ptr());
LazyValue* b = static_cast<LazyValue*>(args[1].ptr());
Would this be worth applying? By the look of the code in transform.py,
translation_transform() and possibly others might be affected by this
too. Maybe a better solution might be to automatically construct Value
objects from Python floats where required, but that might need a bit
more thought.
Ben.
|