matplotlib-devel Mailing List for matplotlib (Page 3)

This is definitely a bug, but I thought I'd clarify and add in a little more...

The distinction between 'step' and 'stepfilled' is that 'step' is
supposed to show only the outline of the histogram with no lines in
between bins (standard practice in some fields), while 'stepfilled' is
supposed to do the same, but have a different-colored fill between the
steps and the x-axis.  This is different from 'bar' because the bars
always have either an outline bounding each bar, or no outline at all.
 An alternative approach, presumably, would be to eliminate
'stepfilled' and instead just pass in some keyword that tells whether
or not to draw the filled color region or not, but that was judged
confusing because it would have no meaning for the bar types.

As for the log=True errors, I think what this was supposed to do was
have the minimum number of bin *counts* be the replacement for 0s,
rather the minimum *value*, so that's just a pure bug.  This is might
have been my fault - the code has changed quite a bit from the
original patch, so I'm not sure at this point.  The logic was that
this makes more sense than arbitrarily choosing 1 - if you have a
histogram where the bins are all within, say, 1000 and 10000, but one
of them is 0, it perhaps looks better to set the bottom to the 1000
rather than 1... It was really just an arbitrary choice that no one
objected to at the time.

As I think about it, it might make sense to change it so that the log
keyword can be used to set the assumed minimum value for empty bins if
it is greater than 0 (and stick with the default you suggested of 1 if
log=True).  The attached patch includes this change, adopted from
Ben's original patch, as well as clarifying all of this in teh
docstring.


On Wed, Aug 11, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root <ben...@ou...> wrote:
>>
>> I am tracing down a bug in hist() and I am trying to figure out what is it
>> about the 'stepfilled' mode that is different from the regular 'bar' mode.
>> Currently, the hist() code has a separate if branch for dealing with 'step'
>> and 'stepfilled', and that branch has a bunch of bugs.  The best that I can
>> figure is that it prevents lines from being drawn in between the bins.  If
>> that is the only difference, maybe we could somehow use the bar functions?
>>
>> At the very least, I think this needs to be documented better to make it
>> clear why this oddball approach is happening.
>>
>> Thanks,
>> Ben Root
>
> By the way, the bugs I was referring to both have to do with log=True and
> the two stepped modes.
>
> First, the smallest of values to histogram (the minimum bin value) is, for
> some reason, used to clip the lower bounds of the histogram count. In some
> situations, this can result in most if not all the graph not being shown.
>
> Second, related to the first is a problem with the 'stepfilled' mode in log
> space.  The stepfilled mode uses the minimum bin value to anchor the
> patches.  However, this can cause the polygon to not close correctly and can
> get some unsightly artifacts. I have attached an image demonstrating this
> bug.  This has been reported before:
>
> http://old.nabble.com/hist%28%29-with-log-and-step-tp28888742p28888742.html
> http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html
>
> In one of the comments, the reporter concluded that it appeared fixed, but
> either he was experiencing a slightly different problem, or he was mistaken.
>
> I have also included a possible patch for addressing these issues.  The
> approach simply sets the minimum value to be zero when not doing log, and
> use 1.0 when log=True.  This differs slightly from how the normal bar graphs
> are done where a value of 1e-100 is used when log=True, but then the axes
> limits are adjusted to use 1.0 as a lower limit.
>
> Cheers,
> Ben Root
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>



-- 
Erik Tollerud

On 08/23/2010 05:17 AM, John Hunter wrote:
> On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing<ef...@ha...>  wrote:
>> Mike, John, or anyone else who works directly with Ticks:
>>
>> I think you are the only ones who have worked with the code I suggest
>> changing as in the attached diff.  It looks to me like the three *Tick
>> methods, set_view_interval(), get_minpos(), get_data_interval(), are unused
>> and unlikely ever to have been or to be used.  I particularly object to the
>> first of these because I don't think a Tick has any business changing the
>> view interval.  The other two look like clutter, harmless except insofar as
>> they make it harder to understand the code. If some projection actually does
>> end up needing the functionality in any of these methods, it is still
>> available via *Tick.axes.xaxis.* etc.
>>
>> Am I missing something?  If not, I will commit this to the trunk.  This is a
>> case where I think immediate surgery is better than a deprecation process.
>
> I'm OK with removing them, and I don't feel strongly about deprecation
> with a helpful suggestion or radical mastectomy, though the former
> seems a little gentler.  This should go into the trunk only since it
> is API breaking.
>
> JDH

Committed to the trunk in r8655. I agree that deprecation is gentler, 
and that is the route I usually take; but given the obscurity of the 
Tick classes and the oddness of these methods in that class, I'm taking 
a chance on just getting it over with now.  Time will tell whether it is 
a mistake.  If it is, it won't be the first or the last.

Eric


>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing <ef...@ha...> wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest
> changing as in the attached diff.  It looks to me like the three *Tick
> methods, set_view_interval(), get_minpos(), get_data_interval(), are unused
> and unlikely ever to have been or to be used.  I particularly object to the
> first of these because I don't think a Tick has any business changing the
> view interval.  The other two look like clutter, harmless except insofar as
> they make it harder to understand the code. If some projection actually does
> end up needing the functionality in any of these methods, it is still
> available via *Tick.axes.xaxis.* etc.
>
> Am I missing something?  If not, I will commit this to the trunk.  This is a
> case where I think immediate surgery is better than a deprecation process.

I'm OK with removing them, and I don't feel strongly about deprecation
with a helpful suggestion or radical mastectomy, though the former
seems a little gentler.  This should go into the trunk only since it
is API breaking.

JDH

I think you're right about this.

Mike

On 08/21/2010 03:08 PM, Eric Firing wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest 
> changing as in the attached diff.  It looks to me like the three *Tick 
> methods, set_view_interval(), get_minpos(), get_data_interval(), are 
> unused and unlikely ever to have been or to be used.  I particularly 
> object to the first of these because I don't think a Tick has any 
> business changing the view interval.  The other two look like clutter, 
> harmless except insofar as they make it harder to understand the code. 
> If some projection actually does end up needing the functionality in 
> any of these methods, it is still available via *Tick.axes.xaxis.* etc.
>
> Am I missing something?  If not, I will commit this to the trunk.  
> This is a case where I think immediate surgery is better than a 
> deprecation process.
>
> Thanks.
>
> Eric


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 8/21/10 12:08 PM, Eric Firing wrote:
> Mike, John, or anyone else who works directly with Ticks:
>
> I think you are the only ones who have worked with the code I suggest 
> changing as in the attached diff.  It looks to me like the three *Tick 
> methods, set_view_interval(), get_minpos(), get_data_interval(), are 
> unused and unlikely ever to have been or to be used.  I particularly 
> object to the first of these because I don't think a Tick has any 
> business changing the view interval.  The other two look like clutter, 
> harmless except insofar as they make it harder to understand the code. 
> If some projection actually does end up needing the functionality in 
> any of these methods, it is still available via *Tick.axes.xaxis.* etc.
>
> Am I missing something?  If not, I will commit this to the trunk.  
> This is a case where I think immediate surgery is better than a 
> deprecation process.
Hi Eric,

In general I'm all for it - simplicity is good. Just make sure that it 
doesn't break the spine placement code (e.g. 
examples/pylab_demo/spine_placement_demo.py ) -- I remember those method 
names from the time when I was working on the spines. I don't remember 
any deep issues, but it's long enough ago now that I don't remember the 
details.

Thanks,
Andrew

Mike, John, or anyone else who works directly with Ticks:

I think you are the only ones who have worked with the code I suggest 
changing as in the attached diff.  It looks to me like the three *Tick 
methods, set_view_interval(), get_minpos(), get_data_interval(), are 
unused and unlikely ever to have been or to be used.  I particularly 
object to the first of these because I don't think a Tick has any 
business changing the view interval.  The other two look like clutter, 
harmless except insofar as they make it harder to understand the code. 
If some projection actually does end up needing the functionality in any 
of these methods, it is still available via *Tick.axes.xaxis.* etc.

Am I missing something?  If not, I will commit this to the trunk.  This 
is a case where I think immediate surgery is better than a deprecation 
process.

Thanks.

Eric

Hey, it's getting vivid!  Nice!

2010/8/19 Benjamin Root <ben...@ou...>:
> Neat!  I have been sticking mainly to the front-end parts of matplotlib with
> only a vague understanding of the backend/core pieces.  I am learning more
> all the time.

I'm diving sometimes into matplotlib code, but this is the deepest
glimpse I have reached so far ...

>> > By the time we get to the backends, all the color data should be in a
>> > clean,
>> > broadcasted rgba form, so it should then be a relatively simple check of
>> > the
>> > grey flag before writing out the color information.
>>
>> Mmmh, for some reason colorConverter is used there again, maybe
>> historical.
>>
>
> Might be a good idea to try and make a flowchart of some sort and codify
> where and when certain things should be done and strive for that
> organization.

Maybe it would be good contribution to the developer's documentation
of *how matplotlib works*.

> I hope it isn't the blind leading the blind here.  I tend to get lots of
> crazy design ideas, especially when dealing with overall architecture, even
> without fully understanding exactly how things work.

haha!  Seems that we are similar in this respect.  But in this case, I
really tried to tell only ideas which are verified to work from
inspection of the code afaict.

