[matplotlib-devel] Solaris bugfix in ttconv/pprdrv_tt2.cpp

[Jason Grout]

In 
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/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.cpp2009-08-01 12:15:15.0 -0700
+++ patches/pprdrv_tt2.cpp2009-08-08 23:33:24.0 -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/matplotlib-devel@lists.sourceforge.net/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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Solaris bugfix in ttconv/pprdrv_tt2.cpp

[Jason Grout]

On 6/10/10 7:01 AM, Jason Grout wrote:
In 
http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/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.cpp2009-08-01 12:15:15.0 -0700
+++ patches/pprdrv_tt2.cpp2009-08-08 23:33:24.0 -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/matplotlib-devel@lists.sourceforge.net/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/matplotlib-devel@lists.sourceforge.net/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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?

[Jae-Joon Lee]

On Wed, Jun 9, 2010 at 6:22 PM, Eric Firing  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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs

[Jae-Joon Lee]

On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud  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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Basemap r8403 and numpy 2.0

[Pierre GM]

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 "", line 1, in 
  File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in 

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.
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Basemap r8403 and numpy 2.0

[Jeff Whitaker]

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 "", line 1, in
>File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, 
> in
>  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/PSD1Email  : jeffrey.s.whita...@noaa.gov
325 BroadwayOffice : 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?

[Benjamin Root]

On Thu, Jun 10, 2010 at 11:56 AM, Jeff Whitaker  wrote:

>  On 6/10/10 10:41 AM, Benjamin Root wrote:
>
>
>
> On Thu, Jun 10, 2010 at 11:05 AM, Jeff Whitaker 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


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

Re: [matplotlib-devel] [Matplotlib-users] Basemap r8403 and numpy 2.0

[Jeff Whitaker]

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 "", line 1, in
>>>File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, 
>>> in
>>>  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/PSD1Email  : jeffrey.s.whita...@noaa.gov
325 BroadwayOffice : 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?

[Jeff Whitaker]

On 6/10/10 11:13 AM, Benjamin Root wrote:



On Thu, Jun 10, 2010 at 11:56 AM, Jeff Whitaker > wrote:


On 6/10/10 10:41 AM, Benjamin Root wrote:



On Thu, Jun 10, 2010 at 11:05 AM, Jeff Whitaker
mailto:jsw...@fastmail.fm>> 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
mailto:ben.r...@ou.edu>> 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 f

Re: [matplotlib-devel] [Matplotlib-users] Is there a way to link axes of imshow plots?

[Jae-Joon Lee]

On Thu, Jun 10, 2010 at 1:13 PM, Benjamin Root  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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Basemap r8403 and numpy 2.0

[Jeff Whitaker]

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 "", line 1, in
>File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, 
> in
>  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/PSD1Email  : jeffrey.s.whita...@noaa.gov
325 BroadwayOffice : 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Basemap r8403 and numpy 2.0

[Benjamin Root]

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  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 "", line 1, in
> >File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line
> 43, in
> >  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/PSD1Email  : jeffrey.s.whita...@noaa.gov
> 325 BroadwayOffice : 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
> Matplotlib-devel@lists.sourceforge.net
> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Plots shifted up or to the left a pixel or so

[Jason Grout]

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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel