You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(20) |
2
(21) |
3
(21) |
4
(14) |
5
(8) |
6
(12) |
7
(16) |
8
(27) |
9
(39) |
10
(19) |
11
(12) |
12
(3) |
13
(3) |
14
(18) |
15
(14) |
16
(6) |
17
(7) |
18
(19) |
19
(5) |
20
(8) |
21
(24) |
22
(42) |
23
(12) |
24
(11) |
25
(16) |
26
(2) |
27
(4) |
28
(10) |
|
|
|
|
|
From: Eric F. <ef...@ha...> - 2011-02-04 23:29:21
|
On 02/04/2011 12:33 PM, Christoph Gohlke wrote: > > > On 2/4/2011 2:14 PM, Eric Firing wrote: >> On 02/04/2011 11:33 AM, Eric Firing wrote: >>> On 02/04/2011 10:28 AM, Christoph Gohlke wrote: >>>> >>>> >>>> On 2/4/2011 11:54 AM, Eric Firing wrote: >>>>> On 02/03/2011 05:35 PM, Christoph Gohlke wrote: >>>>>> >>>>>> >>>>>> On 2/3/2011 6:50 PM, Eric Firing wrote: >>>>>>> On 02/03/2011 03:04 PM, Benjamin Root wrote: >>>>>>> >>>>>>>> Also, not to sound too annoying, but has anyone considered the idea of >>>>>>>> using compressed arrays for holding those rgba values? >>>>>>> >>>>>>> I don't see how that really helps; as far as I know, a full rgba array >>>>>>> has to be passed into agg. What *does* help is using uint8 from start >>>>>>> to finish. It might also be possible to use some smart downsampling >>>>>>> before generating the rgba array, but the uint8 route seems to me the >>>>>>> first thing to attack. >>>>>>> >>>>>>> Eric >>>>>>> >>>>>>>> >>>>>>>> Ben Root >>>>>>> >>>>>> >>>>>> Please review the attached patch. It avoids generating and storing >>>>>> float64 rgba arrays and uses uint8 rgba instead. That's a huge memory >>>>>> saving and also faster. I can't see any side effects as >>>>>> _image.fromarray() converts the float64 input to uint8 anyway. >>>>> >>>>> Christoph, >>>>> >>>>> Thank you! I haven't found anything wrong with that delightfully simple >>>>> patch, so I have committed it to the trunk. Back in 2007 I added the >>>>> ability of colormapping to generate uint8 directly, precisely to enable >>>>> this sort of optimization. Why it was not already being used in imshow, >>>>> I don't know--maybe I was going to do it, got sidetracked, and never >>>>> finished. >>>>> >>>>> I suspect it won't be as simple as for the plain image, but there may be >>>>> opportunities for optimizing with uint8 in other image-like operations. >>>>> >>>>>> >>>>>> So far other attempts to optimize memory usage were thwarted by >>>>>> matplotlib's internal use of masked arrays. As mentioned before, users >>>>>> can provide their own normalized rgba arrays to avoid all this processing. >>>>>> >>>>> >>>>> Did you see other potential low-hanging fruit that might be harvested >>>>> with some changes to the code associated with masked arrays? >>>>> >>>>> Eric >>>>> >>>> >>>> The norm function currently converts the data to double precision >>>> floating point and also creates temporary arrays that can be avoided. >>>> For float32 and low precision integer images this seems overkill and one >>>> could use float32. It might be possible to replace the norm function >>>> with numpy.digitize if that works with masked arrays. Last, the >>>> _image.frombyte function does a copy of 'strided arrays' (only relevant >>>> when zooming/panning large images). I try to provide a patch for each. >>> >>> masked arrays can be filled to create an ndarray before passing to >>> digitize; whether that will be faster, remains to be seen. I've never >>> used digitize. >> >> I didn't say that ("can be filled...") right. I think one would need to >> use the mask to put in the i_bad index where appropriate. np.ma does >> not have a digitize function. I suspect it won't help much if at all in >> Normalize, but it would be a natural for use in BoundaryNorm. >> >> It looks easy to allow Normalize.__call__ to use float32 if that is what >> it receives. >> >> I don't see any unnecessary temporary array creation apart from the >> conversion to float64, except for the generation of a masked array >> regardless of input. I don't think this costs much; if it gets an >> ndarray it does not copy it, and it does not generate a full mask array. >> Still, the function probably could be sped up a bit by handling >> masking more explicitly instead of letting ma do the work. >> > > In class Normalize: > result = 0.0 * val > and > result = (val-vmin) / (vmax-vmin) > >> Eric >> >>> >>> Regarding frombyte, I suspect you can't avoid the copy; the data >>> structure being passed to agg is just a string of bytes, as far as I can >>> see, so everything is based on having a simple contiguous array. >>> > > The PyArray_ContiguousFromObject call will return a copy if the input > array is not already contiguous. Exactly. I thought you were suggesting that this was not needed, but maybe I misunderstood. Eric > > Christoph > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Christoph G. <cg...@uc...> - 2011-02-04 22:34:06
|
On 2/4/2011 2:14 PM, Eric Firing wrote: > On 02/04/2011 11:33 AM, Eric Firing wrote: >> On 02/04/2011 10:28 AM, Christoph Gohlke wrote: >>> >>> >>> On 2/4/2011 11:54 AM, Eric Firing wrote: >>>> On 02/03/2011 05:35 PM, Christoph Gohlke wrote: >>>>> >>>>> >>>>> On 2/3/2011 6:50 PM, Eric Firing wrote: >>>>>> On 02/03/2011 03:04 PM, Benjamin Root wrote: >>>>>> >>>>>>> Also, not to sound too annoying, but has anyone considered the idea of >>>>>>> using compressed arrays for holding those rgba values? >>>>>> >>>>>> I don't see how that really helps; as far as I know, a full rgba array >>>>>> has to be passed into agg. What *does* help is using uint8 from start >>>>>> to finish. It might also be possible to use some smart downsampling >>>>>> before generating the rgba array, but the uint8 route seems to me the >>>>>> first thing to attack. >>>>>> >>>>>> Eric >>>>>> >>>>>>> >>>>>>> Ben Root >>>>>> >>>>> >>>>> Please review the attached patch. It avoids generating and storing >>>>> float64 rgba arrays and uses uint8 rgba instead. That's a huge memory >>>>> saving and also faster. I can't see any side effects as >>>>> _image.fromarray() converts the float64 input to uint8 anyway. >>>> >>>> Christoph, >>>> >>>> Thank you! I haven't found anything wrong with that delightfully simple >>>> patch, so I have committed it to the trunk. Back in 2007 I added the >>>> ability of colormapping to generate uint8 directly, precisely to enable >>>> this sort of optimization. Why it was not already being used in imshow, >>>> I don't know--maybe I was going to do it, got sidetracked, and never >>>> finished. >>>> >>>> I suspect it won't be as simple as for the plain image, but there may be >>>> opportunities for optimizing with uint8 in other image-like operations. >>>> >>>>> >>>>> So far other attempts to optimize memory usage were thwarted by >>>>> matplotlib's internal use of masked arrays. As mentioned before, users >>>>> can provide their own normalized rgba arrays to avoid all this processing. >>>>> >>>> >>>> Did you see other potential low-hanging fruit that might be harvested >>>> with some changes to the code associated with masked arrays? >>>> >>>> Eric >>>> >>> >>> The norm function currently converts the data to double precision >>> floating point and also creates temporary arrays that can be avoided. >>> For float32 and low precision integer images this seems overkill and one >>> could use float32. It might be possible to replace the norm function >>> with numpy.digitize if that works with masked arrays. Last, the >>> _image.frombyte function does a copy of 'strided arrays' (only relevant >>> when zooming/panning large images). I try to provide a patch for each. >> >> masked arrays can be filled to create an ndarray before passing to >> digitize; whether that will be faster, remains to be seen. I've never >> used digitize. > > I didn't say that ("can be filled...") right. I think one would need to > use the mask to put in the i_bad index where appropriate. np.ma does > not have a digitize function. I suspect it won't help much if at all in > Normalize, but it would be a natural for use in BoundaryNorm. > > It looks easy to allow Normalize.__call__ to use float32 if that is what > it receives. > > I don't see any unnecessary temporary array creation apart from the > conversion to float64, except for the generation of a masked array > regardless of input. I don't think this costs much; if it gets an > ndarray it does not copy it, and it does not generate a full mask array. > Still, the function probably could be sped up a bit by handling > masking more explicitly instead of letting ma do the work. > In class Normalize: result = 0.0 * val and result = (val-vmin) / (vmax-vmin) > Eric > >> >> Regarding frombyte, I suspect you can't avoid the copy; the data >> structure being passed to agg is just a string of bytes, as far as I can >> see, so everything is based on having a simple contiguous array. >> The PyArray_ContiguousFromObject call will return a copy if the input array is not already contiguous. Christoph |
From: Eric F. <ef...@ha...> - 2011-02-04 22:15:05
|
On 02/04/2011 11:33 AM, Eric Firing wrote: > On 02/04/2011 10:28 AM, Christoph Gohlke wrote: >> >> >> On 2/4/2011 11:54 AM, Eric Firing wrote: >>> On 02/03/2011 05:35 PM, Christoph Gohlke wrote: >>>> >>>> >>>> On 2/3/2011 6:50 PM, Eric Firing wrote: >>>>> On 02/03/2011 03:04 PM, Benjamin Root wrote: >>>>> >>>>>> Also, not to sound too annoying, but has anyone considered the idea of >>>>>> using compressed arrays for holding those rgba values? >>>>> >>>>> I don't see how that really helps; as far as I know, a full rgba array >>>>> has to be passed into agg. What *does* help is using uint8 from start >>>>> to finish. It might also be possible to use some smart downsampling >>>>> before generating the rgba array, but the uint8 route seems to me the >>>>> first thing to attack. >>>>> >>>>> Eric >>>>> >>>>>> >>>>>> Ben Root >>>>> >>>> >>>> Please review the attached patch. It avoids generating and storing >>>> float64 rgba arrays and uses uint8 rgba instead. That's a huge memory >>>> saving and also faster. I can't see any side effects as >>>> _image.fromarray() converts the float64 input to uint8 anyway. >>> >>> Christoph, >>> >>> Thank you! I haven't found anything wrong with that delightfully simple >>> patch, so I have committed it to the trunk. Back in 2007 I added the >>> ability of colormapping to generate uint8 directly, precisely to enable >>> this sort of optimization. Why it was not already being used in imshow, >>> I don't know--maybe I was going to do it, got sidetracked, and never >>> finished. >>> >>> I suspect it won't be as simple as for the plain image, but there may be >>> opportunities for optimizing with uint8 in other image-like operations. >>> >>>> >>>> So far other attempts to optimize memory usage were thwarted by >>>> matplotlib's internal use of masked arrays. As mentioned before, users >>>> can provide their own normalized rgba arrays to avoid all this processing. >>>> >>> >>> Did you see other potential low-hanging fruit that might be harvested >>> with some changes to the code associated with masked arrays? >>> >>> Eric >>> >> >> The norm function currently converts the data to double precision >> floating point and also creates temporary arrays that can be avoided. >> For float32 and low precision integer images this seems overkill and one >> could use float32. It might be possible to replace the norm function >> with numpy.digitize if that works with masked arrays. Last, the >> _image.frombyte function does a copy of 'strided arrays' (only relevant >> when zooming/panning large images). I try to provide a patch for each. > > masked arrays can be filled to create an ndarray before passing to > digitize; whether that will be faster, remains to be seen. I've never > used digitize. I didn't say that ("can be filled...") right. I think one would need to use the mask to put in the i_bad index where appropriate. np.ma does not have a digitize function. I suspect it won't help much if at all in Normalize, but it would be a natural for use in BoundaryNorm. It looks easy to allow Normalize.__call__ to use float32 if that is what it receives. I don't see any unnecessary temporary array creation apart from the conversion to float64, except for the generation of a masked array regardless of input. I don't think this costs much; if it gets an ndarray it does not copy it, and it does not generate a full mask array. Still, the function probably could be sped up a bit by handling masking more explicitly instead of letting ma do the work. Eric > > Regarding frombyte, I suspect you can't avoid the copy; the data > structure being passed to agg is just a string of bytes, as far as I can > see, so everything is based on having a simple contiguous array. > > Eric > >> >> Christoph >> |
From: Eric F. <ef...@ha...> - 2011-02-04 21:33:58
|
On 02/04/2011 10:28 AM, Christoph Gohlke wrote: > > > On 2/4/2011 11:54 AM, Eric Firing wrote: >> On 02/03/2011 05:35 PM, Christoph Gohlke wrote: >>> >>> >>> On 2/3/2011 6:50 PM, Eric Firing wrote: >>>> On 02/03/2011 03:04 PM, Benjamin Root wrote: >>>> >>>>> Also, not to sound too annoying, but has anyone considered the idea of >>>>> using compressed arrays for holding those rgba values? >>>> >>>> I don't see how that really helps; as far as I know, a full rgba array >>>> has to be passed into agg. What *does* help is using uint8 from start >>>> to finish. It might also be possible to use some smart downsampling >>>> before generating the rgba array, but the uint8 route seems to me the >>>> first thing to attack. >>>> >>>> Eric >>>> >>>>> >>>>> Ben Root >>>> >>> >>> Please review the attached patch. It avoids generating and storing >>> float64 rgba arrays and uses uint8 rgba instead. That's a huge memory >>> saving and also faster. I can't see any side effects as >>> _image.fromarray() converts the float64 input to uint8 anyway. >> >> Christoph, >> >> Thank you! I haven't found anything wrong with that delightfully simple >> patch, so I have committed it to the trunk. Back in 2007 I added the >> ability of colormapping to generate uint8 directly, precisely to enable >> this sort of optimization. Why it was not already being used in imshow, >> I don't know--maybe I was going to do it, got sidetracked, and never >> finished. >> >> I suspect it won't be as simple as for the plain image, but there may be >> opportunities for optimizing with uint8 in other image-like operations. >> >>> >>> So far other attempts to optimize memory usage were thwarted by >>> matplotlib's internal use of masked arrays. As mentioned before, users >>> can provide their own normalized rgba arrays to avoid all this processing. >>> >> >> Did you see other potential low-hanging fruit that might be harvested >> with some changes to the code associated with masked arrays? >> >> Eric >> > > The norm function currently converts the data to double precision > floating point and also creates temporary arrays that can be avoided. > For float32 and low precision integer images this seems overkill and one > could use float32. It might be possible to replace the norm function > with numpy.digitize if that works with masked arrays. Last, the > _image.frombyte function does a copy of 'strided arrays' (only relevant > when zooming/panning large images). I try to provide a patch for each. masked arrays can be filled to create an ndarray before passing to digitize; whether that will be faster, remains to be seen. I've never used digitize. Regarding frombyte, I suspect you can't avoid the copy; the data structure being passed to agg is just a string of bytes, as far as I can see, so everything is based on having a simple contiguous array. Eric > > Christoph > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Christoph G. <cg...@uc...> - 2011-02-04 20:29:01
|
On 2/4/2011 11:54 AM, Eric Firing wrote: > On 02/03/2011 05:35 PM, Christoph Gohlke wrote: >> >> >> On 2/3/2011 6:50 PM, Eric Firing wrote: >>> On 02/03/2011 03:04 PM, Benjamin Root wrote: >>> >>>> Also, not to sound too annoying, but has anyone considered the idea of >>>> using compressed arrays for holding those rgba values? >>> >>> I don't see how that really helps; as far as I know, a full rgba array >>> has to be passed into agg. What *does* help is using uint8 from start >>> to finish. It might also be possible to use some smart downsampling >>> before generating the rgba array, but the uint8 route seems to me the >>> first thing to attack. >>> >>> Eric >>> >>>> >>>> Ben Root >>> >> >> Please review the attached patch. It avoids generating and storing >> float64 rgba arrays and uses uint8 rgba instead. That's a huge memory >> saving and also faster. I can't see any side effects as >> _image.fromarray() converts the float64 input to uint8 anyway. > > Christoph, > > Thank you! I haven't found anything wrong with that delightfully simple > patch, so I have committed it to the trunk. Back in 2007 I added the > ability of colormapping to generate uint8 directly, precisely to enable > this sort of optimization. Why it was not already being used in imshow, > I don't know--maybe I was going to do it, got sidetracked, and never > finished. > > I suspect it won't be as simple as for the plain image, but there may be > opportunities for optimizing with uint8 in other image-like operations. > >> >> So far other attempts to optimize memory usage were thwarted by >> matplotlib's internal use of masked arrays. As mentioned before, users >> can provide their own normalized rgba arrays to avoid all this processing. >> > > Did you see other potential low-hanging fruit that might be harvested > with some changes to the code associated with masked arrays? > > Eric > The norm function currently converts the data to double precision floating point and also creates temporary arrays that can be avoided. For float32 and low precision integer images this seems overkill and one could use float32. It might be possible to replace the norm function with numpy.digitize if that works with masked arrays. Last, the _image.frombyte function does a copy of 'strided arrays' (only relevant when zooming/panning large images). I try to provide a patch for each. Christoph |
From: Eric F. <ef...@ha...> - 2011-02-04 19:54:56
|
On 02/03/2011 05:35 PM, Christoph Gohlke wrote: > > > On 2/3/2011 6:50 PM, Eric Firing wrote: >> On 02/03/2011 03:04 PM, Benjamin Root wrote: >> >>> Also, not to sound too annoying, but has anyone considered the idea of >>> using compressed arrays for holding those rgba values? >> >> I don't see how that really helps; as far as I know, a full rgba array >> has to be passed into agg. What *does* help is using uint8 from start >> to finish. It might also be possible to use some smart downsampling >> before generating the rgba array, but the uint8 route seems to me the >> first thing to attack. >> >> Eric >> >>> >>> Ben Root >> > > Please review the attached patch. It avoids generating and storing > float64 rgba arrays and uses uint8 rgba instead. That's a huge memory > saving and also faster. I can't see any side effects as > _image.fromarray() converts the float64 input to uint8 anyway. Christoph, Thank you! I haven't found anything wrong with that delightfully simple patch, so I have committed it to the trunk. Back in 2007 I added the ability of colormapping to generate uint8 directly, precisely to enable this sort of optimization. Why it was not already being used in imshow, I don't know--maybe I was going to do it, got sidetracked, and never finished. I suspect it won't be as simple as for the plain image, but there may be opportunities for optimizing with uint8 in other image-like operations. > > So far other attempts to optimize memory usage were thwarted by > matplotlib's internal use of masked arrays. As mentioned before, users > can provide their own normalized rgba arrays to avoid all this processing. > Did you see other potential low-hanging fruit that might be harvested with some changes to the code associated with masked arrays? Eric > Christoph |
From: Francesco M. <fra...@go...> - 2011-02-04 16:01:44
|
Dear all again, I've tried to play with it again, but I couldn't find a solution for the problem. For clarity I report an example of what each of the subplots looks like: > import numpy as np > import matplotlib.pyplot as plt > mean = np.array([-0.9206394, -0.90127456, -0.91983625, -0.97765539, -1.02991184, -1.02267017, -0.97730167, -0.93715172, -0.94324653, -0.92884379]) > stddev = np.array([0.16351397, 0.15075966, 0.13413909, 0.15404823, 0.13559582, 0.13109754, 0.12128598, 0.11589682, 0.11921571, 0.10866761]) > > ax = plt.figure().add_axes([0.1,0.1,0.8,0.8]) > ax.errorbar(np.arange(10,20)/100., mean, yerr=stddev) > > ax.set_xlim([0.095, 0.195]) > lab = ax.get_ymajorticklabels() > > print lab > for i in lab: > print i > > plt.show() as output of this script I get > <a list of 7 Text yticklabel objects> > Text(0,0,'') > Text(0,0,'') > Text(0,0,'') > Text(0,0,'') > Text(0,0,'') > Text(0,0,'') > Text(0,0,'') In the plot instead I only have only 5 y tick labels, as visible from the attachment. In this case if I set the first and the last label invisible, nothing changes, and if I have other plots under this the plot becomes ugly/unreadable. I hope to have been clearer than in my previous mail. Any suggestion on how to fix or find a workaround in order to get the same number of tick labels as the ones actually plotted. Thank in advance Fra 2011/2/1 Francesco Montesano <fra...@go...>: > Dear all, > > I'm producing a single figure with subplots arrange in a single columns. > They all share the same x range but the y variable change from subplot to > subplot > > In order have a nicer figure I hide the first and the last y label of each > subplot in the following way >> >> ytl = subpl.get_ymajorticklabels() >> ytl[0].set_visible(False) >> ytl[-1].set_visible(False) > > It was well in most cases. But I've noticed that in some plot the first > and/or the last label remains. > In this cases, if I "print ytl", it writes "<a list of n Text yticklabel > objects>", where "n" is larger by 1 or 2 than the number of labels shown > before I make them invisible. > So I end up having some label (nearly) exactly on the upper and/or bottom > range of the plot. > > Is there a way to force the axis to return exactly the number of labels > shown in the plot? > > Thanks in advance, > > Francesco > > > -- personals: mon...@ya..., mon...@ho... (messenger), fra...@go.... work: mon...@mp... http://picasaweb.google.it/franz.bergesund |
From: Pauli V. <pa...@ik...> - 2011-02-04 10:07:28
|
Thu, 03 Feb 2011 16:37:31 -0800, Christoph Gohlke wrote: [clip] > My understanding is that if there is a circular reference then the > refcount will not be zero anyway. In this case _AxesImageBase instances > and their image caches will never be deleted by the gc (__del__ method > present or not) unless the circle is broken. Python's GC will try to break the cycles if possible. In fact, there's no other need for a GC in a reference counted system. http://docs.python.org/extending/extending.html#reference-counts -- Pauli Virtanen |
From: Jason G. <jas...@cr...> - 2011-02-04 04:16:14
|
On 2/2/11 8:51 AM, Francois Maltey wrote: > Hello, > > I use matplolib by the mathematical system Sage in order to plot a function. > The Sage code calls matplotlib and uses its options : The Sage command is > > plot (sin, x, -5, 5) > > I add labels par axes_labels or remove axes by : > > plot (sin(x), x, -5, 5, axes_label = ['x', 'y']) > plot (sin(x), x, -5, 5, axes=false) > > French users (and maybe others) uses arrows and not lines for axes. > I'm looking for a plot (sin(x), x, -5, 5, axes="arrows") > Is there a pretty way to get these arrows. The result of this code isn't > so fine. > length, width and color don't match. > > plot (sin(x), x, -5, 5, axes=false) + arrow ((-5,0),(5,0)) + arrow > ((0,-1),(0,1)) > > What options do you propose ? I've made a Sage ticket for this: http://trac.sagemath.org/sage_trac/ticket/10740 As a clumsy workaround, you could use the .matplotlib() method for Sage graphics objects to get the matplotlib figure object for the graphics object. Then you could: 1. figure out which spine was being used as the drawn axes 2. use that spine's transform to place an arrow at the end of the spine (using the example code that was just posted in another message to draw the arrow). 3. Draw the figure Thanks, Jason |
From: Christoph G. <cg...@uc...> - 2011-02-04 03:36:25
|
On 2/3/2011 6:50 PM, Eric Firing wrote: > On 02/03/2011 03:04 PM, Benjamin Root wrote: > >> Also, not to sound too annoying, but has anyone considered the idea of >> using compressed arrays for holding those rgba values? > > I don't see how that really helps; as far as I know, a full rgba array > has to be passed into agg. What *does* help is using uint8 from start > to finish. It might also be possible to use some smart downsampling > before generating the rgba array, but the uint8 route seems to me the > first thing to attack. > > Eric > >> >> Ben Root > Please review the attached patch. It avoids generating and storing float64 rgba arrays and uses uint8 rgba instead. That's a huge memory saving and also faster. I can't see any side effects as _image.fromarray() converts the float64 input to uint8 anyway. So far other attempts to optimize memory usage were thwarted by matplotlib's internal use of masked arrays. As mentioned before, users can provide their own normalized rgba arrays to avoid all this processing. Christoph |
From: Eric F. <ef...@ha...> - 2011-02-04 02:51:20
|
On 02/03/2011 03:04 PM, Benjamin Root wrote: > Also, not to sound too annoying, but has anyone considered the idea of > using compressed arrays for holding those rgba values? I don't see how that really helps; as far as I know, a full rgba array has to be passed into agg. What *does* help is using uint8 from start to finish. It might also be possible to use some smart downsampling before generating the rgba array, but the uint8 route seems to me the first thing to attack. Eric > > Ben Root |
From: Paul I. <piv...@gm...> - 2011-02-04 02:23:33
|
From: Paul Ivanov <piv...@gm...> To: Francois Maltey <fm...@ne...> Cc: cc: Subject: Re: [Matplotlib-users] Is it possible to plot axes with arrows ? Reply-To: In-Reply-To: <4D4...@ne...> X-PGP-Key: http://pirsquared.org/PaulIvanov0F3E28F7.asc Francois Maltey, on 2011-02-02 15:51, wrote: > Hello, > > I use matplolib by the mathematical system Sage in order to plot a function. > The Sage code calls matplotlib and uses its options : The Sage command is > > plot (sin, x, -5, 5) > > I add labels par axes_labels or remove axes by : > > plot (sin(x), x, -5, 5, axes_label = ['x', 'y']) > plot (sin(x), x, -5, 5, axes=false) > > French users (and maybe others) uses arrows and not lines for axes. > I'm looking for a plot (sin(x), x, -5, 5, axes="arrows") > Is there a pretty way to get these arrows. The result of this code isn't > so fine. > length, width and color don't match. > > plot (sin(x), x, -5, 5, axes=false) + arrow ((-5,0),(5,0)) + arrow > ((0,-1),(0,1)) > > What options do you propose ? > I don't find relevant answers in the archive. Hi Francois, I'm not sure I understand - but do you want the arrows at the end of the axes spines? I don't think there's a direct way to adjust the spines to become arrows at the moment, but we can remedy that by making annotations in axes coordinates. The important thing to know here is that in axes coordinates, which are always between 0-1, spine endpoints are at these locations: (0,0), (0,1), (1,0), and (1,1). Here's the code, and attached is the resulting image import matplotlib.pyplot as plt ax = plt.subplot(1,1,1) al = 7 # arrow length in points arrowprops=dict(clip_on=False, # plotting outside axes on purpose frac=1., # make end arrowhead the whole size of arrow headwidth=al, # in points facecolor='k') kwargs = dict( xycoords='axes fraction', textcoords='offset points', arrowprops= arrowprops, ) ax.annotate("",(1,0),xytext=(-al,0), **kwargs) # bottom spine arrow ax.annotate("",(0,1),xytext=(0,-al), **kwargs) # left spin arrow # hide the top and right spines [sp.set_visible(False) for sp in ax.spines['top'],ax.spines['right']] #hide the right and top tick marks ax.yaxis.tick_left() ax.xaxis.tick_bottom() x = np.linspace(-5,5,50) ax.plot(x, np.sin(x)) # adjust the view a little bit ax.set_xlim(-5,5) ax.set_ylim(-1.1,1.1) plt.draw() I'm not familiar with how SAGE exposes matplotlib functionality, though, since the syntax you used differs from how matplotlib is utilized. best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 |
From: Benjamin R. <ben...@ou...> - 2011-02-04 01:04:47
|
On Thu, Feb 3, 2011 at 6:37 PM, Christoph Gohlke <cg...@uc...> wrote: > > > On 2/3/2011 3:13 PM, Eric Firing wrote: > > On 02/03/2011 01:02 PM, Christoph Gohlke wrote: > >> > >> > >> On 2/3/2011 2:44 PM, Eric Firing wrote: > >>> On 02/03/2011 12:28 PM, Christoph Gohlke wrote: > >>>> > >>>> > >>>> On 2/3/2011 2:15 PM, Eric Firing wrote: > >>>>> On 02/03/2011 11:30 AM, Robert Abiad wrote: > >>>>>> On 2/3/2011 10:06 AM, Eric Firing wrote: > >>>>>>> On 02/02/2011 10:17 PM, Eric Firing wrote: > >>>>>>>> On 02/02/2011 08:38 PM, Robert Abiad wrote: > >>>>>>>>> > >>>>>>>> [...] > >>>>>>>>> I'll put it in as an enhancement, but I'm still unsure if there > is a > >>>>>>>>> bug in > >>>>>>>>> there as well. Is there something I should be doing to clear > memory > >>>>>>>>> after the > >>>>>>>>> first figure is closed other than close()? I don't understand why > >>>>>>>>> memory usage > >>>>>>>>> grows each time I replot, but I'm pretty sure it isn't desireable > >>>>>>>>> behavior. As > >>>>>>>>> I mentioned, this effect is worse with plot. > >>>>>>>>> > >>>>>>>>> So is this a bug or improper usage? > >>>>>>>> > >>>>>>>> I'm not quite sure, but I don't think there is a specifically > >>>>>>>> matplotlib > >>>>>>>> memory leak bug at work here. Are you using ipython, and if so, > have > >>>>>>>> you > >>>>>>>> turned off the caching? In its default mode, ipython keeps lots of > >>>>>>>> references, thereby keeping memory in use. Also, memory management > and > >>>>>>>> reporting can be a bit tricky and misleading. > >>>>>>>> > >>>>>>>> Nevertheless, the attached script may be illustrating the problem. > Try > >>>>>>>> running it from the command line as-is (maybe shorten the loop--it > >>>>>>>> doesn't take 100 iterations to show the pattern) and then > commenting > >>>>>>>> out > >>>>>>>> the line as indicated in the comment. It seems that if anything is > done > >>>>>>>> that adds ever so slightly to memory use while the figure is > displayed, > >>>>>>>> then when the figure is closed, its memory is not reused. I'm > puzzled. > >>>>>>> > >>>>>>> I wasn't thinking straight--there is no mystery and no memory leak. > >>>>>>> Ignore my example script referred to above. It was saving rows of > the z > >>>>>>> array, not single elements as I had intended, so of course memory > use > >>>>>>> was growing substantially. > >>>>>>> > >>>>>>> Eric > >>>>>>> > >>>>>> > >>>>>> You may not see a memory leak, but I still can't get my memory back > >>>>>> without killing python. I > >>>>>> turned off the ipython caching and even ran without iPython on both > >>>>>> Windows and Ubuntu, but when I > >>>>>> use imshow(), followed by close('all') and another imshow(), I run > out > >>>>>> of memory. I can see from > >>>>>> the OS that the memory does not come back after close() and that it > >>>>>> grows after the second imshow(). > >>>>>> > >>>>>> Any other ideas? Looks like a bug to me otherwise. > >>>>> > >>>>> Except that I tried the same things and did not get quite the same > >>>>> result. Let's track this down. Please try the attached script, and > see > >>>>> if the memory usage grows substantially, or just oscillates a bit. > >>>>> > >>>>> Eric > >>>>> > >>>> > >>>> > >>>> One thing I noticed is that if I add a "def __del__(self): print > 'del'" > >>>> to image._AxesImageBase, it never gets called. _AxesImageBase keeps > >>>> float64 and uint8 rgba images in a cache, which is never freed. > >>> > >>> Adding a __del__ method defeats (or blocks) the garbage collection. > >>> > >> > >> Sorry, never heard of that. I thought __del__() is called when the > >> reference count reaches 0. > > > > It is, but if there are circular reference chains (cycles--and mpl is > > full of them) then the garbage collector has to identify them and remove > > them. If it encounters a __del__ it stops and leaves that cycle alone. > > > > My understanding is that if there is a circular reference then the > refcount will not be zero anyway. In this case _AxesImageBase instances > and their image caches will never be deleted by the gc (__del__ method > present or not) unless the circle is broken. When the interpreter quits > things are deleted by other means. I don't know matplotlib code good > enough to fix this and will instead work on reducing the memory overhead > needed to plot an image. In the meantime it could help to explicitly > delete the image cache when a plot closes or to avoid caching altogether. > > Christoph > > Just to clarify the circular reference paradox. The garbage collector will pick it up because it is using weak refs instead of regular references. So, when a circular reference occurs, but is not hard ref-ed to anything, then it is "detached" and the gc picks it up. I am not very familiar on this concept in particular, but I do remember it being explained this way. Anyone who is more knowledgeable about this, I would welcome further comment or corrections to what I remember. Also, not to sound too annoying, but has anyone considered the idea of using compressed arrays for holding those rgba values? Ben Root |
From: Christoph G. <cg...@uc...> - 2011-02-04 00:38:07
|
On 2/3/2011 3:13 PM, Eric Firing wrote: > On 02/03/2011 01:02 PM, Christoph Gohlke wrote: >> >> >> On 2/3/2011 2:44 PM, Eric Firing wrote: >>> On 02/03/2011 12:28 PM, Christoph Gohlke wrote: >>>> >>>> >>>> On 2/3/2011 2:15 PM, Eric Firing wrote: >>>>> On 02/03/2011 11:30 AM, Robert Abiad wrote: >>>>>> On 2/3/2011 10:06 AM, Eric Firing wrote: >>>>>>> On 02/02/2011 10:17 PM, Eric Firing wrote: >>>>>>>> On 02/02/2011 08:38 PM, Robert Abiad wrote: >>>>>>>>> >>>>>>>> [...] >>>>>>>>> I'll put it in as an enhancement, but I'm still unsure if there is a >>>>>>>>> bug in >>>>>>>>> there as well. Is there something I should be doing to clear memory >>>>>>>>> after the >>>>>>>>> first figure is closed other than close()? I don't understand why >>>>>>>>> memory usage >>>>>>>>> grows each time I replot, but I'm pretty sure it isn't desireable >>>>>>>>> behavior. As >>>>>>>>> I mentioned, this effect is worse with plot. >>>>>>>>> >>>>>>>>> So is this a bug or improper usage? >>>>>>>> >>>>>>>> I'm not quite sure, but I don't think there is a specifically >>>>>>>> matplotlib >>>>>>>> memory leak bug at work here. Are you using ipython, and if so, have >>>>>>>> you >>>>>>>> turned off the caching? In its default mode, ipython keeps lots of >>>>>>>> references, thereby keeping memory in use. Also, memory management and >>>>>>>> reporting can be a bit tricky and misleading. >>>>>>>> >>>>>>>> Nevertheless, the attached script may be illustrating the problem. Try >>>>>>>> running it from the command line as-is (maybe shorten the loop--it >>>>>>>> doesn't take 100 iterations to show the pattern) and then commenting >>>>>>>> out >>>>>>>> the line as indicated in the comment. It seems that if anything is done >>>>>>>> that adds ever so slightly to memory use while the figure is displayed, >>>>>>>> then when the figure is closed, its memory is not reused. I'm puzzled. >>>>>>> >>>>>>> I wasn't thinking straight--there is no mystery and no memory leak. >>>>>>> Ignore my example script referred to above. It was saving rows of the z >>>>>>> array, not single elements as I had intended, so of course memory use >>>>>>> was growing substantially. >>>>>>> >>>>>>> Eric >>>>>>> >>>>>> >>>>>> You may not see a memory leak, but I still can't get my memory back >>>>>> without killing python. I >>>>>> turned off the ipython caching and even ran without iPython on both >>>>>> Windows and Ubuntu, but when I >>>>>> use imshow(), followed by close('all') and another imshow(), I run out >>>>>> of memory. I can see from >>>>>> the OS that the memory does not come back after close() and that it >>>>>> grows after the second imshow(). >>>>>> >>>>>> Any other ideas? Looks like a bug to me otherwise. >>>>> >>>>> Except that I tried the same things and did not get quite the same >>>>> result. Let's track this down. Please try the attached script, and see >>>>> if the memory usage grows substantially, or just oscillates a bit. >>>>> >>>>> Eric >>>>> >>>> >>>> >>>> One thing I noticed is that if I add a "def __del__(self): print 'del'" >>>> to image._AxesImageBase, it never gets called. _AxesImageBase keeps >>>> float64 and uint8 rgba images in a cache, which is never freed. >>> >>> Adding a __del__ method defeats (or blocks) the garbage collection. >>> >> >> Sorry, never heard of that. I thought __del__() is called when the >> reference count reaches 0. > > It is, but if there are circular reference chains (cycles--and mpl is > full of them) then the garbage collector has to identify them and remove > them. If it encounters a __del__ it stops and leaves that cycle alone. > My understanding is that if there is a circular reference then the refcount will not be zero anyway. In this case _AxesImageBase instances and their image caches will never be deleted by the gc (__del__ method present or not) unless the circle is broken. When the interpreter quits things are deleted by other means. I don't know matplotlib code good enough to fix this and will instead work on reducing the memory overhead needed to plot an image. In the meantime it could help to explicitly delete the image cache when a plot closes or to avoid caching altogether. Christoph > Eric > >> >> Christoph >> >>> Since self._imcache is an instance attribute, when the instance is no >>> longer referenced, it should get garbage-collected, provided there is no >>> __del__ method. >>> >>> Eric >>> >>>> >>>> Christoph > > ------------------------------------------------------------------------------ > The modern datacenter depends on network connectivity to access resources > and provide services. The best practices for maximizing a physical server's > connectivity to a physical network are well understood - see how these > rules translate into the virtual world? > http://p.sf.net/sfu/oracle-sfdevnlfb > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |