matplotlib-devel Mailing List for matplotlib (Page 4)

On 06/11/2010 07:44 AM, Michael Droettboom wrote:
> The Qt4 backend crashes with a Segmentation Fault when no toolbar is
> requested. For example:

Mike,

Have the other backends been tested for the same problem?

Eric

>
> from matplotlib import pyplot as plt
> from matplotlib import rcParams
> rcParams['toolbar'] = 'None'
> fig=plt.figure()
> plt.show()
>
> I have attached a possible patch, but since I've never really touched
> the Qt4 backend before, thought I'd solicit some feedback before
> committing.
>
> Mike
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 06/11/2010 07:39 AM, Michael Droettboom wrote:
> On 06/11/2010 01:31 PM, jas...@cr... wrote:
>> On 6/11/10 9:44 AM, Michael Droettboom wrote:
>>
>>> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>>>
>>>
>>>> However, there's actually a bug in the quantizer that your example
>>>> illustrates.  Since the spine lines in your example have a stroke width
>>>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>>>> not nearest center pixel.  So the quantizing is causing this slight
>>>> alignment problem *and* making the straight lines look fuzzier than they
>>>> should.  I'm planning on writing a patch that will take stroke width
>>>> into account to address this.  By coincidence only, this will also make
>>>> your example plot look more accurate (but that's dependent on the
>>>> specific scale being used).
>>>>
>>>>
>>>>
>>> This specific bug is fixed in r8414.
>>>
>>> Mike
>>>
>>>
>>>
>> I tested your fix, and now this example gives the same sort of problem
>> (note that in this case, the spine is 1 pixel wide; I've just changed
>> the dpi):
>>
> That's exactly what I meant when I said "By coincidence only, this will
> also make your example plot look more accurate (but that's dependent on
> the specific scale being used)."  This isn't a proper fix, other than to
> make even-width lines looking less fuzzy.  The correct fix (to either
> make quanitizing an rcParam or to adjust the data based on it) is much
> more work.

I don't see how any reasonable algorithm could do such a data adjustment 
in general, so if the half-pixel inaccuracy is a problem, then I think 
using an rcParam to turn off quantizing is the way to go.

It appears that the difficulty is that quantization is exposed at the 
python level only for collections, via iter_segments.

Eric


>
> Mike
>

The Qt4 backend crashes with a Segmentation Fault when no toolbar is 
requested.  For example:

from matplotlib  import pyplot as plt
from matplotlib  import rcParams
rcParams['toolbar'] = 'None'
fig=plt.figure()
plt.show()

I have attached a possible patch, but since I've never really touched 
the Qt4 backend before, thought I'd solicit some feedback before committing.

Mike

-- 

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

On 06/11/2010 01:31 PM, jas...@cr... wrote:
> On 6/11/10 9:44 AM, Michael Droettboom wrote:
>    
>> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>>
>>      
>>> However, there's actually a bug in the quantizer that your example
>>> illustrates.  Since the spine lines in your example have a stroke width
>>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>>> not nearest center pixel.  So the quantizing is causing this slight
>>> alignment problem *and* making the straight lines look fuzzier than they
>>> should.  I'm planning on writing a patch that will take stroke width
>>> into account to address this.  By coincidence only, this will also make
>>> your example plot look more accurate (but that's dependent on the
>>> specific scale being used).
>>>
>>>
>>>        
>> This specific bug is fixed in r8414.
>>
>> Mike
>>
>>
>>      
> I tested your fix, and now this example gives the same sort of problem
> (note that in this case, the spine is 1 pixel wide; I've just changed
> the dpi):
>    
That's exactly what I meant when I said "By coincidence only, this will 
also make your example plot look more accurate (but that's dependent on 
the specific scale being used)."  This isn't a proper fix, other than to 
make even-width lines looking less fuzzy.  The correct fix (to either 
make quanitizing an rcParam or to adjust the data based on it) is much 
more work.

Mike

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

On 6/11/10 9:44 AM, Michael Droettboom wrote:
> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>    
>> However, there's actually a bug in the quantizer that your example
>> illustrates.  Since the spine lines in your example have a stroke width
>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>> not nearest center pixel.  So the quantizing is causing this slight
>> alignment problem *and* making the straight lines look fuzzier than they
>> should.  I'm planning on writing a patch that will take stroke width
>> into account to address this.  By coincidence only, this will also make
>> your example plot look more accurate (but that's dependent on the
>> specific scale being used).
>>
>>      
> This specific bug is fixed in r8414.
>
> Mike
>
>    

I tested your fix, and now this example gives the same sort of problem 
(note that in this case, the spine is 1 pixel wide; I've just changed 
the dpi):

from matplotlib import pyplot as plt
import numpy as np
fig = plt.figure()

ax = fig.add_subplot(1,1,1, aspect='equal')
ax.plot([-1,1],[-1,1], color='blue')
ax.set_xlim(-1.1,1.1)
ax.set_ylim(-1.1,1.1)
ax.spines['left'].set_position('zero')
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png',dpi=100)

It appears that the true origin is at the top left corner of the 1-pixel 
intersection of the two spines in the above example.

Thanks again for your work on this!

Jason

I notice in setupext.py, a default is set for the setup.cfg 
build_windowing option, but it doesn't look like anything is ever 
actually read in from the configuration file to override the default.  
Also, the build_windowing option is not in the setup.cfg.template file.  
Is all of this intentional?

Thanks,

Jason

--
Jason Grout

On 6/11/10 9:44 AM, Michael Droettboom wrote:
> On 06/11/2010 09:46 AM, Michael Droettboom wrote:
>    
>> However, there's actually a bug in the quantizer that your example
>> illustrates.  Since the spine lines in your example have a stroke width
>> of 4 pixels, they should actually be rounded to the nearest pixel edge,
>> not nearest center pixel.  So the quantizing is causing this slight
>> alignment problem *and* making the straight lines look fuzzier than they
>> should.  I'm planning on writing a patch that will take stroke width
>> into account to address this.  By coincidence only, this will also make
>> your example plot look more accurate (but that's dependent on the
>> specific scale being used).
>>
>>      
> This specific bug is fixed in r8414.
>    

THANK YOU!!!

And thanks for the nice explanation.  Karl-Dieter Crisman and I figured 
there was some sort of pixel rounding issue somewhere, but it was above 
our heads to try to find it.

Thanks,

Jason

Hi,

Plotting some very small values (~1E-306) will break mpl with the error:

   File 
"/usr/lib/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 154, in draw_text
     self._renderer.draw_text_image(font.get_image(), int(x), int(y) + 
1, angle, gc)
OverflowError: cannot convert float infinity to long


Very large values don't seem to be a problem and this bug seems to be 
backend independent. Also, for some reason the minimum double value 
representable in C and Python seem to be different... On my machine 
(i686 GNU/Linux, 32 bits Debian testing) the C DBL_MIN is ~1E-308, but 
Python seem to 1E-323 or so (Python 2.5.5). I'm using the latest mpl svn 
(rev 8414).

Regards,
João Silva

Example script -----------------------------------------------------

import numpy as np
import matplotlib.pyplot as plt
n = 10
x = np.linspace(0.0,10.0,n)
plt.plot(x,1E-306*np.ones(n))
plt.show()

-----------------------------------------------------

On 06/11/2010 09:46 AM, Michael Droettboom wrote:
> However, there's actually a bug in the quantizer that your example
> illustrates.  Since the spine lines in your example have a stroke width
> of 4 pixels, they should actually be rounded to the nearest pixel edge,
> not nearest center pixel.  So the quantizing is causing this slight
> alignment problem *and* making the straight lines look fuzzier than they
> should.  I'm planning on writing a patch that will take stroke width
> into account to address this.  By coincidence only, this will also make
> your example plot look more accurate (but that's dependent on the
> specific scale being used).
>    
This specific bug is fixed in r8414.

Mike

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

The problem is the default quantizing of all rectilinear axis-aligned 
lines (which includes the spines).  They are "rounded" to the nearest 
center pixels in order to make them less fuzzy.

However, there's actually a bug in the quantizer that your example 
illustrates.  Since the spine lines in your example have a stroke width 
of 4 pixels, they should actually be rounded to the nearest pixel edge, 
not nearest center pixel.  So the quantizing is causing this slight 
alignment problem *and* making the straight lines look fuzzier than they 
should.  I'm planning on writing a patch that will take stroke width 
into account to address this.  By coincidence only, this will also make 
your example plot look more accurate (but that's dependent on the 
specific scale being used).

The quantizing (once corrected) is a tradeoff to increase the sharpness 
of rectilinear lines (which is important to many, including myself) at 
the expense of some subpixel accuracy.  The easy solution is to provide 
a global flag (similar to path.simplify) that would turn off 
quantization globally for those that want to live on the other side of 
the tradeoff.  The harder solution would be to quantize the axes (or 
spines) and adjust the data accordingly based on the amount of shift.  
I'm really not sure how to make the latter work without completely 
reworking how quantization is currently implemented (the quantization is 
pretty ignorant of anything "global" other than what it is currently 
drawing).

Mike

On 06/11/2010 02:02 AM, Jason Grout wrote:
> Hi all,
>
> If you zoom in to the origin in the following figure:
>
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1, aspect='equal')
> ax.plot([-1,1],[-1,1], color='blue')
> ax.set_xlim(-1.1,1.1)
> ax.set_ylim(-1.1,1.1)
> ax.spines['left'].set_position('zero')
> ax.spines['right'].set_color('none')
> ax.spines['bottom'].set_position('zero')
> ax.spines['top'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png',dpi=300)
>
> you'll see that the blue line isn't quite centered at the origin (at
> least the origin marked by the spines).  It appears to hit just above or
> just to the left of the origin.  Notice that there is a bit of blue
> coloring in the second quadrant, but none in the fourth.  Notice also
> that there are more pixels colored just below the x-axis in quadrant 3
> than just above the axis in quadrant 1.
>
> Several of us Sage developers have been practically pulling out our hair
> trying to trace down why our plots seem to be shifted up or to the left
> by a pixel or so.  I think the above example illustrates what is going on.
>
> Any ideas as to what is going on?  I'm not sure if the problem is with
> the line or with the spines.  The lines ax.plot([-1,1],[0,0]) and
> ax.plot([0,0],[-1,1]) seem to be right on center with the spines.
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> 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 all,

If you zoom in to the origin in the following figure:

fig = plt.figure()
ax = fig.add_subplot(1,1,1, aspect='equal')
ax.plot([-1,1],[-1,1], color='blue')
ax.set_xlim(-1.1,1.1)
ax.set_ylim(-1.1,1.1)
ax.spines['left'].set_position('zero')
ax.spines['right'].set_color('none')
ax.spines['bottom'].set_position('zero')
ax.spines['top'].set_color('none')
ax.xaxis.set_ticks_position('bottom')
ax.yaxis.set_ticks_position('left')
fig.savefig('test.png',dpi=300)

you'll see that the blue line isn't quite centered at the origin (at 
least the origin marked by the spines).  It appears to hit just above or 
just to the left of the origin.  Notice that there is a bit of blue 
coloring in the second quadrant, but none in the fourth.  Notice also 
that there are more pixels colored just below the x-axis in quadrant 3 
than just above the axis in quadrant 1.

Several of us Sage developers have been practically pulling out our hair 
trying to trace down why our plots seem to be shifted up or to the left 
by a pixel or so.  I think the above example illustrates what is going on.

Any ideas as to what is going on?  I'm not sure if the problem is with 
the line or with the spines.  The lines ax.plot([-1,1],[0,0]) and 
ax.plot([0,0],[-1,1]) seem to be right on center with the spines.

Thanks,

Jason

--
Jason Grout

Actually, I just noticed this problem myself after upgrading my system to
Fedora 13.  Turns out I still had some *.so files in the lib directory that
were not getting updated by the Make (might be a dependency issue?), and
they weren't getting eliminated by a 'clean' command.  Therefore, the old
.so files were still expecting to link to the older versions of the
libraries which didn't exist anymore.

Deleting the *.so files in the lib directory and redoing the entire build
worked like a charm for me.

Ben Root

On Thu, Jun 10, 2010 at 1:21 PM, Jeff Whitaker <js...@fa...> wrote:

> On 6/10/10 11:50 AM, Pierre GM wrote:
> > On Jun 10, 2010, at 1:30 PM, Christoph Gohlke wrote:
> >
> >>
> >> On 6/10/2010 10:14 AM, Pierre GM wrote:
> >>
> >>> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
> >>>
> >>>> On 6/10/10 10:40 AM, Pierre GM wrote:
> >>>>
> >>>>> All,
> >>>>> Sorry, it's been a while since I've been using Basemap. I was just
> trying to update my local svn directory to r8403 and reinstall basemap, but
> an import fail w/ the following message:
> >>>>> """
> >>>>> Traceback (most recent call last):
> >>>>>    File "<string>", line 1, in<module>
> >>>>>    File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line
> 43, in<module>
> >>>>>      import _geoslib, netcdftime
> >>>>>    File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
> >>>>> ValueError: numpy.ndarray does not appear to be the correct type
> object
> >>>>> """
> >>>>> I'm using numpy 2.0.0r8460 (development version). basemap can be
> successfully imported w/ the latest stable version, though. What am I doing
> wrong ?
> >>>>> Thx in advance.
> >>>>> P.
> >>>>>
> >>>>>
> >>>> Pierre:  That should have been fixed with a recompile of the _geoslib
> C extension  Are you sure you deleted the build directory before
> reinstalling basemap?
> >>>>
> >>>
> >> Try to regenerate the c files from _geod.pyx, _proj.pyx, and
> >> _geoslib.pyx, using Cython-0.12.1. For example:
> >>
>
> Wonder why I didn't have to do that ...
>
> -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
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 6/10/10 11:50 AM, Pierre GM wrote:
> On Jun 10, 2010, at 1:30 PM, Christoph Gohlke wrote:
>    
>>
>> On 6/10/2010 10:14 AM, Pierre GM wrote:
>>      
>>> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
>>>        
>>>> On 6/10/10 10:40 AM, Pierre GM wrote:
>>>>          
>>>>> All,
>>>>> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
>>>>> """
>>>>> Traceback (most recent call last):
>>>>>    File "<string>", line 1, in<module>
>>>>>    File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
>>>>>      import _geoslib, netcdftime
>>>>>    File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
>>>>> ValueError: numpy.ndarray does not appear to be the correct type object
>>>>> """
>>>>> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
>>>>> Thx in advance.
>>>>> P.
>>>>>
>>>>>            
>>>> Pierre:  That should have been fixed with a recompile of the _geoslib C extension  Are you sure you deleted the build directory before reinstalling basemap?
>>>>          
>>>        
>> Try to regenerate the c files from _geod.pyx, _proj.pyx, and
>> _geoslib.pyx, using Cython-0.12.1. For example:
>>      

Wonder why I didn't have to do that ...

-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

On Thu, Jun 10, 2010 at 1:13 PM, Benjamin Root <ben...@ou...> wrote:
> Taking out adjustable='box' had the same effect for me as setting
> adjustable='box-forced

Just a quick comment.
As you can verify, the axes created with AxesGrid will have
adjustable="datalim". With AxesGrid, the size of each axes is adjusted
before they call "apply_aspect", hence the value of adjustable
actually does not matter from the AxesGrid point of view.

My recollection is that "bbox-forced" option was originally meant to
be used with a normal axes.

Regards,

-JJ

On 6/10/10 11:13 AM, Benjamin Root wrote:
>
>
> On Thu, Jun 10, 2010 at 11:56 AM, Jeff Whitaker <js...@fa... 
> <mailto:js...@fa...>> wrote:
>
>     On 6/10/10 10:41 AM, Benjamin Root wrote:
>>
>>
>>     On Thu, Jun 10, 2010 at 11:05 AM, Jeff Whitaker
>>     <js...@fa... <mailto:js...@fa...>> wrote:
>>
>>         On 6/9/10 1:58 PM, Benjamin Root wrote:
>>>         Has anybody given any further thought to the implication of
>>>         having Basemap set adjustable as "box-forced" instead of
>>>         "box"?  So far, it has been working just fine for me, but I
>>>         have no clue if there are any unintended side-effects.
>>>
>>>         Ben Root
>>
>>         Ben:  To summarize the discussion so far, it seems that
>>         "box-forced" should not be used, and either Basemap should
>>         continue to use adjustable="box" (for the reasons Eric gave
>>         in his post yesterday) or adjustable should not be set at all
>>         by Basemap and that job should be left to the user (since
>>         adjustable='box' is the default anyway, as Jae-Joon pointed
>>         out today).  Perhaps it would help if you could provide a
>>         usage example for AxesGrid axes sharing with Basemap, so we
>>         can see what the consequences of changing the current
>>         behavior are.
>>
>>         -Jeff
>>
>>     Maybe it isn't a use-case per se, but I have found that it is
>>     much easier to use axes_grid1 instead of subplots to produce
>>     multiple radar plots that all use the same colorbar.  For
>>     example, I have 3 radar plots to show, and I want a single
>>     colorbar on the right-hand side.  To a newbie, one would add
>>     three subplots with a .colorbar() command for the last one. 
>>     Unfortunately, the newbie will discover that the third plot will
>>     be smaller than the other two because that last axes has to be
>>     split between two objects.  To someone a little more advanced,
>>     you would create 4 subplots, but fool around with the size of the
>>     last axes (and also have to discover to use ColorbarBase instead
>>     of the regular colorbar call).
>>
>>     But, with axes_grid, this is quite trivial and the results look
>>     very nice.
>>
>>     Attached is a png image of a time series I recent submitted in a
>>     publication.
>>
>>     Ben Root
>>
>>     P.S. - I have found a 'bug' of sorts with using 'box-forced' for
>>     Basemap and AxesGrid.  For the displayed plot, if one were to
>>     zoom in on one of the plots, the other plots will zoom in as well
>>     (which I think is neat), but they won't update their bbox to
>>     completely match the zoomed-in axes.  I guess this would be an
>>     argument against using 'box-forced'?
>
>     Ben:  Could you send the code that produced this plot?
>
>     I'm thinking that just removing the adjustable='box' from Basemap
>     altogether is the best solution.  Can you try editing
>     lib/mpl_toolkits/basemap/__init__.py and removing the two
>     occurences of adjustable='box' in set_axes_limits works for you?
>
>
> Jeff, here is a very simple script that gets the idea across (the code 
> and the data for producing those plots are rather extensive...).  
> Taking out adjustable='box' had the same effect for me as setting 
> adjustable='box-forced'.  You can see the zooming issue I was talking 
> about before as well when you interact with the displayed figure.
>
> Ben Root

Ben:  OK, I see the issue with zooming.  If you create the subplots 
manually (without AxesGrid) it doesn't happen (only one plot zooms).  
Maybe Jae-Joon can comment on why this is happening?

-Jeff
>
>
>     Index: lib/mpl_toolkits/basemap/__init__.py
>     ===================================================================
>     --- lib/mpl_toolkits/basemap/__init__.py        (revision 8406)
>     +++ lib/mpl_toolkits/basemap/__init__.py        (working copy)
>     @@ -2628,9 +2628,9 @@
>              # plot is re-centered in bounding rectangle.
>              # (anchor instance var determines where plot is placed)
>              if self.fix_aspect:
>     -           
>     ax.set_aspect('equal',adjustable='box',anchor=self.anchor)
>     +            ax.set_aspect('equal',anchor=self.anchor)
>              else:
>     -            ax.set_aspect('auto',adjustable='box',anchor=self.anchor)
>     +            ax.set_aspect('auto',anchor=self.anchor)
>              # make sure axis ticks are turned off.
>              if self.noticks:
>                  ax.set_xticks([])
>
>     We definitely don't want to use 'box-forced', I think that will
>     cause many problems.
>
>     -Jeff
>
>>
>>>
>>>
>>>         On Tue, Jun 1, 2010 at 6:00 PM, Benjamin Root
>>>         <ben...@ou... <mailto:ben...@ou...>> wrote:
>>>
>>>             Right, that is sort of what I am asking.  My thinking is
>>>             that Basemap could use 'box-forced' instead of 'box' for
>>>             the adjustable parameter in order to make it and
>>>             AxesGrid compatible.  Usually, if one wants to use
>>>             AxesGrid, they all should have the same domain and
>>>             aspect ratio.  I just have no clue what sort of
>>>             repricussions that has for other use cases.
>>>
>>>             So far, this has worked just fine for me, but I hardly
>>>             represent the normal use cases of Basemap and AxesGrid.
>>>
>>>             Ben Root
>>>
>>>
>>>             On Tue, Jun 1, 2010 at 5:20 PM, Jae-Joon Lee
>>>             <lee...@gm... <mailto:lee...@gm...>> wrote:
>>>
>>>                 If Basemap explicitly sets aspect=1 and
>>>                 adjustable="box" at the same
>>>                 time, you cannot use this with any axes that shares
>>>                 its axis with
>>>                 others (including the axes created by the AxesGrid).
>>>
>>>                 You need to somehow avoid the set_aspect call with
>>>                 adjustable"box"
>>>                 (you can set box-forced in stead).
>>>
>>>                 -JJ
>>>
>>>
>>>                 On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root
>>>                 <ben...@ou... <mailto:ben...@ou...>> wrote:
>>>                 >
>>>                 > On a related note, I have noticed an
>>>                 incompatibility between AxesGrid and
>>>                 > Basemap.  It appears that Basemap will explicitly
>>>                 set adjustable='box' when
>>>                 > it calls ax.set_aspect(), but AxesGrid will error
>>>                 out, saying that it has to
>>>                 > be 'datalim'.  What are the implications of using
>>>                 'box-forced' instead of
>>>                 > 'box' in Basemap?
>>>                 >
>>>                 > Ben Root
>>>                 >
>>>                 > On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee
>>>                 <lee...@gm... <mailto:lee...@gm...>>
>>>                 wrote:
>>>                 >>
>>>                 >> ax1 = subplot(121)
>>>                 >> ax2 = subplot(122, sharex=ax1, sharey=ax1)
>>>                 >>
>>>                 >> ax1.set_adjustable("box-forced")
>>>                 >> ax2.set_adjustable("box-forced")
>>>                 >>
>>>                 >> arr1 = np.arange(100).reshape((10, 10))
>>>                 >> ax1.imshow(arr1)
>>>                 >>
>>>                 >> arr2 = np.arange(100, 0, -1).reshape((10, 10))
>>>                 >> ax2.imshow(arr2)
>>>                 >>
>>>                 >> Note the use of set_adjustable("box-forced").
>>>                 >> sharex and sharey does not get along with axes of
>>>                 aspect=1 &
>>>                 >> adjustable="box".
>>>                 >>
>>>                 >> -JJ
>>>                 >>
>>>                 >>
>>>                 >>
>>>                 >> On Thu, May 27, 2010 at 2:10 PM,
>>>                 <PH...@ge...
>>>                 <mailto:PH...@ge...>> wrote:
>>>                 >> > Do the “sharex” and “sharey” kwargs help?
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html
>>>                 >> >
>>>                 >> > -paul
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > From: Adam Fraser
>>>                 [mailto:ada...@gm...
>>>                 <mailto:ada...@gm...>]
>>>                 >> > Sent: Thursday, May 27, 2010 10:44 AM
>>>                 >> > To: matplotlib-users
>>>                 >> > Subject: [Matplotlib-users] Is there a way to
>>>                 link axes of imshow plots?
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > Suppose I have a figure canvas with 3 plots...
>>>                 2 are images of the same
>>>                 >> > dimensions plotted with imshow, and the other
>>>                 is a scatterplot. I'd like
>>>                 >> > to
>>>                 >> > be able to link the x and y axes of the imshow
>>>                 plots so that when I zoom
>>>                 >> > in
>>>                 >> > one, the other zooms to the same coordinates,
>>>                 and when I pan in one, the
>>>                 >> > other pans as well.
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > I started hacking my way around this by
>>>                 >> > subclassing NavigationToolbar2WxAgg
>>>                 >> > (shown below)... but there are several problems
>>>                 here.
>>>                 >> >
>>>                 >> > 1) This will link the axes of all plots in a
>>>                 canvas since all I've done
>>>                 >> > is
>>>                 >> > get rid of the checks for a.in_axes()
>>>                 >> >
>>>                 >> > 2) This worked well for panning, but zooming
>>>                 caused all subplots to zoom
>>>                 >> > from the same global point, rather than from
>>>                 the same point in each of
>>>                 >> > their
>>>                 >> > respective axes.
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > Can anyone suggest a workaround?
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > Much thanks!
>>>                 >> >
>>>                 >> > -Adam
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> > from matplotlib.backends.backend_wxagg import
>>>                 NavigationToolbar2WxAgg as
>>>                 >> > NavigationToolbar
>>>                 >> >
>>>                 >> > class MyNavToolbar(NavigationToolbar):
>>>                 >> >
>>>                 >> >     def __init__(self, canvas, cpfig):
>>>                 >> >
>>>                 >> >         NavigationToolbar.__init__(self, canvas)
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >     # override
>>>                 >> >
>>>                 >> >     def press_pan(self, event):
>>>                 >> >
>>>                 >> >         'the press mouse button in pan/zoom
>>>                 mode callback'
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         if event.button == 1:
>>>                 >> >
>>>                 >> >             self._button_pressed=1
>>>                 >> >
>>>                 >> >         elif  event.button == 3:
>>>                 >> >
>>>                 >> >             self._button_pressed=3
>>>                 >> >
>>>                 >> >         else:
>>>                 >> >
>>>                 >> >             self._button_pressed=None
>>>                 >> >
>>>                 >> >             return
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         x, y = event.x, event.y
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         # push the current view to define home
>>>                 if stack is empty
>>>                 >> >
>>>                 >> >         if self._views.empty(): self.push_current()
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         self._xypress=[]
>>>                 >> >
>>>                 >> >         for i, a in
>>>                 enumerate(self.canvas.figure.get_axes()):
>>>                 >> >
>>>                 >> >             # only difference from overridden
>>>                 method is that this one
>>>                 >> > doesn't
>>>                 >> >
>>>                 >> >             # check a.in_axes(event)
>>>                 >> >
>>>                 >> >             if x is not None and y is not None
>>>                 and a.get_navigate():
>>>                 >> >
>>>                 >> >                 a.start_pan(x, y, event.button)
>>>                 >> >
>>>                 >> >                 self._xypress.append((a, i))
>>>                 >> >
>>>                 >> >               
>>>                  self.canvas.mpl_disconnect(self._idDrag)
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                  self._idDrag=self.canvas.mpl_connect('motion_notify_event',
>>>                 >> > self.drag_pan)
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >     def press_zoom(self, event):
>>>                 >> >
>>>                 >> >         'the press mouse button in zoom to rect
>>>                 mode callback'
>>>                 >> >
>>>                 >> >         if event.button == 1:
>>>                 >> >
>>>                 >> >             self._button_pressed=1
>>>                 >> >
>>>                 >> >         elif  event.button == 3:
>>>                 >> >
>>>                 >> >             self._button_pressed=3
>>>                 >> >
>>>                 >> >         else:
>>>                 >> >
>>>                 >> >             self._button_pressed=None
>>>                 >> >
>>>                 >> >             return
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         x, y = event.x, event.y
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         # push the current view to define home
>>>                 if stack is empty
>>>                 >> >
>>>                 >> >         if self._views.empty(): self.push_current()
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         self._xypress=[]
>>>                 >> >
>>>                 >> >         for i, a in
>>>                 enumerate(self.canvas.figure.get_axes()):
>>>                 >> >
>>>                 >> >             # only difference from overridden
>>>                 method is that this one
>>>                 >> > doesn't
>>>                 >> >
>>>                 >> >             # check a.in_axes(event)
>>>                 >> >
>>>                 >> >             if x is not None and y is not None
>>>                 and a.get_navigate() and
>>>                 >> > a.can_zoom():
>>>                 >> >
>>>                 >> >                 self._xypress.append(( x, y, a,
>>>                 i, a.viewLim.frozen(),
>>>                 >> > a.transData.frozen()))
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >         self.press(event)
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 >> >
>>>                 ------------------------------------------------------------------------------
>>>                 >> >
>>>                 >> >
>>>                 >> > _______________________________________________
>>>                 >> > Matplotlib-users mailing list
>>>                 >> > Mat...@li...
>>>                 <mailto:Mat...@li...>
>>>                 >> >
>>>                 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>                 >> >
>>>                 >> >
>>>                 >>
>>>                 >>
>>>                 >>
>>>                 ------------------------------------------------------------------------------
>>>                 >>
>>>                 >> _______________________________________________
>>>                 >> Matplotlib-users mailing list
>>>                 >> Mat...@li...
>>>                 <mailto:Mat...@li...>
>>>                 >>
>>>                 https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>                 >
>>>                 >
>>>                 >
>>>                 ------------------------------------------------------------------------------
>>>                 >
>>>                 >
>>>                 > _______________________________________________
>>>                 > Matplotlib-devel mailing list
>>>                 > Mat...@li...
>>>                 <mailto:Mat...@li...>
>>>                 >
>>>                 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>                 >
>>>                 >
>>>
>>>                 ------------------------------------------------------------------------------
>>>
>>>                 _______________________________________________
>>>                 Matplotlib-devel mailing list
>>>                 Mat...@li...
>>>                 <mailto:Mat...@li...>
>>>                 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>
>>
>>         -- 
>>         Jeffrey S. Whitaker         Phone  : (303)497-6313
>>         Meteorologist               FAX    : (303)497-6449
>>         NOAA/OAR/PSD  R/PSD1        Email  :Jef...@no...  <mailto:Jef...@no...>
>>         325 Broadway                Office : Skaggs Research Cntr 1D-113
>>         Boulder, CO, USA 80303-3328 Web    :http://tinyurl.com/5telg
>>              
>>
>>
>
>
>     -- 
>     Jeffrey S. Whitaker         Phone  : (303)497-6313
>     Meteorologist               FAX    : (303)497-6449
>     NOAA/OAR/PSD  R/PSD1        Email  :Jef...@no...  <mailto:Jef...@no...>
>     325 Broadway                Office : Skaggs Research Cntr 1D-113
>     Boulder, CO, USA 80303-3328 Web    :http://tinyurl.com/5telg
>          
>
>


