matplotlib-devel Mailing List for matplotlib

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

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> 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

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> 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.

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> 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

>>>>> "Eric" == Eric Firing <ef...@ha...> 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

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

John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> 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

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

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

>>>>> "Manuel" == Manuel Metz <mm...@as...> writes:
 Manuel> John Hunter wrote:
 >>>>>>> "Manuel" == Manuel Metz <mm...@as...> 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

John Hunter wrote:
>>>>>> "Manuel" == Manuel Metz <mm...@as...> 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