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) |
|
|
|
|
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 >>> >>> >>
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 >>> >> >
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.
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)
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 >> > >
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 >
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
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. >
You can do it this way: data = array(data) x = arange(len(data)) plot(x[data!=0], data[data!=0]) Regards, ~ Antonio
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])
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 > >
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.
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
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
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.
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)
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.
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)
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
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 >
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):
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.
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)
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:
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.