There appears to be a bug in the 3rd subplot of symlog_demo.py because the ticker is generating an OverflowError on my powerbook. The problem is in SymmetricalLogLocator.__call__ when the vmin, vmax = self._transform.transform((vmin, vmax)) call transforms vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to 3.30039237078e+17. Then the while loop runs until I kill the job:: stride = 1 while numdec/stride+1 > self.numticks: stride += 1 This may have something to do with a platform specific floating point computations, because I am seeing different results on a linux box I am also testing on, but even there the results don't look right. For example, on that box, a 64 bit linux machine, I see [-1,1] transformed to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the example does run w/o crashing. In any case, it looks like there is some non-robust computation going on, and I'm hoping Michael has a quick insight :-) JDH
I held off on the release to hear back on this. Should we proceed this evening if there is no response? On Sat, Dec 6, 2008 at 5:09 PM, John Hunter <jd...@gm...> wrote: > There appears to be a bug in the 3rd subplot of symlog_demo.py because > the ticker is generating an OverflowError on my powerbook. > > The problem is in SymmetricalLogLocator.__call__ when the vmin, vmax = > self._transform.transform((vmin, vmax)) call transforms > vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to > 3.30039237078e+17. Then the while loop runs until I kill the job:: > > stride = 1 > while numdec/stride+1 > self.numticks: > stride += 1 > > This may have something to do with a platform specific floating point > computations, because I am seeing different results on a linux box I > am also testing on, but even there the results don't look right. For > example, on that box, a 64 bit linux machine, I see [-1,1] transformed > to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the > example does run w/o crashing. > > In any case, it looks like there is some non-robust computation going > on, and I'm hoping Michael has a quick insight :-) > > JDH > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
John, I can't reproduce the error on my intel macbook. Anyhow, it seems to me a bug in the code and bugs in numpy. (I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed in newer numpy. ) Can you try the patch below and see if this fix your problem? -JJ Index: lib/matplotlib/scale.py =================================================================== --- lib/matplotlib/scale.py (revision 6487) +++ lib/matplotlib/scale.py (working copy) @@ -301,7 +301,8 @@ self._linadjust = (np.log(linthresh) / self._log_base) / linthre def transform(self, a): - sign = np.sign(np.asarray(a)) + a = np.asarray(a) + sign = np.sign(a) masked = ma.masked_inside(a, -self.linthresh, self.linthresh, co False) log = sign * ma.log(np.abs(masked)) / self._log_base if masked.mask.any(): @@ -328,6 +329,7 @@ self._linadjust = linthresh / (np.log(linthresh) / self._log_bas def transform(self, a): + a = np.asarray(a) return np.where(a <= self._log_linthresh, np.where(a >= -self._log_linthresh, On Sat, Dec 6, 2008 at 5:09 PM, John Hunter <jd...@gm...> wrote: > There appears to be a bug in the 3rd subplot of symlog_demo.py because > the ticker is generating an OverflowError on my powerbook. > > The problem is in SymmetricalLogLocator.__call__ when the vmin, vmax = > self._transform.transform((vmin, vmax)) call transforms > vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to > 3.30039237078e+17. Then the while loop runs until I kill the job:: > > stride = 1 > while numdec/stride+1 > self.numticks: > stride += 1 > > This may have something to do with a platform specific floating point > computations, because I am seeing different results on a linux box I > am also testing on, but even there the results don't look right. For > example, on that box, a 64 bit linux machine, I see [-1,1] transformed > to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the > example does run w/o crashing. > > In any case, it looks like there is some non-robust computation going > on, and I'm hoping Michael has a quick insight :-) > > JDH > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
Unfortunately, today is a crazy day for me so I can't test until late tonight at the earliest. But Charlie, I do think we should hold the release until we resolve this. We should be able to fix and test this by tomorrow afternoon so perhaps Monday night for the release if everything is in order by then and you still have time. Sent from my iPhone On Dec 7, 2008, at 1:55 PM, "Jae-Joon Lee" <lee...@gm...> wrote: > John, > > I can't reproduce the error on my intel macbook. > Anyhow, it seems to me a bug in the code and bugs in numpy. > (I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed > in newer numpy. ) > Can you try the patch below and see if this fix your problem? > > -JJ > > > > Index: lib/matplotlib/scale.py > =================================================================== > --- lib/matplotlib/scale.py (revision 6487) > +++ lib/matplotlib/scale.py (working copy) > @@ -301,7 +301,8 @@ > self._linadjust = (np.log(linthresh) / self._log_base) / > linthre > > def transform(self, a): > - sign = np.sign(np.asarray(a)) > + a = np.asarray(a) > + sign = np.sign(a) > masked = ma.masked_inside(a, -self.linthresh, > self.linthresh, co False) > log = sign * ma.log(np.abs(masked)) / self._log_base > if masked.mask.any(): > @@ -328,6 +329,7 @@ > self._linadjust = linthresh / (np.log(linthresh) / > self._log_bas > > def transform(self, a): > + a = np.asarray(a) > return np.where(a <= self._log_linthresh, > np.where(a >= -self._log_linthresh, > > > > > > > On Sat, Dec 6, 2008 at 5:09 PM, John Hunter <jd...@gm...> wrote: >> There appears to be a bug in the 3rd subplot of symlog_demo.py >> because >> the ticker is generating an OverflowError on my powerbook. >> >> The problem is in SymmetricalLogLocator.__call__ when the vmin, >> vmax = >> self._transform.transform((vmin, vmax)) call transforms >> vmin,vmax=[-1,1] to [-3.30039237078e+17,1.0] numdec is set to >> 3.30039237078e+17. Then the while loop runs until I kill the job:: >> >> stride = 1 >> while numdec/stride+1 > self.numticks: >> stride += 1 >> >> This may have something to do with a platform specific floating point >> computations, because I am seeing different results on a linux box I >> am also testing on, but even there the results don't look right. For >> example, on that box, a 64 bit linux machine, I see [-1,1] >> transformed >> to [2.18190930577e-316, 6.90437063896e-310] and numdec=-1 but the >> example does run w/o crashing. >> >> In any case, it looks like there is some non-robust computation going >> on, and I'm hoping Michael has a quick insight :-) >> >> JDH >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, >> Nevada. >> The future of the web can't happen without you. Join us at MIX09 >> to help >> pave the way to the Next Web now. Learn more and register at >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>
I ran into the same problem independently on an Intel Mac (I didn't read these messages until now) and came up with the first part of Jae-Joon Lee's fix. It does fix the problem, at least for me - I suspect the difference may not actually be in the platform but in the exact version of numpy (I have 1.1.0). I also committed the other part of the fix. This does seem to fix the problem, but I think we should wait for confirmation from John before releasing the code. -- Jouni K. Seppänen http://www.iki.fi/jks John Hunter <jd...@gm...> writes: > Unfortunately, today is a crazy day for me so I can't test until late > tonight at the earliest. But Charlie, I do think we should hold the > release until we resolve this. We should be able to fix and test this > by tomorrow afternoon so perhaps Monday night for the release if > everything is in order by then and you still have time. > > Sent from my iPhone > > On Dec 7, 2008, at 1:55 PM, "Jae-Joon Lee" <lee...@gm...> wrote: > >> John, >> >> I can't reproduce the error on my intel macbook. >> Anyhow, it seems to me a bug in the code and bugs in numpy. >> (I'm using numpy version 1.1.1, and I'm not sure these bugs are fixed >> in newer numpy. ) >> Can you try the patch below and see if this fix your problem? >> >> -JJ >> >> >> >> Index: lib/matplotlib/scale.py >> =================================================================== >> --- lib/matplotlib/scale.py (revision 6487) >> +++ lib/matplotlib/scale.py (working copy) >> @@ -301,7 +301,8 @@ >> self._linadjust = (np.log(linthresh) / self._log_base) / >> linthre >> >> def transform(self, a): >> - sign = np.sign(np.asarray(a)) >> + a = np.asarray(a) >> + sign = np.sign(a) >> masked = ma.masked_inside(a, -self.linthresh, >> self.linthresh, co False) >> log = sign * ma.log(np.abs(masked)) / self._log_base >> if masked.mask.any(): >> @@ -328,6 +329,7 @@ >> self._linadjust = linthresh / (np.log(linthresh) / >> self._log_bas >> >> def transform(self, a): >> + a = np.asarray(a) >> return np.where(a <= self._log_linthresh, >> np.where(a >= -self._log_linthresh, >> >> >> >>
On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <jk...@ik...> wrote: > I ran into the same problem independently on an Intel Mac (I didn't read > these messages until now) and came up with the first part of Jae-Joon > Lee's fix. It does fix the problem, at least for me - I suspect the > difference may not actually be in the platform but in the exact version > of numpy (I have 1.1.0). I also committed the other part of the fix. > > This does seem to fix the problem, but I think we should wait for > confirmation from John before releasing the code. This is looking good on my end -- thanks Jae-Joon and Jouni for the patches. JDH
Just getting to this thread now. Since you asked for my insight -- I can't reproduce the bug on my Linux box, but the patch looks innocent enough if it fixes it for others. Mike John Hunter wrote: > On Mon, Dec 8, 2008 at 6:37 AM, Jouni K. Seppänen <jk...@ik...> wrote: > >> I ran into the same problem independently on an Intel Mac (I didn't read >> these messages until now) and came up with the first part of Jae-Joon >> Lee's fix. It does fix the problem, at least for me - I suspect the >> difference may not actually be in the platform but in the exact version >> of numpy (I have 1.1.0). I also committed the other part of the fix. >> >> This does seem to fix the problem, but I think we should wait for >> confirmation from John before releasing the code. >> > > This is looking good on my end -- thanks Jae-Joon and Jouni for the patches. > > JDH > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA