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
|
From: John H. <jdh...@ac...> - 2005-02-22 21:33:15
|
>>>>> "Perry" == Perry Greenfield <pe...@st...> writes: Perry> As far as keyword args go, it seems to me that they would Perry> be more convenient in many cases, but as Stephen mentions, Perry> may be a fair amount of work (and in essence, they are an Perry> attribute of the data, so that may be where they belong). In the context of plotting, it isn't clear that NaNess is an attribute of the data. If the data are y = sin(2*pi*t), then NaNess enters only under certain transformations (eg log) of the data. From my perspective, or the perspective of a matplotlib Line, the data are intact, it is just that under certain transformations the data are invalid. Thus the mask is only needed under certain views (transformations) which the Line class is mostly unaware of. I think there are two cases to be distinguished: the case Eric mentioned where some data points are NaN or None because the measurements are missing or invalid, and the case where the data are valid but are nan under certain transformations. For the latter, it would be maximally useful to be able to do #x,y,xt,yt are numerix arrays; transform puts in NaN on domain error xt, yt = transform(x, y) and the drawing routine drops NaN points and handles the connecting segments properly. That it only works for float arrays is not a problem since that is what we are using, eg in the line class self._x = asarray(x, Float) self._y = asarray(y, Float) but it is my current understanding that this ain't gonna happen in a consistent way for Numeric, Numeric3, and numarray across platforms, because my brief forays into researching this issue turned up posts by Tim Peters saying that there was no standard way of dealing with IEEE 754 special values across compilers. If that's true, and we can't fix it or work around it, then I think boolean masks passed as a kwarg may be the easiest way to handle this across various numerix implementations, assuming that Numeric3 comes to fruition and assuming that there isn't a consistent MA approach that is accessible at the API level, which I don't know to be true but I get the feeling that this is a reasonable guess. I'd be interested in getting feedback from those of you who have informed opinions on these matters: - Is it possible to handle NaN in Numeric/numarray arrays across the big three platforms? I'm pretty sure the answer here is no. - Are Numeric and numarray MAs similar enough to be used at the C-API level, which is where agg would be checking the mask? Does anyone know whether MAs will be part of the Numeric3 core? I haven't seen any reference to them in the PEP. JDH |
From: Perry G. <pe...@st...> - 2005-02-22 21:03:55
|
On Feb 21, 2005, at 7:00 PM, Eric Firing wrote: > > Stephen, > >>> Are you suggesting something like this? Let each plotting function >>> have a new kwarg, perhaps called "validmask", with the same >>> dimensions as the dependent variable to be plotted, and with nonzero >>> where the variable is valid and 0 where it is missing. >> More or less, except that the mask is an attribute (?) of a >> MaskedArray object. I for one would be in favor of this capability. > > I agree that this is an alternative, but I am not sure that it is > better than what I described. It requires all the machinery of the > ma/MA module, which looks cumbersome to me. What does it gain? max > and min will do the right thing on the masked array input, so one > would not have to duplicate this inside matplotlib. It is not hard to > duplicate, however. How much more ma/MA functionality would actually > be useful? > > When it was originally developed, the MaskedArray may have been a good > way to get past Numeric's lack of nan-handling. In the long run, > however, it seems to me that Python needs a numeric module with good > nan-handling (as in Matlab and Octave), and that this will render the > Masked Array obsolete. If so, then specifying a mask as a kwarg in > matplotlib, and not using MA internally, may be simpler, more robust, > and more flexible. > > The user would still be free to use MA/ma externally, if desired. > > A variation would be to support MA/ma in matplotlib only to the extent > of checking for a MaskedArray input, and if it is present, breaking it > apart and using the mask as if it had come via the kwarg. One could > use either the kwarg or a Masked Array. > When we looked at the issue of using NaNs in place of masks or masked arrays, we concluded (well, I did anyway) that while NaNs could be used to replace masks in many instances, they could not be used in all. There are a lot of cases where people want to retain the value being masked (e.g., to do statistics on the rejected values). NaNs as masks only work for float and complex, not ints. So both approaches are useful and needed as far as I can tell. As far as keyword args go, it seems to me that they would be more convenient in many cases, but as Stephen mentions, may be a fair amount of work (and in essence, they are an attribute of the data, so that may be where they belong). Perry |
From: Darren D. <dd...@co...> - 2005-02-22 20:41:36
|
On Tuesday 22 February 2005 01:47 pm, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> Hi, I am reporting a minor bug. I noticed that if I change > Darren> the ticklabel size to 10, draw a semilogy plot, and save > Darren> an eps file, that the yticklabels in the eps are badly > Darren> formatted. The exponent runs into the base. > [...] > > The relevant section of code is matplotlib.text.Text._get_layout_super [...] > see if you can find something that works well for a variety of > reasonable font sizes. You might want to make the pad dependent on > the fontsize... The following conditions will work for eps files, however, the labels in the plot on the screen are adversely effected. if size<12: xe = xb+1.3*wb elif size==16: xe = xb+1.175*wb else: xe = xb+1.125*wb ye = yb+0.5*hb Is it possible that the translation to postscript is what needs to be modified? Darren |
From: John H. <jdh...@ac...> - 2005-02-22 18:58:42
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> Hi, I am reporting a minor bug. I noticed that if I change Darren> the ticklabel size to 10, draw a semilogy plot, and save Darren> an eps file, that the yticklabels in the eps are badly Darren> formatted. The exponent runs into the base. Darren> from matplotlib import * rc('tick',labelsize=10) from Darren> pylab import * Darren> semilogy([1,2,3],[1e-5,1,1e5]) savefig('temp.eps') The relevant section of code is matplotlib.text.Text._get_layout_super wb,hb = renderer.get_text_width_height(base, self._fontproperties, False) we,he = renderer.get_text_width_height(exponent, fpexp, False) w = wb+we xb, yb = self._transform.xy_tup((self._x, self._y)) xe = xb+wb ye = yb+0.5*hb h = ye+he-yb w,h is width and height and e,b is exponent and base -- eg, xb is the x location of the base and wb is the width of the base. Try adding a pad to xe, eg xe = xb+1.05*wb and see if you can find something that works well for a variety of reasonable font sizes. You might want to make the pad dependent on the fontsize... JDH |
From: John H. <jdh...@ac...> - 2005-02-22 18:45:34
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes: Eric> Perry, John, Progress! Cool! Eric> I found that the problem I was having with PolyCollection Eric> was this: the vertices argument must be a sequence (list or Eric> tuple) of tuples of tuples--if one gives it a list of Eric> *lists* of tuples, one gets Eric> [first part of trace omitted] File Eric> "/usr/lib/python2.3/site-packages/matplotlib/collections.py", Eric> line 205, in draw self._offsets, self._transOffset) Eric> TypeError: CXX: type error Eric> (The line number was smaller before I put in some debugging Eric> print statements.) Eric> I think this fussiness qualifies as a bug; the docstring for Eric> PolyCollection says vertices can be a sequence of sequences Eric> of tuples. I don't know what the right way to fix it is, Eric> however, so I am working around it. Fair enough -- I just fixed all the agg collection drawing routines to work with the sequence API and not require tuples. Glad to see you're making progress -- poly contouring is something I'd like to see added. Eric> Having solved that problem, I am getting more optimistic Eric> about being able to come up with a usable filled contour Eric> capability fairly quickly. Still no promises, though. Great -- be mindful of the contourf matlab docstrings. Strict adherence is not required, but it is nice to be compatible where possible. Eric> All this brings to mind a question that has puzzled me for a Eric> long time: why does matplotlib internally use sequences of Eric> (x,y) tuples instead of numerix arrays--either a 2-D array, Eric> or a pair (or tuple) of 1-D arrays? I would think that Eric> running all plotted numbers through the conversion from Eric> arrays to Python tuples, and then from there into the native Eric> data types for each backend, would incur a big performance Eric> penalty when plotting large numbers of points. Not that I Eric> am suggesting a redesign--I am just curious. Historical and other reasons. The historical part is that this part of the code was written before Todd had solved the numeric/numarray API compatibility problem for matplotlib. These are now solved, 've been slowly adding some numerix code to backend agg, most recently in 0.72. I don't think it would make a lot of difference for collections. In the first place, you'd have to create all these lists of numarray lists, since the collection is by definition a list of disconnected lines. In the second place, there is a fair amount going on in the inner loop that I think would offset the gains you get from using numeric. In draw_lines, where the x,y access is a major part of the inner loop, I do use numerix. The backend API is moving to a path drawing model, which may obviate the need for specialized collection drawing methods. The collection interface would remain unchanged, but we might get away w/o having special methods to draw them. JDH |
From: Stephen W. <ste...@cs...> - 2005-02-22 14:35:16
|
Stephen Walton wrote, in the context of using masked arrays rather than a keyword argument which would be the mask: > It would be more flexible. Instead of having to actually replace data > with NaN, you could create a mask which marked data to be ignored for > the moment: This is, of course, incorrect. Both approaches would allow arbitrary data sets to be masked as needed. There was a mention over on an astronomy group of the progress being made in masked astronomical images. Here too, the mask "comes along" with the data. Perry et al., does STScI anticipate using numarray/Numeric masked arrays within PyFITS to handle this? |
From: Eric F. <ef...@ha...> - 2005-02-22 04:14:50
|
Perry, John, Progress! I found that the problem I was having with PolyCollection was this: the vertices argument must be a sequence (list or tuple) of tuples of tuples--if one gives it a list of *lists* of tuples, one gets [first part of trace omitted] File "/usr/lib/python2.3/site-packages/matplotlib/collections.py", line 205, in draw self._offsets, self._transOffset) TypeError: CXX: type error (The line number was smaller before I put in some debugging print statements.) I think this fussiness qualifies as a bug; the docstring for PolyCollection says vertices can be a sequence of sequences of tuples. I don't know what the right way to fix it is, however, so I am working around it. Having solved that problem, I am getting more optimistic about being able to come up with a usable filled contour capability fairly quickly. Still no promises, though. All this brings to mind a question that has puzzled me for a long time: why does matplotlib internally use sequences of (x,y) tuples instead of numerix arrays--either a 2-D array, or a pair (or tuple) of 1-D arrays? I would think that running all plotted numbers through the conversion from arrays to Python tuples, and then from there into the native data types for each backend, would incur a big performance penalty when plotting large numbers of points. Not that I am suggesting a redesign--I am just curious. Eric |
From: Darren D. <dd...@co...> - 2005-02-22 04:13:14
|
Hi, I am reporting a minor bug. I noticed that if I change the ticklabel size to 10, draw a semilogy plot, and save an eps file, that the yticklabels in the eps are badly formatted. The exponent runs into the base. from matplotlib import * rc('tick',labelsize=10) from pylab import * semilogy([1,2,3],[1e-5,1,1e5]) savefig('temp.eps') -- Darren |
From: Stephen W. <ste...@cs...> - 2005-02-22 03:05:49
|
Hello, > > I agree that this is an alternative, but I am not sure that it is > better than what I described. It requires all the machinery of the > ma/MA module, which looks cumbersome to me. What does it gain? It would be more flexible. Instead of having to actually replace data with NaN, you could create a mask which marked data to be ignored for the moment: all negative values, say, or all values with a complex part less than 1e-5. Much more flexible. Having said that, I agree that NaN should also be ignored wherever it occurs. > One could use either the kwarg or a Masked Array. -1 on the kwarg. It seems to me that adding it to every plot command uglifies the interface significantly as well as being more work for John. Stephen |
From: Eric F. <ef...@ha...> - 2005-02-22 00:01:05
|
Stephen, >> Are you suggesting something like this? Let each plotting function >> have a new kwarg, perhaps called "validmask", with the same dimensions >> as the dependent variable to be plotted, and with nonzero where the >> variable is valid and 0 where it is missing. > > > More or less, except that the mask is an attribute (?) of a MaskedArray > object. I for one would be in favor of this capability. I agree that this is an alternative, but I am not sure that it is better than what I described. It requires all the machinery of the ma/MA module, which looks cumbersome to me. What does it gain? max and min will do the right thing on the masked array input, so one would not have to duplicate this inside matplotlib. It is not hard to duplicate, however. How much more ma/MA functionality would actually be useful? When it was originally developed, the MaskedArray may have been a good way to get past Numeric's lack of nan-handling. In the long run, however, it seems to me that Python needs a numeric module with good nan-handling (as in Matlab and Octave), and that this will render the Masked Array obsolete. If so, then specifying a mask as a kwarg in matplotlib, and not using MA internally, may be simpler, more robust, and more flexible. The user would still be free to use MA/ma externally, if desired. A variation would be to support MA/ma in matplotlib only to the extent of checking for a MaskedArray input, and if it is present, breaking it apart and using the mask as if it had come via the kwarg. One could use either the kwarg or a Masked Array. Eric |
From: Stephen W. <ste...@cs...> - 2005-02-21 22:07:34
|
Eric Firing wrote: > Are you suggesting something like this? Let each plotting function > have a new kwarg, perhaps called "validmask", with the same dimensions > as the dependent variable to be plotted, and with nonzero where the > variable is valid and 0 where it is missing. More or less, except that the mask is an attribute (?) of a MaskedArray object. I for one would be in favor of this capability. |
From: Eric F. <ef...@ha...> - 2005-02-21 22:02:38
|
Perry, >> I would like to phase in matplotlib to replace Matlab ASAP for >> plotting physical oceanographic observations, primarily current >> profile measurements. I (and many other physical oceanographers) >> primarily use contourf to plot filled contours; I only rarely use line >> contours. It looks to me like gcntr.c has the necessary >> functionality--the ability to output polygons enclosing regions >> between a pair of specified levels. Is someone already working on >> exposing that functionality in matplotlib, or is it planned? >> > No one (as far as I know :-) is working on it right now. It is in our > plans to add this capability. As you correctly note, the underlying C > code can handle this capability. I'm not sure how long it will be; right > now the priority is to finish contour labeling capability, and the > person working on that also has other work that competes with her time > to do this. I'm guessing that she could start looking at it in a couple > weeks. Of course, if someone wants to help now, that would be great. I have started working on it. I don't know how far I will get; the necessary change to the c extension code was easy, but my first attempt to make a PolyCollection work in place of a Line Collection is failing. I will do a bit more research before asking for help, if necessary. (No promises--I don't have much time to work on this, and it is my first plunge into the innards of matplotlib.) > >> It appears that gcntr.c also has the ability to handle missing data >> via setting elements of the reg array to zero, and that this could be >> exposed fairly easily in the contour method in axes.py by adding "reg" >> to the set of kwargs. Correct? If so, is this also planned? >> > Correct. Yes (it is planned). > >> The question of missing data handling in contour plotting brings up >> the more general issue of how to handle data gaps in plots. For >> example, the ocean current profiles that I measure using a Doppler >> profiler extend to varying depths, and sometimes have holes in the >> middle where there are not enough acoustic scatterers to give a >> signal. This sort of thing--data gaps--is universal in physical >> oceanography. One of Matlab's major strengths is the way it handles >> them, using nan as a bad value flag. Plotting a line with the plot >> command, the line is broken at each nan; so if there is a hole in the >> data, the plot shows exactly that. The same for contouring: nans are >> automatically used as a mask. >> >> Obviously, not everyone needs this kind of automatic handling of data >> gaps, but I think it would be very useful for many applications, so I >> hope it can be considered as a possible goal. At the plotting level, >> collections may make it easier to implement than would have been the >> case in the early days of matplotlib. At the array manipulation >> level, the implementation could involve either masked arrays or nans. >> I would greatly prefer the Matlab-style nan approach, but I don't know >> whether this would work with Numeric. Maybe in Numeric3? Numarray >> appears better equipped, with its ieeespecial.py module. >> > I think you touch on the key issue. I think we'd have to figure out how > to handle this between Numeric and numarray (and Numeric3 potentially). > Would a mask array be a suitable substitute as an interim solution? Are you suggesting something like this? Let each plotting function have a new kwarg, perhaps called "validmask", with the same dimensions as the dependent variable to be plotted, and with nonzero where the variable is valid and 0 where it is missing. The mask would then be used (1) to limit the autoranging tests to the valid data, (2) in the case of line plotting, to break the line up into segments so that a LineCollection would be plotted, (3) in the case of contouring, to set the reg array, (4) for images or pcolors to similarly mask out the invalid regions with white, or transparent, or perhaps some settable color. This could be implemented in matplotlib in a way that would not depend on any special features, or likely changes, in the Numeric/Numeric3/numarray set. A numarray user could then use def notnan(y): return numarray.ieeespecial.mask(y, numarray.ieeespecial.NAN) and say plot(x, y, validmask=notnan(y)) In any case, this "validmask kwarg" solution seems to me like a perfectly good one from a user's standpoint, and a good bridge to the happy day when Numeric/Numeric3/numarray converge or evolve to a single, dominant numerical module with good nan handling built in. (I very much hope such convergence will occur, and the sooner the better.) Eric |
From: Perry G. <pe...@st...> - 2005-02-21 17:07:39
|
On Feb 19, 2005, at 9:23 PM, Eric Firing wrote: > John et al., > > I would like to phase in matplotlib to replace Matlab ASAP for > plotting physical oceanographic observations, primarily current > profile measurements. I (and many other physical oceanographers) > primarily use contourf to plot filled contours; I only rarely use line > contours. It looks to me like gcntr.c has the necessary > functionality--the ability to output polygons enclosing regions > between a pair of specified levels. Is someone already working on > exposing that functionality in matplotlib, or is it planned? > No one (as far as I know :-) is working on it right now. It is in our plans to add this capability. As you correctly note, the underlying C code can handle this capability. I'm not sure how long it will be; right now the priority is to finish contour labeling capability, and the person working on that also has other work that competes with her time to do this. I'm guessing that she could start looking at it in a couple weeks. Of course, if someone wants to help now, that would be great. > It appears that gcntr.c also has the ability to handle missing data > via setting elements of the reg array to zero, and that this could be > exposed fairly easily in the contour method in axes.py by adding "reg" > to the set of kwargs. Correct? If so, is this also planned? > Correct. Yes (it is planned). > The question of missing data handling in contour plotting brings up > the more general issue of how to handle data gaps in plots. For > example, the ocean current profiles that I measure using a Doppler > profiler extend to varying depths, and sometimes have holes in the > middle where there are not enough acoustic scatterers to give a > signal. This sort of thing--data gaps--is universal in physical > oceanography. One of Matlab's major strengths is the way it handles > them, using nan as a bad value flag. Plotting a line with the plot > command, the line is broken at each nan; so if there is a hole in the > data, the plot shows exactly that. The same for contouring: nans are > automatically used as a mask. > > Obviously, not everyone needs this kind of automatic handling of data > gaps, but I think it would be very useful for many applications, so I > hope it can be considered as a possible goal. At the plotting level, > collections may make it easier to implement than would have been the > case in the early days of matplotlib. At the array manipulation > level, the implementation could involve either masked arrays or nans. > I would greatly prefer the Matlab-style nan approach, but I don't know > whether this would work with Numeric. Maybe in Numeric3? Numarray > appears better equipped, with its ieeespecial.py module. > I think you touch on the key issue. I think we'd have to figure out how to handle this between Numeric and numarray (and Numeric3 potentially). Would a mask array be a suitable substitute as an interim solution? Perry |
From: John H. <jdh...@ac...> - 2005-02-21 17:00:45
|
>>>>> "James" == James Boyle <bo...@ll...> writes: James> From what I can gather, I can change the line colors and James> widths in the contour routine but cannot specify a line James> style such as dashed, dotted etc. James> Is this true? If so I would like to have this capability - James> it makes black and white plots easier to interpret. There was a bug in the drawing routing for agg line collections that was preventing us from using this. I fixed it this morning. The new default is to use dashed lines for contour levels <0. The contour routine returns (levels, collections) where collections is a list of LineCollection instances, one for each level. You can now use the collection.set_linestyle method, which *should* work across backends. Valid args are 'solid' | 'dashed', 'dashdot', 'dotted' | (offset, on-off-dash-seq) where the last option allows you to control the dash sequence explicitly; on-off-dash-seq is an even length sequence of on/off ink in points. Eg, you can do dashes = 0, (5,1,10,3) collection.set_linestyle(dashes) which is 5 points on, 1 off, followed by 10 points on, 3 off and then repeated. James> In any case the contour in 0.72 works great - thanks Glad to hear it -- we'll be adding more features (eg auto-labeling, poly filling) as we get time. The linestyle support is in 0.72.1, which I uploaded to the sf site this morning. JDH |
From: John H. <jdh...@ac...> - 2005-02-21 14:34:27
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> Wow, I was going crazy trying to reproduce this. Your Darren> script works fine. Try this one: .... Darren> Both the x *and* y axes have to be set_visible(False) to Darren> reproduce the behavior. OK, that helps. Thanks. The problem can be fixed in backend_ps RendererPS.set_color, change the line self.color = (r,g,b) to if store: self.color = (r,g,b) Thanks for the report and example. JDH |
From: fabian s. <fs...@ce...> - 2005-02-21 07:40:50
|
I develop a web application under zope and I would like installing matplotlib under zope.Considering that the python of zope has no the entry in the register, how installing matplotlib? thanks |
From: Darren D. <dd...@co...> - 2005-02-21 02:59:45
|
Wow, I was going crazy trying to reproduce this. Your script works fine. Try this one: from pylab import * a=rand(100,100) ax=axes() ax.imshow(a) ax.xaxis.set_visible(False) ax.yaxis.set_visible(False) ax.text(10,10,'white',color='w') ax.text(10,20,'black',color='k') savefig('temp.ps') Both the x *and* y axes have to be set_visible(False) to reproduce the behavior. Darren On Sunday 20 February 2005 07:47 pm, John Hunter wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> I am displaying some images and overlaying a scalebar. The > Darren> image on the screen displays the requested white text and > Darren> bar, but they are black in the eps image. > > Hi Darren, > > I'm having trouble replicating the problem. Make sure you have an > up-to-date matplotlib. For example, in CVS, I get the expected > behavior in agg and ps with > > from pylab import * > subplot(111, axisbg='red') > text(0.5, 3.5,'this is black', color=0) > text(0.5, 2.5,'this is black', color='k') > text(0.5, 1.5,'this is white', color=1) > text(0.5, 0.5,'this is white', color='w') > axis([0,2,0,4]) > savefig('test.ps') > show() > > If you are still having troubles, please submit a complete test > script, and the output of --verbose-helpful when you run it. > > Is it possible you have a pre 0.72 CVS? There were a couple of bugs I > introduced into PS CVS before the last release, but I think I cleaned > them up. > > Hope this helps, > JDH > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Darren |
From: John H. <jdh...@ac...> - 2005-02-21 00:58:36
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> I am displaying some images and overlaying a scalebar. The Darren> image on the screen displays the requested white text and Darren> bar, but they are black in the eps image. Hi Darren, I'm having trouble replicating the problem. Make sure you have an up-to-date matplotlib. For example, in CVS, I get the expected behavior in agg and ps with from pylab import * subplot(111, axisbg='red') text(0.5, 3.5,'this is black', color=0) text(0.5, 2.5,'this is black', color='k') text(0.5, 1.5,'this is white', color=1) text(0.5, 0.5,'this is white', color='w') axis([0,2,0,4]) savefig('test.ps') show() If you are still having troubles, please submit a complete test script, and the output of --verbose-helpful when you run it. Is it possible you have a pre 0.72 CVS? There were a couple of bugs I introduced into PS CVS before the last release, but I think I cleaned them up. Hope this helps, JDH |
From: Darren D. <dd...@co...> - 2005-02-20 22:05:14
|
I am displaying some images and overlaying a scalebar. The image on the screen displays the requested white text and bar, but they are black in the eps image. text(1,1,'Hi John!',color=1) ---> black text in eps text(1,1,'Hi Jochen!',color='w') ---> black text in eps text(1,1,'I thought this would work...',color=[1,1,1]) ---> black text in eps text(1,1,'but it didnt, so I tried this...',color='y') ---> yellow text in eps text(1,1,'and this...',color=[1,1,0]) ---> yellow text in eps text(1,1,'and finally this.',color=[1,1,.99]) ---> white text in eps I tried to track this through backend_ps.py, where: @ line 103: def set_color(self, r, g, b, store=1): if (r,g,b) != self.color: if r==g and r==b: self._pswriter.write("%1.3f setgray\n"%r) print "%1.3f setgray"%r >>> 1.000 setgray becomes this in the eps file: 0.000 setgray I think there is too much going on behind the scenes for me to follow. This is as far as I could get. -- Darren |
From: John H. <jdh...@ac...> - 2005-02-20 14:32:22
|
>>>>> "Jan" == Jan Rienyer Gadil <jr...@gm...> writes: Jan> i am trying the table_demo.py on IDLE and i am getting this Jan> error message: Traceback (most recent call last): File Jan> "C:\Python23\practices\table.py", line 5, in -toplevel- from Jan> colours import get_colours ImportError: No module named Jan> colours You have to download the examples directory which contains table_demo.py -- it is available as a zip file at http://matplotlib.sourceforge.net/matplotlib_examples_0.72.zip This dir contains colours.py, which table_demo imports. JDH |
From: John H. <jdh...@ac...> - 2005-02-20 14:30:26
|
>>>>> "Alex" == Alex Rada <ale...@gm...> writes: Alex> HI, and now I can load pylab but have problems to see Alex> images, infact if I try: >>>> from pylab import * plot([1,2,3]) There are a number of subtleties in trying to get matplotlib working from the python shell, as described at http://matplotlib.sf.net/interactive.html . Try running a script from pylab import plot, show plot([1,2,3]) show() from the bash shell with > python myscript.py --verbose-helpful Do you get a plot? If not, please post the output generated by the script. JDH |
From: Alex R. <ale...@gm...> - 2005-02-20 11:27:57
|
HI, and now I can load pylab but have problems to see images, infact if I try: >>> from pylab import * >>> plot([1,2,3]) I get: art_render_invoke: no image source given art_render_invoke: no image source given art_render_invoke: no image source given art_render_invoke: no image source given art_render_invoke: no image source given art_render_invoke: no image source given *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice *** attempt to put segment in horiz list twice art_render_invoke: no image source given [<matplotlib.lines.Line2D instance at 0xb7bea96c>] maybe I have not the right backend settings!? I'm using GTK (backend : GTK, in my .matplotlibrc), I tried to install agg, but I have problems with the makefile... Alex... |
From: Robert L. <ro...@le...> - 2005-02-20 10:34:04
|
Alex Rada wrote: > ImportError: No module named Numeric You need to tell Matplotlib that you are using numarray instead of Numeric. It can be specified in your matplotlibrc file or at runtime: > python myscript.py --numarray # use numarray > python myscript.py --Numeric # use Numeric See section 1.2.1 of the users guide. Robert |
From: Alex R. <ale...@ya...> - 2005-02-20 10:13:00
|
Hi all, I newly installed matplotlib 0.71 on my slackware 10 with numarray 1.1 and python 2.4, the installation goes well, but when I try to launch pylab I get the following error: ------------------------------------------------------------------------------------------------------------------- Python 2.4 (#1, Feb 19 2005, 22:46:12) [GCC 3.3.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from pylab import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/usr/lib/python2.4/site-packages/matplotlib/pylab.py", line 186, in ? import cm File "/usr/lib/python2.4/site-packages/matplotlib/cm.py", line 5, in ? import colors File "/usr/lib/python2.4/site-packages/matplotlib/colors.py", line 32, in ? from numerix import array, arange, take, put, Float, Int, where, \ File "/usr/lib/python2.4/site-packages/matplotlib/numerix/__init__.py", line 59, in ? from Numeric import * ImportError: No module named Numeric ------------------------------------------------------------------------------------------------------------------------- thanks for the help, Alex |
From: Jan R. G. <jr...@gm...> - 2005-02-20 03:28:39
|
i am trying the table_demo.py on IDLE and i am getting this error message: Traceback (most recent call last): File "C:\Python23\practices\table.py", line 5, in -toplevel- from colours import get_colours ImportError: No module named colours i am using python 2.3 (enthought edition) with matplotlib 0.71 on Win XP. here's the demo code by the way (copy/pasted): #!/usr/bin/env python import matplotlib from pylab import * from colours import get_colours axes([0.2, 0.2, 0.7, 0.6]) # leave room below the axes for the table data = [[ 66386, 174296, 75131, 577908, 32015], [ 58230, 381139, 78045, 99308, 160454], [ 89135, 80552, 152558, 497981, 603535], [ 78415, 81858, 150656, 193263, 69638], [ 139361, 331509, 343164, 781380, 52269]] colLabels = ('Freeze', 'Wind', 'Flood', 'Quake', 'Hail') rowLabels = ['%d year' % x for x in (100, 50, 20, 10, 5)] # Get some pastel shades for the colours colours = get_colours(len(colLabels)) colours.reverse() rows = len(data) ind = arange(len(colLabels)) + 0.3 # the x locations for the groups cellText = [] width = 0.4 # the width of the bars yoff = array([0.0] * len(colLabels)) # the bottom values for stacked bar chart for row in xrange(rows): bar(ind, data[row], width, bottom=yoff, color=colours[row]) yoff = yoff + data[row] cellText.append(['%1.1f' % (x/1000.0) for x in yoff]) # Add a table at the bottom of the axes colours.reverse() cellText.reverse() the_table = table(cellText=cellText, rowLabels=rowLabels, rowColours=colours, colLabels=colLabels, loc='bottom') ylabel("Loss $1000's") vals = arange(0, 2500, 500) yticks(vals*1000, ['%d' % val for val in vals]) xticks([]) title('Loss by Disaster') #savefig('table_demo_small', dpi=75) #savefig('table_demo_large', dpi=300) show() |