[matplotlib-devel] rotate_vector major bug in basemap
Jeff, I ran into a major bug that I think results from a fairly deep-seated gotcha in basemap. The problem lies with the in-place transformation of lon,lat in the proj library. This is not an inherent problem in itself; the trouble comes because sometimes the data get copied along the way from the basemap interface into proj, and sometimes they don't. When they don't get copied, rotate_vector breaks, because the input lon,lat variables are transformed in place, and then they are no longer lon and lat when they need to be reused as such. This could be fixed with a copy in rotate_vector, but I recommend that instead it be fixed by guaranteeing that there is a copy at a much lower level, probably in the pyproj Proj.__call__ method, and if not there, then in the basemap.__call__ method. I am not sure what all the effects might be, though--is anything relying on in-place calculation at that level? The reason for recommending the low-level copy is that if basemap.__call__ continues to behave as it does, sometimes obliterating its input arguments via the in-place operation and sometimes not, it will continue to cause horrible surprises. I think that the overhead of a single copy would be a small price to pay to eliminate such surprises. If there is a need to preserve the in-place option, then perhaps it could be accessed through a different interface. Let __call__ guarantee that its input arguments are preserved, and have a "transform" method that minimizes copying. Eric - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rotate_vector major bug in basemap
Jeff, I sent that last message a little too quickly. Now I see that pyproj really is trying to ensure a copy--that is what the comments and docstring say--so I will simply try to find and fix the bug, the particular case in which a copy is not being made. Eric Eric Firing wrote: > Jeff, > > I ran into a major bug that I think results from a fairly deep-seated > gotcha in basemap. The problem lies with the in-place transformation of > lon,lat in the proj library. This is not an inherent problem in itself; > the trouble comes because sometimes the data get copied along the way > from the basemap interface into proj, and sometimes they don't. When > they don't get copied, rotate_vector breaks, because the input lon,lat > variables are transformed in place, and then they are no longer lon and > lat when they need to be reused as such. > > This could be fixed with a copy in rotate_vector, but I recommend that > instead it be fixed by guaranteeing that there is a copy at a much lower > level, probably in the pyproj Proj.__call__ method, and if not there, > then in the basemap.__call__ method. I am not sure what all the effects > might be, though--is anything relying on in-place calculation at that level? > > The reason for recommending the low-level copy is that if > basemap.__call__ continues to behave as it does, sometimes obliterating > its input arguments via the in-place operation and sometimes not, it > will continue to cause horrible surprises. I think that the overhead of > a single copy would be a small price to pay to eliminate such surprises. > > If there is a need to preserve the in-place option, then perhaps it > could be accessed through a different interface. Let __call__ guarantee > that its input arguments are preserved, and have a "transform" method > that minimizes copying. > > Eric > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] rotate_vector major bug in basemap
Jeff, The problem is not in basemap, it is numpy. Basemap is doing the right thing, using the astype method to ensure a copy--but that is not what the method is actually doing in this case. I filed a numpy ticket (788). I took a quick look at the numpy code but did not find anything obviously amiss. If this does not get solved in numpy right away, the workaround in basemap/pyproj _copytobuffer is to use npy.array(x, dtype=npy.float64, copy=True) instead of the astype method. Eric Eric Firing wrote: > Jeff, > > I sent that last message a little too quickly. Now I see that pyproj > really is trying to ensure a copy--that is what the comments and > docstring say--so I will simply try to find and fix the bug, the > particular case in which a copy is not being made. > > Eric > > Eric Firing wrote: >> Jeff, >> >> I ran into a major bug that I think results from a fairly deep-seated >> gotcha in basemap. The problem lies with the in-place transformation of [...] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel