symlog problem

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

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 <jdh2358@...149...> 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 :slight_smile:

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
Matplotlib-devel@lists.sourceforge.net
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 <jdh2358@...149...> 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 :slight_smile:

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
Matplotlib-devel@lists.sourceforge.net
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.j.joon@...149...> 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 <jdh2358@...149...> 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 :slight_smile:

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