matplotlib-devel Mailing List for matplotlib (Page 3)

>>>>> "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.
 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.
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> It raises larger API questions. From the standpoint of
 Eric> user-level code readability, the present array of marker and
 Eric> line identifiers (inherited from Matlab) is not good. For
 Eric> example, why should '-' mean a solid line, but '_' means a
 Eric> horizontal line marker? What is the difference between '^'
 Eric> and '2', and how on earth is anyone reading the code
 Eric> supposed to know what '2' means? The only justification I
 Eric> can see for the 1- and 2-character codes is their
 Eric> convenience in interactive use for things like
 Eric> "plot(x,y,'g.'". I would not want this to go away, but for
 Eric> non-interactive coding I think longer names, typically
 Eric> corresponding to the name of the function that generates the
I think for interactive use it is important to keep these short
characters though you are right, for some of the more arcane ones like
1,2,3,4 it makes no sense since there is no mnemonic. But I see no
harm in keeping them for interactive users
 Eric> This needs either some broader discussion, or a command
 Eric> decision by John along the lines of "Forget it; it's OK the
 Eric> way it is, or it is too late to make any change in this part
 Eric> of the API."
As you suggest, what we need to provide is an easy way for people to
use long readable names. The easiest way is in set_marker and
set_linestyle to do something like (untested sketch)
 def set_linestyle(self, linestyle):
 funcname = '_draw_%s'%linestyle
 func = getattr(self, funcname, None)
 if callable(func):
 self._lineFunc = func
and ditto for set_marker while still supporting the old mnemonics.
We can then advertise any of names available as values in the
Line2D._lineStyles and Line2D._markers dictionaries as legitimate
values for the linestyle and marker properties. Extra credit for
auto-updating the docstring by parsing the dictionary values.
In [1]: from matplotlib.lines import Line2D
In [2]: print [name[6:] for name in Line2D._markers.values() if
name.startswith('_draw_')]
['tickleft', 'tickright', 'tickup', 'tickdown', 'nothing', 'nothing',
'plus', 'pixel', 'point', 'tri_down', 'tri_left', 'tri_up',
'tri_right', 'triangle_left', 'triangle_right', 'nothing', 'diamond',
'hexagon2', 'hline', 'triangle_up', 'thin_diamond', 'hexagon1',
'circle', 'pentagon', 'square', 'triangle_down', 'x', 'vline']
JDH

Norbert,
>>> The core problem: The matplotlibrc file distributed with matplotlib
>>> contains all the default values in non-commented lines. This file is
>>> usually copied to the home-directory of any user, making it impossible
>>> to simply change any default value in later versions. It is not possible
>>> to find out which values in the users matplotlibrc were set on purpose
>>> and which were just left untouched from the distributed file.
>>>
>>> The better solution: place '#' at the beginning of every line in
>>> matplotlibrc.template (except for 'backend' and 'numerix' which carry
>>> important information) Any user who explicitely wants to change a value,
>>> can simply uncomment the line and set a value. Otherwise, the default
>>> value from matplotlib/__init__.py will remain active, even if changed in
>>> an update. Of course, this would only make sense, if users were informed
>>> and encouraged to replace their personal matplotlibrc
>>> 
>> This seems like a good idea, and one that is consistent with the way 
>> many other configurable systems are often handled. I think that 
>> regardless of what else is done, this would reduce pain during updates; 
>> it would also make it easier for the user to see what changes to the 
>> defaults he/she has made.
>> 
> So, should we simply do that? The only problem that I see is, that
> matplotlibrc.template will probably soon be out of sync with
> defaultParams in __init__.py, once there is no necessity for developers
> to update it.
> 
>>> The ultimate solution: The file matplotlib.template should probably be
>>> dropped completely and be auto-created from the information in
>>> matplotlib/__init__.py - this would remove quite some redundancy and
>>> potential for inconsistencies.
>>> 
>> Reducing redundancy is appealing, but I don't know if it would be worth 
>> the effort of implementing your auto-generation idea--which might add 
>> clutter and complexity to __init__.py.
>> 
> Not necessarily. I was thinking of moving defaultParams out of
> __init__.py to a separate file, which can be imported by setup.py to
> write matplotlibrc. This would even reduce the complexity of
> __init__.py. However, it will need some cleanup first to reduce
> dependencies. I've started on that, but it will take some more time.
> 
> In any case, this auto-generation would solve the problem of a
> increasingly outdated matplotlibrc.template.
Before going too far with all this, it would be good to hear from John 
and others. It all sounds good to me, but others might have objections 
or good alternatives that should be considered.
To summarize, your two proposals are:
1) generate matplotlibrc with almost everything commented out by default
2) eliminate matplotlibrc.template by having setup.py autogenerate 
matplotlibrc based on the rcParams-related code that is presently in 
__init__.py.
Eric

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> marker='tri_up')"? (I still don't know what is the
 Eric> difference between "tri_up" and "triangle_up".)
tri_up is a tripod up, vs a triangle up.
JDH

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'.
Eric

Norbert,
I am splitting this thread because I think different issues are involved 
in different parts.
> 
>> In looking at your original patch, I also wondered what is the reason 
>> for supporting 3 different ways of specifying "_draw_nothing"? (I had 
>> not previously noticed that there was any such thing at all, and I guess 
>> I don't understand what it is for.)
>> class Line2D(Artist):
>> _lineStyles = {
>> '-' : '_draw_solid',
>> '--' : '_draw_dashed',
>> '-.' : '_draw_dash_dot',
>> ':' : '_draw_dotted',
>> 'steps': '_draw_steps',
>> 'None' : '_draw_nothing',
>> ' ' : '_draw_nothing',
>> '' : '_draw_nothing',
>> }
>> 
> The idea was to be able to say something like
> plot(x,y,line='',marker='o',color=(.2,.5,.8))
> which seemed a bit more intuitive to me than line='None' when I created
> the patch. By now, I wonder about it myself...
It raises larger API questions. From the standpoint of user-level code 
readability, the present array of marker and line identifiers (inherited 
from Matlab) is not good. For example, why should '-' mean a solid 
line, but '_' means a horizontal line marker? What is the difference 
between '^' and '2', and how on earth is anyone reading the code 
supposed to know what '2' means? The only justification I can see for 
the 1- and 2-character codes is their convenience in interactive use for 
things like "plot(x,y,'g.'". I would not want this to go away, but for 
non-interactive coding I think longer names, typically corresponding to 
the name of the function that generates the marker (in the case of 
markers) should be available and used. Further, it may be that only the 
set of unique descriptive names should be available at the level of 
lines.py, and the shorthand versions should be relegated to support code 
for the plot command, which is at a higher level. Going even further, 
maybe the short format strings should be limited to a subset of 
available lines and markers. Is it really important to let people write 
"plot(x,y,'g2')" instead of "plot(x,y, color='g', marker='tri_up')"? (I 
still don't know what is the difference between "tri_up" and "triangle_up".)
This needs either some broader discussion, or a command decision by John 
along the lines of "Forget it; it's OK the way it is, or it is too late 
to make any change in this part of the API."
Eric

>>>>> "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.
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?
JDH

Eric Firing wrote:
> Norbert Nemec wrote:
> 
>> OK, I found the problem and committed a temporary fix. The real problem,
>> however is rooted a bit deeper.
>>
>> First an explanation of the intended change:
>>
>> It used to be that marker colors were partly automatic, but not
>> completely. I.e.
>>
>> plot(x,y,'-or')
>>
>> would set both, line color and marker color to red. However
>>
>> plot(x,y,color='r')
>>
>> would set only the line color and leave marker color to the default.
>> My change was to introduce a special value 'auto' for markeredgecolor and
>> markerfacecolor. This special value would cause the marker color to
>> always follow
>> the line color. (Which is, in 99% of the cases, what you want.) Most of
>> the special logic in axes.py could therefore go away. mfc and mec would
>> simply be left at 'auto' unless explicitely assigned another color. The
>> handling of the special value would then happen in lines.py at time of
>> plotting. (including the effect that for filled markers, the edge would
>> default to black)
>>
>> 
>
> In your explanation above, it is not clear what happens in each of the 4 
> cases: mec auto or non-auto, and mfc auto or non-auto.
> 
mec and mfc are handled independently.
markeredges are drawn using:
mec, if mec!='auto'
color, if mec=='auto' and marker not in filled_markers
black, if mec=='auto' and marker in filled_marker
markerfaces are drawn using:
mfc, if mfc!='auto'
color, if mfc=='auto'
Since non-filled markers are considered 'edges' without filling, this
logic is necessary to get the correct behavior.
> In looking at your original patch, I also wondered what is the reason 
> for supporting 3 different ways of specifying "_draw_nothing"? (I had 
> not previously noticed that there was any such thing at all, and I guess 
> I don't understand what it is for.)
> class Line2D(Artist):
> _lineStyles = {
> '-' : '_draw_solid',
> '--' : '_draw_dashed',
> '-.' : '_draw_dash_dot',
> ':' : '_draw_dotted',
> 'steps': '_draw_steps',
> 'None' : '_draw_nothing',
> ' ' : '_draw_nothing',
> '' : '_draw_nothing',
> }
> 
The idea was to be able to say something like
plot(x,y,line='',marker='o',color=(.2,.5,.8))
which seemed a bit more intuitive to me than line='None' when I created
the patch. By now, I wonder about it myself...
If there is an objection against this detail, I can revert it. I
probably should have split the patch in parts in the first place.
Unfortunately, the different parts had become more interdependent than I
would have liked.
> I was also a little uncomfortable with pushing some of the color 
> decision logic all the way down into the draw method, together with a 
> default value, although maybe there is no better way to get the desired 
> behavior:
>
> if self._marker is not None:
> gc = renderer.new_gc()
> if (is_string_like(self._markeredgecolor) and
> self._markeredgecolor == 'auto'):
> if self._marker in self.filled_markers:
> gc.set_foreground('k')
> else:
> gc.set_foreground(self._color)
> else:
> gc.set_foreground(self._markeredgecolor)
> 
This was the cleanest solution. If the decision is made earlier, one
always has to store not only the value of mec, but also, whether it was
set explicitely or automatically. Otherwise, the marker color is not
updated when set_color is called on an existing graph. (Which was the
problem that started my whole effort)
>
>
> 
>> 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.
>> The (temporary) solution in r2800: I deactivated the
>> rcfile-configurability of markeredgecolor and markerfacecolor. Assuming
>> that hardly anybody would want to change the 'auto' behavior in their
>> rcfile, this should be a good solution until we have solved the core
>> problem.
>>
>> The core problem: The matplotlibrc file distributed with matplotlib
>> contains all the default values in non-commented lines. This file is
>> usually copied to the home-directory of any user, making it impossible
>> to simply change any default value in later versions. It is not possible
>> to find out which values in the users matplotlibrc were set on purpose
>> and which were just left untouched from the distributed file.
>>
>> The better solution: place '#' at the beginning of every line in
>> matplotlibrc.template (except for 'backend' and 'numerix' which carry
>> important information) Any user who explicitely wants to change a value,
>> can simply uncomment the line and set a value. Otherwise, the default
>> value from matplotlib/__init__.py will remain active, even if changed in
>> an update. Of course, this would only make sense, if users were informed
>> and encouraged to replace their personal matplotlibrc
>> 
>
> This seems like a good idea, and one that is consistent with the way 
> many other configurable systems are often handled. I think that 
> regardless of what else is done, this would reduce pain during updates; 
> it would also make it easier for the user to see what changes to the 
> defaults he/she has made.
> 
So, should we simply do that? The only problem that I see is, that
matplotlibrc.template will probably soon be out of sync with
defaultParams in __init__.py, once there is no necessity for developers
to update it.
>> The ultimate solution: The file matplotlib.template should probably be
>> dropped completely and be auto-created from the information in
>> matplotlib/__init__.py - this would remove quite some redundancy and
>> potential for inconsistencies.
>> 
>
> Reducing redundancy is appealing, but I don't know if it would be worth 
> the effort of implementing your auto-generation idea--which might add 
> clutter and complexity to __init__.py.
> 
Not necessarily. I was thinking of moving defaultParams out of
__init__.py to a separate file, which can be imported by setup.py to
write matplotlibrc. This would even reduce the complexity of
__init__.py. However, it will need some cleanup first to reduce
dependencies. I've started on that, but it will take some more time.
In any case, this auto-generation would solve the problem of a
increasingly outdated matplotlibrc.template.

Hi,
I just submitted a patch to sourceforge and also attached it to this email:
The applied patch modifies the files axes.py and
collections.py.
I added a class StaredRegularPolyCollection() to
collections.py to create star-like regular Polygons.
These symbols can be used with the scatter() function.
I modified the scatter function somewhat, but keeping
the API compatible. It is now easily possible to create
a greater variety of symbols:
- scatter(x,y,marker="[marker caracter]") behaves as before
- scatter (x,y,marker=None, verts=[list of verts])
behaves as before
- [NEW] scatter(x,y,marker=(N,0,[angle])) produces a
scatter plot with a N-sided regular solid polygone
- [NEW] scatter(x,y,marker=(N,1,[angle])) produces a
scatter plot with a N-sided star-like symbol (using the
class StaredRegularPolyCollection)
- [NEW] scatter(x,y,marker=(verts,0)) produces a
scatter plot like scatter(x,y,marker=None,verts=verts)
So, marker can now be:
- a single character as before
- a tuple (or list): (numsides, style, [optional angle])
- with style=[int]
 = 0: solid polygone
 = 1: stared polygone
 (define this as constants somewhere ?)
- (verts, style); actually style is ignored for this
option, but see below
This approach allows for easy future extension, e.g. a
style 2(=lines) may be added which allows for
none-closed symbols which can be very useful to create
"S"-shaped symbols. Another possibility would be to
interpred marker=(0,0) to plot only single points
instead of Polygons. This can be useful when plotting a
large number of data-points, e.g. stars in an N-Body
simulation of a galaxy collision.
I also attached an example file, scatter_example.py, and its output,
scatter_example.png.

Norbert Nemec wrote:
> OK, I found the problem and committed a temporary fix. The real problem,
> however is rooted a bit deeper.
> 
> First an explanation of the intended change:
> 
> It used to be that marker colors were partly automatic, but not
> completely. I.e.
> 
> plot(x,y,'-or')
> 
> would set both, line color and marker color to red. However
> 
> plot(x,y,color='r')
> 
> would set only the line color and leave marker color to the default.
> My change was to introduce a special value 'auto' for markeredgecolor and
> markerfacecolor. This special value would cause the marker color to
> always follow
> the line color. (Which is, in 99% of the cases, what you want.) Most of
> the special logic in axes.py could therefore go away. mfc and mec would
> simply be left at 'auto' unless explicitely assigned another color. The
> handling of the special value would then happen in lines.py at time of
> plotting. (including the effect that for filled markers, the edge would
> default to black)
> 
In your explanation above, it is not clear what happens in each of the 4 
cases: mec auto or non-auto, and mfc auto or non-auto.
In looking at your original patch, I also wondered what is the reason 
for supporting 3 different ways of specifying "_draw_nothing"? (I had 
not previously noticed that there was any such thing at all, and I guess 
I don't understand what it is for.)
class Line2D(Artist):
 _lineStyles = {
 '-' : '_draw_solid',
 '--' : '_draw_dashed',
 '-.' : '_draw_dash_dot',
 ':' : '_draw_dotted',
 'steps': '_draw_steps',
 'None' : '_draw_nothing',
 ' ' : '_draw_nothing',
 '' : '_draw_nothing',
 }
I was also a little uncomfortable with pushing some of the color 
decision logic all the way down into the draw method, together with a 
default value, although maybe there is no better way to get the desired 
behavior:
 if self._marker is not None:
 gc = renderer.new_gc()
 if (is_string_like(self._markeredgecolor) and
 self._markeredgecolor == 'auto'):
 if self._marker in self.filled_markers:
 gc.set_foreground('k')
 else:
 gc.set_foreground(self._color)
 else:
 gc.set_foreground(self._markeredgecolor)
> 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.
> 
> The (temporary) solution in r2800: I deactivated the
> rcfile-configurability of markeredgecolor and markerfacecolor. Assuming
> that hardly anybody would want to change the 'auto' behavior in their
> rcfile, this should be a good solution until we have solved the core
> problem.
> 
> The core problem: The matplotlibrc file distributed with matplotlib
> contains all the default values in non-commented lines. This file is
> usually copied to the home-directory of any user, making it impossible
> to simply change any default value in later versions. It is not possible
> to find out which values in the users matplotlibrc were set on purpose
> and which were just left untouched from the distributed file.
> 
> The better solution: place '#' at the beginning of every line in
> matplotlibrc.template (except for 'backend' and 'numerix' which carry
> important information) Any user who explicitely wants to change a value,
> can simply uncomment the line and set a value. Otherwise, the default
> value from matplotlib/__init__.py will remain active, even if changed in
> an update. Of course, this would only make sense, if users were informed
> and encouraged to replace their personal matplotlibrc
This seems like a good idea, and one that is consistent with the way 
many other configurable systems are often handled. I think that 
regardless of what else is done, this would reduce pain during updates; 
it would also make it easier for the user to see what changes to the 
defaults he/she has made.
> 
> The ultimate solution: The file matplotlib.template should probably be
> dropped completely and be auto-created from the information in
> matplotlib/__init__.py - this would remove quite some redundancy and
> potential for inconsistencies.
Reducing redundancy is appealing, but I don't know if it would be worth 
the effort of implementing your auto-generation idea--which might add 
clutter and complexity to __init__.py.
Eric

OK, I found the problem and committed a temporary fix. The real problem,
however is rooted a bit deeper.
First an explanation of the intended change:
It used to be that marker colors were partly automatic, but not
completely. I.e.
 plot(x,y,'-or')
would set both, line color and marker color to red. However
 plot(x,y,color='r')
would set only the line color and leave marker color to the default.
My change was to introduce a special value 'auto' for markeredgecolor and
markerfacecolor. This special value would cause the marker color to
always follow
the line color. (Which is, in 99% of the cases, what you want.) Most of
the special logic in axes.py could therefore go away. mfc and mec would
simply be left at 'auto' unless explicitely assigned another color. The
handling of the special value would then happen in lines.py at time of
plotting. (including the effect that for filled markers, the edge would
default to black)
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.
The (temporary) solution in r2800: I deactivated the
rcfile-configurability of markeredgecolor and markerfacecolor. Assuming
that hardly anybody would want to change the 'auto' behavior in their
rcfile, this should be a good solution until we have solved the core
problem.
The core problem: The matplotlibrc file distributed with matplotlib
contains all the default values in non-commented lines. This file is
usually copied to the home-directory of any user, making it impossible
to simply change any default value in later versions. It is not possible
to find out which values in the users matplotlibrc were set on purpose
and which were just left untouched from the distributed file.
The better solution: place '#' at the beginning of every line in
matplotlibrc.template (except for 'backend' and 'numerix' which carry
important information) Any user who explicitely wants to change a value,
can simply uncomment the line and set a value. Otherwise, the default
value from matplotlib/__init__.py will remain active, even if changed in
an update. Of course, this would only make sense, if users were informed
and encouraged to replace their personal matplotlibrc
The ultimate solution: The file matplotlib.template should probably be
dropped completely and be auto-created from the information in
matplotlib/__init__.py - this would remove quite some redundancy and
potential for inconsistencies.
Comments on this?
Greetings,
Norbert
John Hunter wrote:
>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>>>>>> 
>
> Eric> So: please either restore your patch with additional changes
> Eric> to fix the problem Stefan found, or revert all of it cleanly
> Eric> until this can be sorted out.
>
> Norbert -- can you describe briefly the inconsistencies in the format
> arg color handling you were trying to address in your patch? I see
> this --
> http://sourceforge.net/tracker/index.php?func=detail&aid=1504387&group_id=80706&atid=560722
> -- but not much detail about the problems the changes fix. 
>
> Also, for all developers, when making API changes
>
> * post here with a brief descriptions of changes and rationale
>
> * make a note in API_CHANGES
>
> * run backend_driver.py. It is a good habit to not only run the
> script to make sure no exceptions are raised, but also to view
> the output PNG etc files in your favorite image viewer to make
> sure the output is correct
>
>
> Thanks!
> JDH
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> 

OK, I understand. I will try sort out the problem today or otherwise
take back the whole patch.
I had not seen the message in matplotlib-users because of the backlog of
400 messages that have kept piling up...
Don't worry about additional confusion. Quickly reverting the patch was
the best thing to do for the moment.
Greetings,
Norbert
Eric Firing wrote:
> Norbert,
>
> Your 2790 patch seems to have completely wiped out the handling of 
> marker colors in the simple case "N.plot(N.random.random(1000),'r.')", 
> as noted by Stefan Van der Walt in a message yesterday to the matplotlib 
> users list. I presume you are monitoring that list, and saw his message 
> and my reply in which I noted that I was reverting the changes to 
> axes.py. I looked at the changes to axes.py, and it appeared that you 
> had simply forgotten the marker color handling; otherwise, the changes 
> appeared to be code rearrangements, not API changes that would interact 
> with other files, so I thought that reverting that file alone would 
> work--that is, restore basic functionality to the svn version. My 
> original thought was to wait and let you fix it, and evidently I should 
> have, but I decided it would be better not to leave svn without the 
> marker color functionality in the interim, and I had no way of knowing 
> whether you would be able to get to it right away. In any case, I made 
> the change, verified that it did restore marker color handling, 
> committed it to svn, and left it at that.
>
> Of course I was too hasty, and neglected to look at the patch as a 
> whole; now I see that you were trying to shift the setting of marker 
> colors out of axes.py and into lines.py. I still don't know why 
> Stefan's simple example was broken, and I don't have time now to 
> understand your patch properly, though I wish I did. I certainly don't 
> object to the idea of trying to make the code cleaner and easier to follow.
>
> So: please either restore your patch with additional changes to fix the 
> problem Stefan found, or revert all of it cleanly until this can be 
> sorted out.
>
> If you think there might be incompatibilities introduced by your patch, 
> then it would be good to know what they are.
>
> Sorry to have made the situation more confusing than necessary.
>
> Eric
>
>
>
>
> Norbert Nemec wrote:
> 
>> Hi Eric, hi everybody,
>>
>> I just noticed that you, Eric, have committed r2799 to SVN which partly
>> reverts my commit r2790.
>>
>> I understand that, obviously, the changes that I introduced are more
>> controversial than I would have expected, so we should try to reach an
>> agreement.
>>
>> Was your objection generally about my patch or just about some detail? I
>> know that the patch might have broken a bit of compatibility, but since
>> the old logic was inconsistent and hard to understand, I figured that a
>> cleaner and simpler logic would justify a some possible break of
>> compatibility.
>>
>> If you disagree with some change in principle, I would like to know your
>> objection. If there simply was a bug introduced by the change, I
>> appologize and hope I can fix it.
>>
>> In any case, I have to point out that the current state of the SVN code
>> after the partial reversion of my commit is not self-consistent: My
>> commit changed several files besides axes.py - only reverting this one
>> file is bound to cause problems.
>>
>> Greetings,
>> Norbert
>> 
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> 

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> So: please either restore your patch with additional changes
 Eric> to fix the problem Stefan found, or revert all of it cleanly
 Eric> until this can be sorted out.
Norbert -- can you describe briefly the inconsistencies in the format
arg color handling you were trying to address in your patch? I see
this --
http://sourceforge.net/tracker/index.php?func=detail&aid=1504387&group_id=80706&atid=560722
-- but not much detail about the problems the changes fix. 
Also, for all developers, when making API changes
 * post here with a brief descriptions of changes and rationale
 * make a note in API_CHANGES
 * run backend_driver.py. It is a good habit to not only run the
 script to make sure no exceptions are raised, but also to view
 the output PNG etc files in your favorite image viewer to make
 sure the output is correct
Thanks!
JDH

Norbert,
Your 2790 patch seems to have completely wiped out the handling of 
marker colors in the simple case "N.plot(N.random.random(1000),'r.')", 
as noted by Stefan Van der Walt in a message yesterday to the matplotlib 
users list. I presume you are monitoring that list, and saw his message 
and my reply in which I noted that I was reverting the changes to 
axes.py. I looked at the changes to axes.py, and it appeared that you 
had simply forgotten the marker color handling; otherwise, the changes 
appeared to be code rearrangements, not API changes that would interact 
with other files, so I thought that reverting that file alone would 
work--that is, restore basic functionality to the svn version. My 
original thought was to wait and let you fix it, and evidently I should 
have, but I decided it would be better not to leave svn without the 
marker color functionality in the interim, and I had no way of knowing 
whether you would be able to get to it right away. In any case, I made 
the change, verified that it did restore marker color handling, 
committed it to svn, and left it at that.
Of course I was too hasty, and neglected to look at the patch as a 
whole; now I see that you were trying to shift the setting of marker 
colors out of axes.py and into lines.py. I still don't know why 
Stefan's simple example was broken, and I don't have time now to 
understand your patch properly, though I wish I did. I certainly don't 
object to the idea of trying to make the code cleaner and easier to follow.
So: please either restore your patch with additional changes to fix the 
problem Stefan found, or revert all of it cleanly until this can be 
sorted out.
If you think there might be incompatibilities introduced by your patch, 
then it would be good to know what they are.
Sorry to have made the situation more confusing than necessary.
Eric
Norbert Nemec wrote:
> Hi Eric, hi everybody,
> 
> I just noticed that you, Eric, have committed r2799 to SVN which partly
> reverts my commit r2790.
> 
> I understand that, obviously, the changes that I introduced are more
> controversial than I would have expected, so we should try to reach an
> agreement.
> 
> Was your objection generally about my patch or just about some detail? I
> know that the patch might have broken a bit of compatibility, but since
> the old logic was inconsistent and hard to understand, I figured that a
> cleaner and simpler logic would justify a some possible break of
> compatibility.
> 
> If you disagree with some change in principle, I would like to know your
> objection. If there simply was a bug introduced by the change, I
> appologize and hope I can fix it.
> 
> In any case, I have to point out that the current state of the SVN code
> after the partial reversion of my commit is not self-consistent: My
> commit changed several files besides axes.py - only reverting this one
> file is bound to cause problems.
> 
> Greetings,
> Norbert

Hi Eric, hi everybody,
I just noticed that you, Eric, have committed r2799 to SVN which partly
reverts my commit r2790.
I understand that, obviously, the changes that I introduced are more
controversial than I would have expected, so we should try to reach an
agreement.
Was your objection generally about my patch or just about some detail? I
know that the patch might have broken a bit of compatibility, but since
the old logic was inconsistent and hard to understand, I figured that a
cleaner and simpler logic would justify a some possible break of
compatibility.
If you disagree with some change in principle, I would like to know your
objection. If there simply was a bug introduced by the change, I
appologize and hope I can fix it.
In any case, I have to point out that the current state of the SVN code
after the partial reversion of my commit is not self-consistent: My
commit changed several files besides axes.py - only reverting this one
file is bound to cause problems.
Greetings,
Norbert

Forwarded as requested....
On 10/8/06, Gael Varoquaux <gae...@no...> wrote:
> My apologies, I cannot post to any SF mailing lists currently. Could one
> of you (whoever sees this first) forward this message to matplotlib-dev,
> I can still receive post coming from there.
>
> I am really sorry to ask you such a service.
>
> Thanks a lot,
>
> Ga=EBl
>
> From: Gael Varoquaux <gael_dot_varoquaux_at_normalesup_dot_org>
> To: Matplotlib-devel <matplotlib-devel_at_lists_dot_sourceforge_dot_net>
> Subject: Good method for updating an imshow plot
>
> Hi,
>
> This does not belong to the devel mailing list, but to the users, but I
> cannon subscribe to the users, as my SMTP is black listed by SpamCop
> (screw them, the server isn't sending a single spam).
>
> My question is: what is the correct way to plot a matrix with an imshow,
> and then update this matrix on the plot. I am more interested by the mpl
> way of doing this, rather than the pylab way. The idea would be to
> replace the following pylab commands by something cleaner that would
> involve recreating axes:
>
> imshow(z1)
> clf()
> imshow(z2)
>
> Cheers,
>
>
> Ga=EBl
>

Hi,
I'll do these patches a little at a time.
Here is a patch to show a complex spectrogram with the negative frequencies
flipped down. I've also attached a modified version of the
spectrogram_demo.py that creates the two signals as complex exponentials so
they are only in one half of the spectrum (long signal positive, short
signal negative).
Basically, if the input signal is complex then the whole spectrogram is
shown. If the input is real then just the positive frequencies are shown.
Next I'll work on the following as discussed.
Thanks
Greg
On 10/6/06, John Hunter <jdh...@ac...> wrote:
>
> >>>>> "Greg" == Greg Willden <gre...@gm...> writes:
> Greg> c) Modify specgram so that if it
> Greg> receives an array as the window parameter it checks its
> Greg> length and then applies it as a window. If the window
> Greg> parameter is not an array then it treats it as a function
> Greg> (current behaviour)
>
> This is fine -- I suggest using the matplotlib.cookbook.iterable
> function or the python builtin callable function to do the check.
> Whatever changes you make for specgram should also be ported into psd,
> csd and cohere.
>
-- 
Linux. Because rebooting is for adding hardware.

>>>>> "Greg" == Greg Willden <gre...@gm...> writes:
 Greg> Hi All, I'm a longtime Matlab user. I've been using Python
 Greg> for a year or two and have begun using
 Greg> Matplotlib/Numpy/Scipy. I have a patch for specgram() that
 Greg> will plot the spectrogram with the positive and negative
 Greg> frequencies flipped (fftshift). This is the way that you
 Greg> would examine the complex data coming out of a receiver.
 Greg> What is the prefered method for submitting patches? I
 Greg> didn't find any information on the website.
The best way is to add them as patches to the sf site and then post
here with a link to the patch (and attach the patch if possible). I
tend to monitor this list much more closely, but it is nice to have it
on the sf site if it falls between the cracks because it is easier for
someone to pick it up later. If you get no action in a week or two,
ping us again.
 Greg> Also, I would like to add support for more window functions
 Greg> in specgram(). I see three options for doing this: a) Add
 Greg> the window functions directly ( drawback: code duplication)
 Greg> b) Add wrappers for the window functions in SciPy (drawback:
 Greg> additional dependencies?) 
We are trying to move away from adding our own numerical code and have
this go into numpy/scipy. I suggest adding a docstring saying,
additional window functions a,b and c are available in
somepackage.somemodule
 Greg> c) Modify specgram so that if it
 Greg> receives an array as the window parameter it checks its
 Greg> length and then applies it as a window. If the window
 Greg> parameter is not an array then it treats it as a function
 Greg> (current behaviour)
This is fine -- I suggest using the matplotlib.cookbook.iterable
function or the python builtin callable function to do the check.
Whatever changes you make for specgram should also be ported into psd,
csd and cohere.
Thanks,
JDH

Hi All,
I'm a longtime Matlab user. I've been using Python for a year or two and
have begun using Matplotlib/Numpy/Scipy. I have a patch for specgram() that
will plot the spectrogram with the positive and negative frequencies flipped
(fftshift). This is the way that you would examine the complex data coming
out of a receiver.
What is the prefered method for submitting patches? I didn't find any
information on the website.
Also, I would like to add support for more window functions in specgram().
I see three options for doing this:
a) Add the window functions directly ( drawback: code duplication)
b) Add wrappers for the window functions in SciPy (drawback: additional
dependencies?)
c) Modify specgram so that if it receives an array as the window parameter
it checks its length and then applies it as a window. If the window
parameter is not an array then it treats it as a function (current
behaviour)
I guess there is also
d) Only change the docstring to show how to supply your own window function;
perhaps using one from scipy.
Comments?
Thanks.
Greg
-- 
Linux. Because rebooting is for adding hardware.

The mailing lists have been down for a few days, and this is a test.
Charlie

matplotlib-0.87.6 works fine on AIX 5.1, with gcc 3.2.2 and python 2.5 .
I've not compiled it with GTK or TK support but the Agg backend works.
Would it be possible for a developer to modify the code to include AIX
in the supported OS list? I always have change this structure in
setupext.py manually:
basedir = {
 'win32' : ['win32_static',],
 'linux2' : ['/usr/local', '/usr',],
 'linux' : ['/usr/local', '/usr',],
 'cygwin' : ['/usr/local', '/usr',],
 'darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219',
'/usr/local',
 '/usr', '/sw'],
 'freebsd4' : ['/usr/local', '/usr'],
 'freebsd5' : ['/usr/local', '/usr'],
 'freebsd6' : ['/usr/local', '/usr'],
 'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
 'gnukfreebsd5' : ['/usr/local', '/usr'],
 'gnukfreebsd6' : ['/usr/local', '/usr'],
}
To add the entry:
 'aix5' : [/usr/local],
Thanks for making this wonderful library available!
Mike.