-- 
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

On 6/10/10 11:14 AM, Pierre GM wrote:
> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
>    
>> On 6/10/10 10:40 AM, Pierre GM wrote:
>>      
>>> All,
>>> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
>>> """
>>> Traceback (most recent call last):
>>>    File "<string>", line 1, in<module>
>>>    File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
>>>      import _geoslib, netcdftime
>>>    File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
>>> ValueError: numpy.ndarray does not appear to be the correct type object
>>> """
>>> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
>>> Thx in advance.
>>> P.
>>>
>>>        
>> Pierre:  That should have been fixed with a recompile of the _geoslib C extension  Are you sure you deleted the build directory before reinstalling basemap?
>>      
>
> I did. Do I have to recompile geos ? It should be independent of numpy, right ? So I shouldn't have to touch it ?
> As far as I can tell, the setup picks up the proper versions of numpy and Python...
>    

Pierre:  No, you don't need to recompile the geos library. I just 
installed numpy 2.0 svn with python 2.6, and after a recompile of both 
matplotlib from svn and basemap from svn everything worked fine.  I 
suspect you are still picking up an old _geoslib.so somehow.

-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

On 6/10/10 10:40 AM, Pierre GM wrote:
> All,
> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
> """
> Traceback (most recent call last):
>    File "<string>", line 1, in<module>
>    File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
>      import _geoslib, netcdftime
>    File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
> ValueError: numpy.ndarray does not appear to be the correct type object
> """
> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
> Thx in advance.
> P.
>    

Pierre:  That should have been fixed with a recompile of the _geoslib C 
extension  Are you sure you deleted the build directory before 
reinstalling basemap?

-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

All,
Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
"""
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in <module>
    import _geoslib, netcdftime
  File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
ValueError: numpy.ndarray does not appear to be the correct type object
"""
I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
Thx in advance.
P.

On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud <eri...@gm...> wrote:
> Jae-Joon, your patch looks to be effectively the same except for
> slightly different behavior when more than 3 points are present... but
> that was what was originally intended - the numpoints-> scatterpoints
> was a good catch!

I'm not sure if I put those numbers in the first places (maybe not),
yes, that was what was originally intended. And I'm inclined to leave
it as is.

I'll commit the change soon.
Thanks again.

-JJ

On Wed, Jun 9, 2010 at 6:22 PM, Eric Firing <ef...@ha...> wrote:
> Jeff can correct me if I am wrong, but I think adjustable='box' is
> essential for basemap because the maximum data limits are set when the
> Basemap instance is created.  In some cases the characteristics of the
> projection, and in all cases the extraction of coastlines, is set at
> instantiation time. You can zoom in to show smaller regions, but you
> don't want apply_aspect to expand the data limits beyond their initial
> values.

I think that, as axes in matplotlib, by default, has adjustable='box',
it should be okay without explicitly setting adjustable='box' in most
cases.

With explicit adjustable='bbox',

 * you will fix when a user accidentally provided an axes with wrong
adjustable value.
 * On the other hand, you will prohibit any axes sharing when Basemap
is used (there are cases when axes sharing is fine even if the aspect
is set to "equal").

So, I guess my point is that it might be good in this case to let the
user be responsible for what he is doing.
Since I'm not a regular Basemap user, it is just my point of view
(which might be wrong) from the outside.

Regards,

-JJ

On 6/10/10 7:01 AM, Jason Grout wrote:
> In 
> http://www.mail-archive.com/mat...@li.../msg05423.html, 
> I reported a patch that Sage uses for matplotlib on Solaris.  Notice 
> below that only one line is changed.
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` =
> "SunOS".  The comment is: Copy patched version of pprdrv_tt2.cpp for
> Solaris 10 that builds with gcc 4.3.2.
>
>
> --- src/ttconv/pprdrv_tt2.cpp    2009-08-01 12:15:15.000000000 -0700
> +++ patches/pprdrv_tt2.cpp    2009-08-08 23:33:24.000000000 -0700
> @@ -104,7 +104,8 @@
>       {                /* have a log of points. */
>       if(stack_depth == 0)
>           {
> -            stream.put_char('{');
> +            //  Note the below is a hack to make it compile on Solaris
> 10 with gcc 4.3.2
> +            stream.puts("{");
>               stack_depth=1;
>               }
>    
>
> In 
> http://www.mail-archive.com/mat...@li.../msg05428.html, 
> John said he'd look at it, but also asked for a platform macro for 
> Solaris.  I'm not sure what was done about it since then.  I notice 
> that the 0.99.3 release has the original code (i.e., no patch has been 
> applied).  John (or anyone), if you have time, could you take a look 
> at this?
>
> I'm CCing Dave Kirkby, who is a person in the Sage community that has 
> been working quite a bit on getting things to work on Solaris.  He 
> might have an idea of a good C macro for detecting when we are on Solaris.

I see that 
http://www.mail-archive.com/mat...@li.../msg04947.html 
is a related message which discusses compiling on Solaris and the 
put_char method.  In fact, I think the issue may be fixed from the 
discussion in that message, and our patch is unnecessary now.  I'm 
preparing a new matplotlib package for Sage without our patch above 
which we will test on Solaris.

Jason

--
Jason Grout

In 
http://www.mail-archive.com/mat...@li.../msg05423.html, 
I reported a patch that Sage uses for matplotlib on Solaris.  Notice 
below that only one line is changed.

---------------------------------------------------------------------------------------------------------------------------------------
ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` =
"SunOS".  The comment is: Copy patched version of pprdrv_tt2.cpp for
Solaris 10 that builds with gcc 4.3.2.


--- src/ttconv/pprdrv_tt2.cpp    2009-08-01 12:15:15.000000000 -0700
+++ patches/pprdrv_tt2.cpp    2009-08-08 23:33:24.000000000 -0700
@@ -104,7 +104,8 @@
      {                /* have a log of points. */
      if(stack_depth == 0)
          {
-            stream.put_char('{');
+            //  Note the below is a hack to make it compile on Solaris
10 with gcc 4.3.2
+            stream.puts("{");
              stack_depth=1;
              }


In 
http://www.mail-archive.com/mat...@li.../msg05428.html, 
John said he'd look at it, but also asked for a platform macro for 
Solaris.  I'm not sure what was done about it since then.  I notice that 
the 0.99.3 release has the original code (i.e., no patch has been 
applied).  John (or anyone), if you have time, could you take a look at 
this?

I'm CCing Dave Kirkby, who is a person in the Sage community that has 
been working quite a bit on getting things to work on Solaris.  He might 
have an idea of a good C macro for detecting when we are on Solaris.

Thanks,

Jason

--
Jason Grout

On Wed, Jun 9, 2010 at 8:17 PM, Jason Grout <jas...@cr...> wrote:
> In the "call signature" of savefig found here:
>
> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig
>
> it doesn't list the bbox_inches and pad_inches options, though they are
> listed in the list below the signature.

Thanks -- fixed in svn 8404

JDH

In the "call signature" of savefig found here:

http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig

it doesn't list the bbox_inches and pad_inches options, though they are 
listed in the list below the signature.

Thanks,

Jason

Jae-Joon, your patch looks to be effectively the same except for
slightly different behavior when more than 3 points are present... but
that was what was originally intended - the numpoints-> scatterpoints
was a good catch!

As for allowing an array markerscale, I agree with Jae-Joon... I think
the scatterpoints options are already stretching the limit of how
adaptable this legend is supposed to be, and it quickly becomes
confusing to match the offsets and the scalings. To be honest, I don't
see the use-case for having markerscale be different for each point
(not that there isn't a use for it, but it seems rather like a
corner-case that probably would be rather data-specific and hence more
suitable to subclassing...)


On Wed, Jun 9, 2010 at 2:05 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I'm not very kin to implement every possible options for every possible cases.
> If you need customization beyond what the current "legend" class
> provide, I recommend you to use proxy artists.
>
> http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist
>
> I personally think that the drawing of the legend handle should be
> delegated to the associated artist (but fall back to the default
> behavior when not provided).
>
> Regards,
>
> -JJ
>
>
> On Wed, Jun 9, 2010 at 4:32 PM, Benjamin Root <ben...@ou...> wrote:
>> I was trying the patch and I realized a possible use-case that might not
>> have been thought of before.  Consider the situation where a user does a
>> scatter plot with markers of two different sizes.  Then, it isn't that
>> far-fetched that the user might also want to control the markerscale for
>> each marker in the legend.
>>
>> A particular example would be that a user selected a smaller markersize for
>> the second scatterplot so that one could see the markers from the first
>> scatterplot if they share the same coordinates.  However, they may wish to
>> display the markers in the legend so that they have the same size.
>>
>> Currently, the markerscale argument accepts only a scalar, and not a list.
>> I don't know how difficult it would be to modify it do that, but it is a
>> thought.
>>
>> Ben Root
>>
>> On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>>
>>> Thanks for reporting these.
>>> I took a look at your patch and slight revised it (see the attached).
>>> While I believe that my patch is compatible to yours, it'll be great
>>> if you check my patch to see if I missed anything.
>>> I'll commit the change soon.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>> On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud <eri...@gm...>
>>> wrote:
>>> > I noticed some odd behavior in the legend and managed to track down
>>> > the source of the problem and make a fix (a diff against the current
>>> > svn is attached). Specifically, two things were fixed:
>>> >
>>> > *The "markerscale" argument for the legend seems to do nothing...  The
>>> > attached diff properly applies the markerscale scaling for
>>> > polygon/circle collections and the markers for lines with markers (but
>>> > NOT patches or the width of lines elements in the legend).
>>> >
>>> > *If the "scatterpoints" argument was >3, all points beyond 3
>>> > disappeared.  This was because the default scatteryoffset only had 3
>>> > entries, so if you didn't specifically overwrite this, the points
>>> > beyond 3 didn't appear.  I've re-worked this so that now the default
>>> > properly deals with a number of points other than 3.
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> > lucky parental unit.  See the prize list and enter to win:
>>> > http://p.sf.net/sfu/thinkgeek-promo
>>> > _______________________________________________
>>> > Matplotlib-devel mailing list
>>> > Mat...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>