Re: [matplotlib-devel] custom symbol patch
John Hunter wrote:
>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes:
>
> Manuel> Hi, I just submitted a patch to sourceforge and also
> Manuel> attached it to this email:
>
> Manuel> The applied patch modifies the files axes.py and
> Manuel> collections.py.
>
> Manuel> I added a class StaredRegularPolyCollection() to
> Manuel> collections.py to create star-like regular Polygons.
>
> This looks very useful -- thanks for the patch. To questions:
>
> What does the name "StaredRegularPolygon" mean? I am having trouble
> figuring out the Stared part.
Argh - okay - this is a mistranslation from german to english - sorry. I
wanted to say "starlike". So probably StarlikeRegularPolygon is a better
name...
If changed this and attach an updated patch (also updated on sourceforge).
Btw.: there is also a minor change concerning the rescaling of custom
verts. For the rescaling, it is assumed that the vertices are
centred on the coordinate centre, and rescaling is done such that the
largest distance from the centre is scaled to 1.
> It would be nice to have this functionality in the line markers as
> well. Any interest in trying to port some of these changes to the
> matplotlib.lines?
I will have a look into this.
Manuel
Index: axes.py
===
--- axes.py (revision 2806)
+++ axes.py (working copy)
@@ -15,7 +15,8 @@
from axis import XAxis, YAxis
from cbook import iterable, is_string_like, flatten, enumerate, \
allequal, dict_delall, popd, popall, silent_list
-from collections import RegularPolyCollection, PolyCollection, LineCollection, QuadMesh
+from collections import RegularPolyCollection, PolyCollection, LineCollection, QuadMesh, \
+ StarlikeRegularPolyCollection
from colors import colorConverter, normalize, Colormap, \
LinearSegmentedColormap, looks_like_color, is_color_like
import cm
@@ -1211,7 +1212,7 @@
if xmax is None and hasattr(xmin,'__len__'):
xmin,xmax = xmin
- old_xmin,old_xmax = self.get_xlim()
+old_xmin,old_xmax = self.get_xlim()
if xmin is None: xmin = old_xmin
if xmax is None: xmax = old_xmax
@@ -1223,7 +1224,7 @@
xmin -= 1e-38
xmax += 1e-38
- self.viewLim.intervalx().set_bounds(xmin, xmax)
+self.viewLim.intervalx().set_bounds(xmin, xmax)
if emit: self._send_xlim_event()
return xmin, xmax
@@ -1324,7 +1325,7 @@
if ymax is None and hasattr(ymin,'__len__'):
ymin,ymax = ymin
- old_ymin,old_ymax = self.get_ylim()
+old_ymin,old_ymax = self.get_ylim()
if ymin is None: ymin = old_ymin
if ymax is None: ymax = old_ymax
@@ -3102,10 +3103,9 @@
'h' : hexagon
'8' : octagon
+If marker is None and verts is not None, verts is a sequence
+of (x,y) vertices for a custom scatter symbol.
-if marker is None and verts is not None, verts is a sequence
-of (x,y) vertices for a custom scatter symbol. The
-
s is a size argument in points squared.
Any or all of x, y, s, and c may be masked arrays, in which
@@ -3173,26 +3173,74 @@
if faceted: edgecolors = None
else: edgecolors = 'None'
-sym = syms.get(marker)
-if sym is None and verts is None:
-raise ValueError('Unknown marker symbol to scatter')
-
+sym = None
+starlike = False
+
+if isinstance(marker, str) or isinstance(marker, unicode):
+# the standard way to define symbols using a string character
+sym = syms.get(marker)
+if sym is None and verts is None:
+raise ValueError('Unknown marker symbol to scatter')
+numsides, rotation = syms[marker]
+
+# to be API compatible
+if sym is None and not (verts is None):
+marker = (verts, 0)
+verts = None
+
+if isinstance(marker, tuple) or isinstance(marker, list):
+# accept marker to be:
+#(numsides, style, [angle])
+# or
+#(verts[], style, [angle])
+
+if len(marker)<2 or len(marker)>3:
+raise ValueError('Cannot create markersymbol from marker')
+
+if isinstance(marker[0], int) or isinstance(marker[0], long):
+# (numsides, style, [angle])
+
+if len(marker)==2:
+numsides, rotation = marker[0], math.pi/4.
+elif len(marker)==3:
+numsides, rotation = marker[0], marker[2]
+sym = True
+
+if marker[1]==1:
+# starlike symbol, everthing else is interpreted as solid symbol
+starlike = True
+
+else:
+verts = asarray(marker[0])
+
Re: [matplotlib-devel] custom symbol patch
> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes: Manuel> John Hunter wrote: >>> "Manuel" == Manuel Metz <[EMAIL PROTECTED]> writes: >> Manuel> Hi, I just submitted a patch to sourceforge and also Manuel> attached it to this email: >> Manuel> The applied patch modifies the files axes.py and Manuel> collections.py. >> Manuel> I added a class StaredRegularPolyCollection() to Manuel> collections.py to create star-like regular Polygons. >> This looks very useful -- thanks for the patch. To questions: >> >> What does the name "StaredRegularPolygon" mean? I am having >> trouble figuring out the Stared part. Manuel> Argh - okay - this is a mistranslation from german to Manuel> english - sorry. I wanted to say "starlike". So probably Manuel> StarlikeRegularPolygon is a better name... OK, I see. Perhaps we should just call it a StarPolygonCollection http://en.wikipedia.org/wiki/Star_polygon Also, in your patch, unless I am missing something, it looks like you could simply do something like scale = 0.5/math.sqrt(math.pi) r = scale*ones(self.numsides*2) rather than +r = 1.0/math.sqrt(math.pi) # unit area +r = asarray( [r]*(self.numsides*2) ) +for i in xrange(1,len(r),2): +r[i] *= 0.5 Ie, do everything in numerix, rather than in python. When you get all of this incorporated, if you could send one patch against svn that includes all of the changes I'll check it in (if noone else has any corrections or comments). Thanks again, JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
Eric Firing wrote: > Norbert, > >>> >>> The problem in r2790: I changed the default value in matplotlibrc to 'auto' and everything worked fine for me. I forgot that, of course, anybody updating from an older version, would still have the values 'blue' and 'black' in their matplotlibrc, which would not be overridden by the '.r' option that Stefan used. >>> This is not the first time matplotlibrc has bitten us, and it won't be >>> the last... >>> >>> But *shouldn't* '.r' override a setting in matplotlibrc, regardless of >>> what that setting is? I think it should have set the mfc, or preferably >>> both the mfc and the mec. >>> >>> >> OK, that would be an alternative solution: set both mfc and mec to >> 'auto', whenever the color is specified using a format string. However, >> this would mean that the rcfile options markeredgecolor and >> markerfacecolor are often ignored, even if they were set on purpose. If >> that is the case, one could just as well deactivate them completely and >> prevent some confusion. >> >> > > Either I am not understanding you correctly, or we have fundamentally > different views of the role of matplotlibrc values. The way I see it, > function args and kwargs *always* override matplotlibrc values, which in > turn *always* override built-in defaults. So in the example above, if > the user writes "plot(x,y,'r.')", red dots should be plotted no matter > what is in matplotlibrc. It should not depend on whether something is > set to 'auto'. > I fully agree with you. Guess, the simple solution to the dilemma is to drop the idea of rcfile-configurability of markerfacecolor and markeredgecolor. That way, markers would always have the same color as the line, unless explicitely set differently by the kwargs markeredgecolor/markerfacecolor. This is, what is wanted in 99% of the cases and for every other case, a rcfile-option will not help anyway. Greetings, Norbert - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] matplotlib.template now mostly commented out
Hello everybody, after discussion with Eric Firing and John Hunter (see thread "marker color handling"), I just changed matplotlib.template on SVN: All the lines duplicating the default values already set in defaultParam (lib/matplotlib/__init__.py) are now commented out in matplotlibrc.template (and therefore also in matplotlib, which is usually copied to the users home directory). These values have always been redundant and frequently caused problems when updating to newer versions. Except for the options backend and numerix, which are both set by setup.py, the file matplotlib is therefore effectively empty. If a user explicitely wants to change a value, the line can simply be uncommented to become effective. Users of matplotlib are encouraged to use the new matplotlibrc as basis for their own configuration. Greetings, Norbert Nemec - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc generation
John Hunter wrote: >> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> > > Eric> 1) generate matplotlibrc with almost everything commented > Eric> out by default > > +2 > > Hopefully, this will address the problem of all the deprecated rc > warnings people are getting, which is confusing to new users. > As you saw, I boldly implemented that change already. > Eric> 2) eliminate matplotlibrc.template by having setup.py > Eric> autogenerate matplotlibrc based on the rcParams-related code > Eric> that is presently in __init__.py. > > working code tested across platforms and python versions settles this. > It is mostly working now, but Norbert brings up a good point that if > we now go to mostly empty rc files, it will become increasingly > unlikely that the template gets out of whack. If this is important to > someone and they can come up with a good implementation, I don't have > a problem with it. > I already started working on this. Don't know when I find the time to finish, but I will post patches for testing as soon as I have something clean enough. Greetings, Norbert - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
Norbert, >>Either I am not understanding you correctly, or we have fundamentally >>different views of the role of matplotlibrc values. The way I see it, >>function args and kwargs *always* override matplotlibrc values, which in >>turn *always* override built-in defaults. So in the example above, if >>the user writes "plot(x,y,'r.')", red dots should be plotted no matter >>what is in matplotlibrc. It should not depend on whether something is >>set to 'auto'. >> > > > I fully agree with you. > > Guess, the simple solution to the dilemma is to drop the idea of > rcfile-configurability of markerfacecolor and markeredgecolor. That way, > markers would always have the same color as the line, unless explicitely > set differently by the kwargs markeredgecolor/markerfacecolor. > > This is, what is wanted in 99% of the cases and for every other case, a > rcfile-option will not help anyway. This sounds ideal to me--it makes everything simpler, both in the code and in explaining what the behavior is. Thanks! Eric - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> This is, what is wanted in 99% of the cases and for every other >> case, a rcfile-option will not help anyway. Eric> This sounds ideal to me--it makes everything simpler, both Eric> in the code and in explaining what the behavior is. Hmm I can imagine that there are those who want the default markeredgecolor to be the same color as the facecolor, and those who want the default edgecolor to be black regardless of facecolor. I am a bit hesitant to pull this functionality, though I agree that simpler is better. JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
John Hunter wrote: >>"Eric" == Eric Firing <[EMAIL PROTECTED]> writes: > > > >> This is, what is wanted in 99% of the cases and for every other > >> case, a rcfile-option will not help anyway. > > Eric> This sounds ideal to me--it makes everything simpler, both > Eric> in the code and in explaining what the behavior is. > > Hmm I can imagine that there are those who want the default > markeredgecolor to be the same color as the facecolor, and those who > want the default edgecolor to be black regardless of facecolor. I am > a bit hesitant to pull this functionality, though I agree that simpler > is better. How about replacing the markeredgecolor and markerfacecolor rc options (but not the kwargs) with something like this: markeredgedefault = 'face' | colorspec If something like this is chosen, I think it should apply only to filled markers. Here is a variation on the theme: markeredgedefault = colorspec where colorspec can include 'None' and means "don't draw it". I think that what we actually want for filled markers with the edge color matching the face is not to set the edgecolor to the facecolor, but to not draw the edge at all; this will render better and be more efficient at all levels. (I suspect the 'None' colorspec should be uniformly supported all the way from the high level down to the backends. That would eliminate high-level checking for it as a special case.) As part of this, I think we should be thinking of the "marker color" as the face color for filled markers and as the line color for non-filled markers; for filled markers, the edge is better thought of as the "outline", which is missing for line markers. The clearest point in all of this seems to be that trying to have a 1:1 relation between kwargs and rc params is inconsistent with achieving nice default behavior in this case. Sorry this is a bit of a ramble but I am short on time right now. Norbert, can we take a few days if necessary to think this through carefully and make sure John and others are comfortable with the whole plan before going any further? Eric - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
John Hunter wrote: >> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: >> > > >> This is, what is wanted in 99% of the cases and for every other > >> case, a rcfile-option will not help anyway. > > Eric> This sounds ideal to me--it makes everything simpler, both > Eric> in the code and in explaining what the behavior is. > > Hmm I can imagine that there are those who want the default > markeredgecolor to be the same color as the facecolor, and those who > want the default edgecolor to be black regardless of facecolor. I am > a bit hesitant to pull this functionality, though I agree that simpler > is better. > This functionality was never there, so nobody can miss it. Before my changes, the options in matplotlibrc only allowed to specify fixed colors for mfc and mec. This is now not possible any more, but can easily be done via kwargs. Automatic coloring was just as inflexible as it is now but less consistent. I thought about this kind of configurability, but any clean solution that I could find, would have become awfully complex. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
> "Norbert" == Norbert Nemec <[EMAIL PROTECTED]> writes: Norbert> This functionality was never there, so nobody can miss Norbert> it. Before my changes, the options in matplotlibrc only Norbert> allowed to specify fixed colors for mfc and mec. This is Norbert> now not possible any more, but can easily be done via Norbert> kwargs. Automatic coloring was just as inflexible as it Norbert> is now but less consistent. Yeah, I mispoke a bit. What I meant is that I prefer black edges, and I expect plot(rand(10), 'go') to have a green face and black edges. There is no way in the new infrastructure for this to happen by default as far as I can see, but I can pass mec if I want. I can live with it, but I may not be the only one, so be prepared for griping. Or we can consider something like Eric proposed where mec can either follow mfc or be set to a fixed color, or something along those lines. JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
On another note, I get messages like mpl/examples> python simple_plot.py -dAgg Bad key "lines.markeredgecolor" on line 48 in /home/jdhunter/.matplotlib/matplotlibrc. You probably need to get an updated matplotlibrc file from http://matplotlib.sf.net/matplotlibrc or from the matplotlib source distribution Bad key "lines.markerfacecolor" on line 47 in /home/jdhunter/.matplotlib/matplotlibrc. You probably need to get an updated matplotlibrc file from http://matplotlib.sf.net/matplotlibrc or from the matplotlib source distribution since I did yet not update to the new rc which is to be expected. I know from experience that neophyte users are confused by this. Many mpl users don't even know that an rc file exists, what it is for, and how to find it. While you are mucking around in rc and __init__.py, you might consider a more helpful deprecation message scheme, with part of the message boilerplate and part of the message specific to the bad rc key. Eg, if a user has lines.markerfacecolor in his rc: The setting "lines.markerfacecolor" in your parameter file /home/jdhunter/.matplotlib/matplotlibrc is deprecated in this version of matplotlib. The configuration for marker facecolors was your was recently changed. blah blah blah explain the new interface and behavior. You may want to replace /home/jdhunter/.matplotlib/matplotlibrc with the latest file http://matplotlib.sf.net/matplotlibrc . Something to think about. JDH - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] marker color handling: matplotlibrc versus args and kwargs
John Hunter wrote: >> "Norbert" == Norbert Nemec <[EMAIL PROTECTED]> writes: >> > Norbert> This functionality was never there, so nobody can miss > Norbert> it. Before my changes, the options in matplotlibrc only > Norbert> allowed to specify fixed colors for mfc and mec. This is > Norbert> now not possible any more, but can easily be done via > Norbert> kwargs. Automatic coloring was just as inflexible as it > Norbert> is now but less consistent. > > Yeah, I mispoke a bit. What I meant is that I prefer black edges, and > I expect > > plot(rand(10), 'go') > > to have a green face and black edges. There is no way in the new > infrastructure for this to happen by default as far as I can see, but > I can pass mec if I want. > Actually, this is the new default behavior: for filled markers, the mfc is set to the line color and the mec is set to black. For non-filled markers, mec is set to the line color and mfc is not used at all. What is impossible to set by default are alternative settings like * mec and mfc to line color * mec to line color and mfc to white > I can live with it, but I may not be the only one, so be prepared for > griping. Or we can consider something like Eric proposed where mec > can either follow mfc or be set to a fixed color, or something along > those lines. > > JDH > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
