matplotlib-devel Mailing List for matplotlib

I am not at my computer so I can't check the maintenace branch 
changelog, but I know there have been a few bugfixes. Do any of them 
look significant? How many downloads have we seen on the maintenance 
branch vs the 98 trunk. My guess is there are not that many users and 
we could skip a cycle on the branch.
Sent from my iPhone
On Dec 7, 2008, at 2:46 PM, "Charlie Moad" <cw...@gm...> wrote:
> Is there any need for a maintenance release?
>
> On Thu, Dec 4, 2008 at 1:53 PM, John Hunter <jd...@gm...> wrote:
>> On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <cw...@gm...> 
>> wrote:
>>> Works for me. Let's aim for Saturday night so we have Sunday to 
>>> test
>>> it out. Doable?
>>
>> Great -- everyone please hold off adding any significant features
>> before the release and focus any mpl time you have on outstanding
>> bugs.
>>

I just committed the change. Although the change is trivial, I didn't
tested it in the numpy 1.2 or the svn version.
-JJ
On Sun, Dec 7, 2008 at 3:24 PM, John Hunter <jd...@gm...> wrote:
> I think the version check is a good idea, so people won't get the annoying
> warning. Could you add this?
>
> Sent from my iPhone
>
> On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
>
>> I'm currently using numpy 1.1.1 and np.histogram behave differently
>> depending on the "new" value.
>> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
>> this different behavior is still there.
>> So, as far as we're going to support numpy 1.1 and later, we may
>> better not to drop the "new" silently.
>> We may check the version number of the numpy in the hist() function,
>> and call np.histogram() accordingly.
>>
>> -JJ
>>
>>
>> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
>>>
>>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>>> deprecation warning with svn numpy. Anyone have an opinion on whether
>>> this kwarg should be included in the upcoming mpl release?
>>>
>>> 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
>>

Is there any need for a maintenance release?
On Thu, Dec 4, 2008 at 1:53 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Dec 4, 2008 at 12:38 PM, Charlie Moad <cw...@gm...> wrote:
>> Works for me. Let's aim for Saturday night so we have Sunday to test
>> it out. Doable?
>
> Great -- everyone please hold off adding any significant features
> before the release and focus any mpl time you have on outstanding
> bugs.
>

I think the version check is a good idea, so people won't get the 
annoying warning. Could you add this?
Sent from my iPhone
On Dec 7, 2008, at 2:22 PM, "Jae-Joon Lee" <lee...@gm...> wrote:
> I'm currently using numpy 1.1.1 and np.histogram behave differently
> depending on the "new" value.
> ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
> this different behavior is still there.
> So, as far as we're going to support numpy 1.1 and later, we may
> better not to drop the "new" silently.
> We may check the version number of the numpy in the hist() function,
> and call np.histogram() accordingly.
>
> -JJ
>
>
> On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
>> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
>> deprecation warning with svn numpy. Anyone have an opinion on 
>> whether
>> this kwarg should be included in the upcoming mpl release?
>>
>> 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'm currently using numpy 1.1.1 and np.histogram behave differently
depending on the "new" value.
ubuntu interpid and debian sid has numpy 1.1.1.1 and I presume that
this different behavior is still there.
So, as far as we're going to support numpy 1.1 and later, we may
better not to drop the "new" silently.
We may check the version number of the numpy in the hist() function,
and call np.histogram() accordingly.
-JJ
On Sat, Dec 6, 2008 at 4:33 PM, John Hunter <jd...@gm...> wrote:
> Axes.hist calls np.histogram with the "new" kwarg, which triggers a
> deprecation warning with svn numpy. Anyone have an opinion on whether
> this kwarg should be included in the upcoming mpl release?
>
> 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
>

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
>