> Do you have a github account?  Maybe we can fork Andrew Straw's repo and
> bang on this for a on a separate branch.  I have about a week and a half
> left before I have to divert my full attention to a month-long project.

It's a good idea, my account is friedrichromstedt, maybe you can fork
and add me as an collaborator?

> Maybe we should also start up another thread summarizing some of the ideas
> that has been passed around in this thread and make a prioritized ToDo list
> with milestones?

How long do you think will this gray thingy take?  My plan was to
finish next week by Friday.

I hope I will get a whole picture today night.

Friedrich

On Wed, Aug 18, 2010 at 2:08 PM, Friedrich Romstedt <
fri...@gm...> wrote:

> 2010/8/18 Benjamin Root <ben...@ou...>:
> > I had a thought... and it is based on my admittedly incomplete
> understanding
> > of matplotlib.  Everything that gets drawn is derived from the artist
> class,
> > right?  So, what if there was a 'grey' boolean in that base class, and
> the
> > .draw() function passes that bool down through all the subsequent .draw()
> > calls of its child objects (it could be None by default to accept the
> > parent's property, or allowed to be explicitly set by the user to
> override
> > the parent's value.)
>
> It's a neat idea again.  I like it very much.  I propose the following:
>
> 1)  As you said, a gray flag in mpl.artist.Artist, which can be
> automatically transmitted to the child artists *on render time*.
>
> 2)  Counting the "grayishness" (single, double, ... :-) in
> mpl.backends.renderer_bases.RendererBase.
>
> 3)  Evaluating the grayishness in
> mpl.backends.renderer_bases.RendererBase.new_gc() [i.e., new graphics
> context].  Passing it on to the GraphicsContext as initialisaion
> argument.  mpl.backends.renderer_bases.GraphicsContextBase has ONLY
> ONE COLOUR ARGUMENT, namely .set_foreground().  It seems everythings
> breaks down to foreground rendering of pathes and symbols.  Indeed, it
> uses once again mpl.colors.colorConverter, and I think my refactoring
> of this one is not useless at all, but the main point is, it stores an
> rgb colour in the end, and in fact *all* rgb colours ever used in any
> graphics drawing context.  Also for text, etc. pp.
>
> 4)  Introducing a decorator:
>
> def draw_with_grayishness(fn):
>        def decorated(self, renderer):
>                if self.is_gray():
>                        renderer.increase_grayishness()
>                        fn(self, renderer)
>                        renderer.decrease_grayishness()
>                else:
>                        fn(self, renderer)
>
>        return decorated
>
> This turns on grayishness in the renderer if it is requested by
> *self*, which is an Artist.
>
>
Neat!  I have been sticking mainly to the front-end parts of matplotlib with
only a vague understanding of the backend/core pieces.  I am learning more
all the time.


> > By the time we get to the backends, all the color data should be in a
> clean,
> > broadcasted rgba form, so it should then be a relatively simple check of
> the
> > grey flag before writing out the color information.
>
> Mmmh, for some reason colorConverter is used there again, maybe historical.
>
>
Might be a good idea to try and make a flowchart of some sort and codify
where and when certain things should be done and strive for that
organization.


>  > Admittedly, I would much rather have this flag check done before getting
> to
> > the backends and through a single point of code.  At first, I thought
> that
> > ColorConverter would be it, but as I now understand it, it is treated
> more
> > like a utility module rather than an important step in the rendering
> > process.  It gets used for things at different points in the matplotlib
> > process.
>
> Yes, it's not the only point, there is at least one more,
> mpl.collection.Collection.update_scalaramappable().  And there may be
> tons of other selfish procedures ... So I agree fully with you.
>
> > Maybe I am just going overboard here...
>
> Well, I come with you :-)
>
>
I hope it isn't the blind leading the blind here.  I tend to get lots of
crazy design ideas, especially when dealing with overall architecture, even
without fully understanding exactly how things work.


> So, the code point would be outside of the Renderer, but in the
> GraphicsContext, which is abstract enough to be shared by all
> implementations of the rendering.  It is passed on to the
> implementation's methods as an argument, so its .foreground or
> whatever is the same to all rendering implementations.
>
> Friedrich
>

Do you have a github account?  Maybe we can fork Andrew Straw's repo and
bang on this for a on a separate branch.  I have about a week and a half
left before I have to divert my full attention to a month-long project.

Maybe we should also start up another thread summarizing some of the ideas
that has been passed around in this thread and make a prioritized ToDo list
with milestones?

Ben Root

2010/8/18 Benjamin Root <ben...@ou...>:
> I had a thought... and it is based on my admittedly incomplete understanding
> of matplotlib.  Everything that gets drawn is derived from the artist class,
> right?  So, what if there was a 'grey' boolean in that base class, and the
> .draw() function passes that bool down through all the subsequent .draw()
> calls of its child objects (it could be None by default to accept the
> parent's property, or allowed to be explicitly set by the user to override
> the parent's value.)

It's a neat idea again.  I like it very much.  I propose the following:

1)  As you said, a gray flag in mpl.artist.Artist, which can be
automatically transmitted to the child artists *on render time*.

2)  Counting the "grayishness" (single, double, ... :-) in
mpl.backends.renderer_bases.RendererBase.

3)  Evaluating the grayishness in
mpl.backends.renderer_bases.RendererBase.new_gc() [i.e., new graphics
context].  Passing it on to the GraphicsContext as initialisaion
argument.  mpl.backends.renderer_bases.GraphicsContextBase has ONLY
ONE COLOUR ARGUMENT, namely .set_foreground().  It seems everythings
breaks down to foreground rendering of pathes and symbols.  Indeed, it
uses once again mpl.colors.colorConverter, and I think my refactoring
of this one is not useless at all, but the main point is, it stores an
rgb colour in the end, and in fact *all* rgb colours ever used in any
graphics drawing context.  Also for text, etc. pp.

4)  Introducing a decorator:

def draw_with_grayishness(fn):
	def decorated(self, renderer):
		if self.is_gray():
			renderer.increase_grayishness()
			fn(self, renderer)
			renderer.decrease_grayishness()
		else:
			fn(self, renderer)
	
	return decorated

This turns on grayishness in the renderer if it is requested by
*self*, which is an Artist.

> By the time we get to the backends, all the color data should be in a clean,
> broadcasted rgba form, so it should then be a relatively simple check of the
> grey flag before writing out the color information.

Mmmh, for some reason colorConverter is used there again, maybe historical.

> Admittedly, I would much rather have this flag check done before getting to
> the backends and through a single point of code.  At first, I thought that
> ColorConverter would be it, but as I now understand it, it is treated more
> like a utility module rather than an important step in the rendering
> process.  It gets used for things at different points in the matplotlib
> process.

Yes, it's not the only point, there is at least one more,
mpl.collection.Collection.update_scalaramappable().  And there may be
tons of other selfish procedures ... So I agree fully with you.

> Maybe I am just going overboard here...

Well, I come with you :-)

So, the code point would be outside of the Renderer, but in the
GraphicsContext, which is abstract enough to be shared by all
implementations of the rendering.  It is passed on to the
implementation's methods as an argument, so its .foreground or
whatever is the same to all rendering implementations.

Friedrich

Sure:

--- axis.py     2010-08-18 09:59:25.000000000 -0400
+++ axis.py.orig        2010-08-18 09:58:13.000000000 -0400
@@ -1049,12 +1049,9 @@
     def _get_offset_text(self):
         raise NotImplementedError('Derived must override')

-    def get_gridlines(self,minor=False):
+    def get_gridlines(self):
         'Return the grid lines as a list of Line2D instance'
-        if minor:
-           ticks = self.get_minor_ticks()
-        else:
-           ticks = self.get_major_ticks()
+        ticks = self.get_major_ticks()
         return cbook.silent_list('Line2D gridline', [tick.gridline for tick
in ticks])

     def get_label(self):


On Wed, Aug 18, 2010 at 1:05 PM, Ryan May <rm...@gm...> wrote:

> On Wed, Aug 18, 2010 at 9:25 AM, Daniel Hyams <dh...@gm...> wrote:
> > This is a small patch to enable get_gridlines to be able to get the grid
> > lines for the minor ticks as well.
> > 1052c1052
> > <     def get_gridlines(self):
> > ---
> >>     def get_gridlines(self,minor=False):
> > 1054c1054,1055
> > <         ticks = self.get_major_ticks()
> > ---
> >>         if minor: ticks = self.get_minor_ticks()
> >>         else:     ticks = self.get_major_ticks()
>
> Thanks for the contribution. Can you regenerate using: diff -u
> so we can easily apply to the tree?
>
> Thanks,
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>



-- 
Daniel Hyams
dh...@gm...

On Wed, Aug 18, 2010 at 9:25 AM, Daniel Hyams <dh...@gm...> wrote:
> This is a small patch to enable get_gridlines to be able to get the grid
> lines for the minor ticks as well.
> 1052c1052
> <     def get_gridlines(self):
> ---
>>     def get_gridlines(self,minor=False):
> 1054c1054,1055
> <         ticks = self.get_major_ticks()
> ---
>>         if minor: ticks = self.get_minor_ticks()
>>         else:     ticks = self.get_major_ticks()

Thanks for the contribution. Can you regenerate using: diff -u
so we can easily apply to the tree?

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I can confirm that this now works fine - thanks for the quick fix!

Tom

On Aug 18, 2010, at 12:09 PM, Michael Droettboom wrote:

> Should be fixed in r8648 now.
> 
> Mike
> 
> On 08/18/2010 11:45 AM, Thomas Robitaille wrote:
>> Hi,
>> 
>> I updated to the latest svn version of matplotlib this morning, and Axes.scatter seems to be broken when using marker='v', '>','<', or '^':
>> 
>> import matplotlib
>> matplotlib.use('Agg')
>> import matplotlib.pyplot as mpl
>> 
>> fig = mpl.figure()
>> ax = fig.add_subplot(1,1,1)
>> ax.scatter([1,2,3], [4,5,6], marker='v')
>> fig.savefig('test.png')
>> 
>> gives:
>> 
>> Traceback (most recent call last):
>>   File "test.py", line 7, in<module>
>>     ax.scatter([1,2,3], [4,5,6], marker='^')
>>   File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/axes.py", line 5764, in scatter
>>     transOffset = self.transData,
>>   File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 695, in __init__
>>     self._paths = [self._path_generator(numsides)]
>>   File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 415, in unit_regular_polygon
>>     path = cls(verts, codes)
>>   File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 117, in __init__
>>     assert len(codes) == len(vertices)
>> AssertionError
>> 
>> This did not occur when I updated to the latest svn a couple of days ago, so it must be due to a pretty recent change.
>> 
>> Cheers,
>> 
>> Tom
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>> 
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by 
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Should be fixed in r8648 now.

Mike

On 08/18/2010 11:45 AM, Thomas Robitaille wrote:
> Hi,
>
> I updated to the latest svn version of matplotlib this morning, and Axes.scatter seems to be broken when using marker='v', '>','<', or '^':
>
> import matplotlib
> matplotlib.use('Agg')
> import matplotlib.pyplot as mpl
>
> fig = mpl.figure()
> ax = fig.add_subplot(1,1,1)
> ax.scatter([1,2,3], [4,5,6], marker='v')
> fig.savefig('test.png')
>
> gives:
>
> Traceback (most recent call last):
>    File "test.py", line 7, in<module>
>      ax.scatter([1,2,3], [4,5,6], marker='^')
>    File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/axes.py", line 5764, in scatter
>      transOffset = self.transData,
>    File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 695, in __init__
>      self._paths = [self._path_generator(numsides)]
>    File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 415, in unit_regular_polygon
>      path = cls(verts, codes)
>    File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 117, in __init__
>      assert len(codes) == len(vertices)
> AssertionError
>
> This did not occur when I updated to the latest svn a couple of days ago, so it must be due to a pretty recent change.
>
> Cheers,
>
> Tom
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi,

I updated to the latest svn version of matplotlib this morning, and Axes.scatter seems to be broken when using marker='v', '>', '<', or '^':

import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as mpl

fig = mpl.figure()
ax = fig.add_subplot(1,1,1)
ax.scatter([1,2,3], [4,5,6], marker='v')
fig.savefig('test.png')

gives:

Traceback (most recent call last):
  File "test.py", line 7, in <module>
    ax.scatter([1,2,3], [4,5,6], marker='^')
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/axes.py", line 5764, in scatter
    transOffset = self.transData,
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/collections.py", line 695, in __init__
    self._paths = [self._path_generator(numsides)]
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 415, in unit_regular_polygon
    path = cls(verts, codes)
  File "/Users/tom/Library/Python/2.6/site-packages/matplotlib/path.py", line 117, in __init__
    assert len(codes) == len(vertices)
AssertionError

This did not occur when I updated to the latest svn a couple of days ago, so it must be due to a pretty recent change.

Cheers,

Tom

This is a small patch to enable get_gridlines to be able to get the grid
lines for the minor ticks as well.

1052c1052
<     def get_gridlines(self):
---
>     def get_gridlines(self,minor=False):
1054c1054,1055
<         ticks = self.get_major_ticks()
---
>         if minor: ticks = self.get_minor_ticks()
>         else:     ticks = self.get_major_ticks()



-- 
Daniel Hyams
dh...@gm...

On Tue, Aug 17, 2010 at 4:19 PM, Friedrich Romstedt <
fri...@gm...> wrote:

> 2010/8/17 Benjamin Root <ben...@ou...>:
> > "...it will not be necessary..."
> >
> > I think we are still getting confused here.  I was listing off several
> > different kinds of use-cases where one would like to have a mix of grey
> > colormaps and colored colormaps.  The reason I mention being able to save
> a
> > greyscale and a color version of the same figure is in the context of my
> > approach to solving this problem (the swapping out of colormaps).
> Honestly,
> > I think that your approach is better for dealing with that particular use
> > case.
>
> Okay, may be you're right and we should include the usecase you're
> having in mind.
>
> > However, I mention other cases where one is merely wanting a modified
> > version of a particular colormap to use, be it greyscale, or inverse, or
> > brighter/darker, etc.
>
> Yes, that's neat.
>
> >  What I envision your solution to be solving would be
> > something like this:
>
> > fig = plt.figure()
> > ax = fig.add_subplot(1, 2, 1)
> > ax.plot(np.linspace(1, 10, 10), np.linspace(2, 8, 10))
> > ax.plot(np.linspace(1, 10, 10), np.linspace(4, 9, 10))
> >
> > ax = fig.add_subplot(1, 2, 2)
> > ax.set_grey(True)
> > ax.plot(np.linspace(1, 10, 10), np.linspace(1, 8, 10))
> > ax.plot(np.linspace(1, 10, 10), np.linspace(3, 7, 10))
> > ax.plot(np.linspace(1, 10, 10), np.linspace(2, 9, 10))
>
> Hmm, that's much more complicated ... For Collections, one could set a
> local flag, but it would be nevertheless quite buried in the API ...
> When setting it in the axes, one has to care about all artists added
> later too, and all pathes an artist may sneak into the axes.
>
>
I had a thought... and it is based on my admittedly incomplete understanding
of matplotlib.  Everything that gets drawn is derived from the artist class,
right?  So, what if there was a 'grey' boolean in that base class, and the
.draw() function passes that bool down through all the subsequent .draw()
calls of its child objects (it could be None by default to accept the
parent's property, or allowed to be explicitly set by the user to override
the parent's value.)

By the time we get to the backends, all the color data should be in a clean,
broadcasted rgba form, so it should then be a relatively simple check of the
grey flag before writing out the color information.

Admittedly, I would much rather have this flag check done before getting to
the backends and through a single point of code.  At first, I thought that
ColorConverter would be it, but as I now understand it, it is treated more
like a utility module rather than an important step in the rendering
process.  It gets used for things at different points in the matplotlib
process.

Maybe I am just going overboard here...


> What I'm going to solve is simply a toplevel boolean 'gray' switch in
> the rcParams.  It's working in an abstract way.
>
> Maybe a complementary approach would be useful.  A global switch for
> everything, and more fine-tuning control coming from your side?
>
>
I think the issue with my approach is that it would only impact things that
uses colormaps.  Anything that explicitly sets its colors without a colormap
will be totally unaffected.


> For the "road map", I cannot put myself under strong pressure with
> this, I would say, although being a rather tiny thing, I will finish
> it until end of next week.
>
>
Can't wait to see what you have.


> Ahh, and shall we name the switch 'gray' or 'grey'
>
>
Heh, even matplotlib can't provide too much precedence here because it tries
to cater to both spellings (and I keep flipping back and forth due to a
stupid bug in the Ubuntu packaging that packaged a en_UK spell-checker
instead of en_US, but my Fedora setup has it right...).  I should note that
for Colormaps, there is only a "is_gray" function.

Cheers,
Ben Root

Hi,

I am hesitant to call the following a bug. It might just be a
misunderstanding on my side. Anyhow...

I am plotting a normal line collection and an "axvline" collection on
the same Axes. The latter is a collection of lines with data
coordinates for x and axes coordinates for y, using a blended
transform. I find that the data limits are messed up by the axvline
collection, which unexpectedly sets the bottom y limit to 0. This
results in a badly scaled plot when adjusting the view with
autoscale_view. Interestingly, this problem goes away if the normal
line collection is viewed first via autoscale_view, if the normal line
collection is replaced by a normal plot command, or if the axvline
collection is replaced by a normal axvline command. The problem
appears if the two collections are added to the Axes without an
autoscale_view in between.

I ran the code below with matplotlib trunk (SVN r8646) on Mac OS 10.5
with TkAgg backend. The same behaviour appears in matplotlib 0.99.1.1.
Please let me know if I am doing something obviously stupid,
especially in the way I create the axvline collection. At the moment I
am working around the behaviour by inserting an autoscale_view between
the two collections, so it is not a major show-stopper.

Regards,
Ludwig


### Start code snippet ###

import matplotlib as mpl
import matplotlib.pyplot as plt
import numpy as np

# Create sine wave to plot (offset from zero)
t = np.arange(200)
x = 10 + np.cos(2 * np.pi * t / 20)

plt.figure(1)
plt.clf()
ax = plt.gca()

# Add main plot as a line collection containing one segment
segments = mpl.collections.LineCollection([zip(t, x)])
ax.add_collection(segments)
print ax.dataLim
# Output: Bbox(array([[   0.,    9.], [ 199.,   11.]]))

# Uncommenting the line below actually fixes the problem...
#ax.autoscale_view()

# Add break lines as a collection of axvlines
breaks = np.arange(0, 200, 20)
transFixedY = mpl.transforms.blended_transform_factory(ax.transData,
ax.transAxes)
break_lines = mpl.collections.LineCollection([[(s, 0), (s, 1)] for s
in breaks], transform=transFixedY, colors='k', linewidths=0.5,
linestyles='dotted')
ax.add_collection(break_lines)
print ax.dataLim
# Output: Bbox(array([[   0.,    0.], [ 199.,   11.]]))
# Notice that y0 is now 0 instead of the expected 9

# Autoscaling now inserts a lot of space below the original plot
ax.autoscale_view()

### End code snippet ###

Eric Firing wrote:
> On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>   
>> I'm guessing some of Eric's recent changes to alpha handling in paths
>> require modifications to the MacOS X backend?
>>     
>
> Correct.  I'll fix it.
>   

I see the Mac OS X buildbot is back online now, so perhaps we could add
some unit tests that run on that backend? (I don't know the mac backend
at all -- is it possible for it to save output, or even to run without
access to the graphics system?)

-Andrew

On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>
> I've started to see these errors today:
>
> TypeError: function takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py",
> line 55, in draw_wrapper
>       draw(artist, renderer, *args, **kwargs)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/figure.py",
> line 738, in draw
>       if self.frameon: self.patch.draw(renderer)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py",
> line 55, in draw_wrapper
>       draw(artist, renderer, *args, **kwargs)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/patches.py",
> line 406, in draw
>       renderer.draw_path(gc, tpath, affine, rgbFace)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/backends/backend_macosx.py",
> line 54, in draw_path
>       gc.draw_path(path, transform, linewidth, rgbFace)
> TypeError: function takes exactly 3 arguments (4 given)
>
> I'm guessing some of Eric's recent changes to alpha handling in paths
> require modifications to the MacOS X backend?

Correct.  I'll fix it.

Eric

>
> -Jeff
>

I've started to see these errors today:

TypeError: function takes exactly 3 arguments (4 given)
Traceback (most recent call last):
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py", 
line 55, in draw_wrapper
     draw(artist, renderer, *args, **kwargs)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/figure.py", 
line 738, in draw
     if self.frameon: self.patch.draw(renderer)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py", 
line 55, in draw_wrapper
     draw(artist, renderer, *args, **kwargs)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/patches.py", 
line 406, in draw
     renderer.draw_path(gc, tpath, affine, rgbFace)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/backends/backend_macosx.py", 
line 54, in draw_path
     gc.draw_path(path, transform, linewidth, rgbFace)
TypeError: function takes exactly 3 arguments (4 given)

I'm guessing some of Eric's recent changes to alpha handling in paths 
require modifications to the MacOS X backend?

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Sorry about that.  I believe it is fixed now.

Mike

On 08/16/2010 05:54 PM, Andrew Straw wrote:
> Michael Droettboom wrote:
>    
>> On 08/14/2010 07:22 PM, Eric Firing wrote:
>>
>>      
>>> Mike,
>>>
>>> Is there any reason why the Path.unit_* methods shouldn't include the
>>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at
>>> least have a kwarg to allow that as an option?  In working on patch
>>> drawing via bar(), I noticed that the rectangle outline is not closing
>>> properly, with the same rounded join as at the other 3 corners.  It
>>> isn't apparent unless you set a large linewidth.
>>>
>>> Or is there a better way to ensure that polygons close correctly?
>>>
>>>        
>> I don't think there's a better way.  The renderer can't assume CLOSEPOLY
>> at the end, obviously, because it may in fact by a line and not a filled
>> shape.
>>
>> I think this was left out just as shorthand (not having a codes array
>> makes things a little faster, too), but I think for correctness the
>> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll
>> go ahead and fix this.
>>
>> Mike
>>
>>
>>      
> Hi Mike, all the buildbots have errors with the
> matplotlib.tests.test_simplification.test_hatch test on r8639 that
> weren't there in r8635, and I think it's due to the code you committed.
> Could you have a look?
>
> (Don't worry about the doc build errors -- I think that's a bug with the
> recent Sphinx 1.0.2 release, for which I have filed a report at
> http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
>
> (I was proud of all the green on the buildbot -- hopefully it won't turn
> me into a chronic nag!)
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Mon, Aug 16, 2010 at 4:48 PM, Friedrich Romstedt <
fri...@gm...> wrote:

> Ben, I fully agree with you that figures should be able to be saved
> both coloured and grayscale.  It was a misunderstanding.  What I meant
> was, that it will not be necessary to display one part of the figure
> in colour and the other in grayscale at the same time.
>
> Friedrich
>
>
"...it will not be necessary..."

I think we are still getting confused here.  I was listing off several
different kinds of use-cases where one would like to have a mix of grey
colormaps and colored colormaps.  The reason I mention being able to save a
greyscale and a color version of the same figure is in the context of my
approach to solving this problem (the swapping out of colormaps).  Honestly,
I think that your approach is better for dealing with that particular use
case.

However, I mention other cases where one is merely wanting a modified
version of a particular colormap to use, be it greyscale, or inverse, or
brighter/darker, etc.  What I envision your solution to be solving would be
something like this:

fig = plt.figure()
ax = fig.add_subplot(1, 2, 1)
ax.plot(np.linspace(1, 10, 10), np.linspace(2, 8, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(4, 9, 10))

ax = fig.add_subplot(1, 2, 2)
ax.set_grey(True)
ax.plot(np.linspace(1, 10, 10), np.linspace(1, 8, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(3, 7, 10))
ax.plot(np.linspace(1, 10, 10), np.linspace(2, 9, 10))

plt.show()

And see one in color and one as grey and the other as color.  This would be
a nice feature, but I would settle for it to be at the level of the entire
figure.

I think my approach is trying to solve a related, but different problem.  My
approach is trying to make colormaps more usable and flexible for the
users.  I would like to ensure that matplotlib does not artificially limit
the ability of a user to fully utilize the variety of colormaps available to
him.

Ben Root

Michael Droettboom wrote:
> On 08/14/2010 07:22 PM, Eric Firing wrote:
>   
>> Mike,
>>
>> Is there any reason why the Path.unit_* methods shouldn't include the 
>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at 
>> least have a kwarg to allow that as an option?  In working on patch 
>> drawing via bar(), I noticed that the rectangle outline is not closing 
>> properly, with the same rounded join as at the other 3 corners.  It 
>> isn't apparent unless you set a large linewidth.
>>
>> Or is there a better way to ensure that polygons close correctly?
>>     
>
> I don't think there's a better way.  The renderer can't assume CLOSEPOLY 
> at the end, obviously, because it may in fact by a line and not a filled 
> shape.
>
> I think this was left out just as shorthand (not having a codes array 
> makes things a little faster, too), but I think for correctness the 
> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll 
> go ahead and fix this.
>
> Mike
>
>   

Hi Mike, all the buildbots have errors with the
matplotlib.tests.test_simplification.test_hatch test on r8639 that
weren't there in r8635, and I think it's due to the code you committed.
Could you have a look?

(Don't worry about the doc build errors -- I think that's a bug with the
recent Sphinx 1.0.2 release, for which I have filed a report at
http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)

(I was proud of all the green on the buildbot -- hopefully it won't turn
me into a chronic nag!)

-Andrew

I'm currently working on a patch to enable the matplotlib feature
shown in the video.  Notice that it's pure matplotlib, no change of
any plot parameters.  Unfortunately, or better to say fortunately? I
lost my changes by installing from svn, so I have to redo it, but this
times it's less hacky I believe.  I'm reworking colors.ColorConverter
completely but backwards compatible.

The second change applies to cm.ScalarMappable.to_rgba(), to use the
colors.colorConverter for applying the rc gray setting.

Then printing in grayscale will be possible for all features of
matplolib going one of this routes to get their colors, which should
be most.  Do you know any more?

To pursue on the ColorConverter class, it seems to me that this has
evolved organically, merging class attributes with module attributes.
Shouldn't this be fixed, by putting the class's methods into module
space?

Ben, I fully agree with you that figures should be able to be saved
both coloured and grayscale.  It was a misunderstanding.  What I meant
was, that it will not be necessary to display one part of the figure
in colour and the other in grayscale at the same time.

Friedrich

2010/8/11 Friedrich Romstedt <fri...@gm...>:
> http://www.youtube.com/watch?v=aa5eWT-J3v0

On 08/14/2010 07:22 PM, Eric Firing wrote:
> Mike,
>
> Is there any reason why the Path.unit_* methods shouldn't include the 
> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at 
> least have a kwarg to allow that as an option?  In working on patch 
> drawing via bar(), I noticed that the rectangle outline is not closing 
> properly, with the same rounded join as at the other 3 corners.  It 
> isn't apparent unless you set a large linewidth.
>
> Or is there a better way to ensure that polygons close correctly?

I don't think there's a better way.  The renderer can't assume CLOSEPOLY 
at the end, obviously, because it may in fact by a line and not a filled 
shape.

I think this was left out just as shorthand (not having a codes array 
makes things a little faster, too), but I think for correctness the 
unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll 
go ahead and fix this.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA