matplotlib-devel Mailing List for matplotlib (Page 9)

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

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

On Sun, Dec 7, 2008 at 2:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
> I just committed the change. Although the change is trivial, I didn't
> tested it in the numpy 1.2 or the svn version.

I tested on numpy svn on a couple of platforms (OS X and linux) and
this looks OK from my end.

In the examples/pylab_examples/custom_cmap.py example, I am seeing a
pixel red border, eg colored red on the top border of the middle
subplot, where it looks like it should be blue.  Image attached.  Is
this an artifact of the breakpoint of the colormap, or a true
rendering bug?

JDH

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,
>>
>>
>>
>>

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
>

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

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

Tony,

Sorry. It turned to be a bug I introduced during the update.
It should be fixed in r6499.
Thanks,

-JJ



On Fri, Dec 5, 2008 at 3:47 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Tony,
>
> I'll look at this problem.
> Anyhow, it seems to me that it happens because the handle length is too short.
> Can you try longer handle length and see what happens?
> The code for drawing handles are mostly identical to the previous one.
>
> Regards,
>
> -JJ
>
>
> On Fri, Dec 5, 2008 at 1:46 PM, Tony Yu <ts...@gm...> wrote:
>>
>> On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
>>
>>> John,
>>>
>>> I just committed changes to SVN that reflect most of your comments.
>>> I didn't add the optional transformation support yet though.
>>
>>
>> I'm getting a truncated line when calling:
>>
>>>>> plt.legend(numpoints=1)
>>
>> In the legend, I see a short dashed line followed by the marker. Before, the
>> line went through the marker. I've attached a couple of images showing
>> numpoints set to 1 and 2.
>>
>> I think this behavior was introduced with the improved legend class.
>>
>> Thanks,
>> -Tony
>>
>>
>>
>>
>> mpl svn 6497
>>
>

Tony,

I'll look at this problem.
Anyhow, it seems to me that it happens because the handle length is too short.
Can you try longer handle length and see what happens?
The code for drawing handles are mostly identical to the previous one.

Regards,

-JJ


On Fri, Dec 5, 2008 at 1:46 PM, Tony Yu <ts...@gm...> wrote:
>
> On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:
>
>> John,
>>
>> I just committed changes to SVN that reflect most of your comments.
>> I didn't add the optional transformation support yet though.
>
>
> I'm getting a truncated line when calling:
>
>>>> plt.legend(numpoints=1)
>
> In the legend, I see a short dashed line followed by the marker. Before, the
> line went through the marker. I've attached a couple of images showing
> numpoints set to 1 and 2.
>
> I think this behavior was introduced with the improved legend class.
>
> Thanks,
> -Tony
>
>
>
>
> mpl svn 6497
>

On Dec 4, 2008, at 7:21 PM, Jae-Joon Lee wrote:

> John,
>
> I just committed changes to SVN that reflect most of your comments.
> I didn't add the optional transformation support yet though.


I'm getting a truncated line when calling:

 >>> plt.legend(numpoints=1)

In the legend, I see a short dashed line followed by the marker.  
Before, the line went through the marker. I've attached a couple of  
images showing numpoints set to 1 and 2.

I think this behavior was introduced with the improved legend class.

Thanks,
-Tony

Eric Firing wrote:
> Ryan May wrote:
>> Now, what about dates?  I'm having problems using dates for the x-axis 
>> for fill_between.  I know I can use date2num on my array, but I was 
>> wonder if there was some magic I could add to the fill_between code.
> 
> Magic is the operative word.  It is sprinkled like pixie dust throughout 
> mpl.  You may be able to figure it out by looking at the code for other 
> functions that do support units.  You could look for recent commits by 
> Ted Drain, if I remember correctly, and by John, both of whom fill gaps 
> in units handling every now and then.
> 
> For example, note this line at the top of scatter:
> 
>         self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)

Well, combine all that pixie dust with a few wonderful thoughts, and we should 
all be flying like Peter Pan! :)

Seriously, thanks for the pointer.  _process_unit_info() combined with 
convert_[x|y]units() made it work.  Old example and my own code here both work. 
Checked into r6497.

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

John,

I just committed changes to SVN that reflect most of your comments.
I didn't add the optional transformation support yet though.


On Tue, Dec 2, 2008 at 7:45 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <lee...@gm...> wrote:
>
>> As implementing an optional transformation should be trivial, I'll
>> just go ahead an work on it. But it seems not clear to me how to
>> approach this without any specific use case given.
>
> In another thread yesterday, someone was asking about a general way to
> create a shadow effect.  It occurred to me that we could probably use
> the offsetbox for this.  One could create an offset box for a given
> artist that draws the artist offset from the original by 5 points or 5
> pixels, in a gray color that creates the appearance of a shadow.
> Would this be a reasonable use case to test the offset transformation
> in either points or pixels?
>
> JDH
>

I kind of prefer to use transforms.offset_copy() for simple offsets.
But it may better to use some kind of container (e.g., offsetbox) if
you have multiple artists.
I'll think about it.

Regards,

-JJ

Ryan May wrote:
> Ryan May wrote:
>> Hi,
>>
>> Is there any reason pyplot.fill() doesn't support masked arrays?  Or was 
>> it just overlooked?
> 
> Looks like this is better handled by fill_between, nevermind.
> 
> Now, what about dates?  I'm having problems using dates for the x-axis for 
> fill_between.  I know I can use date2num on my array, but I was wonder if there 
> was some magic I could add to the fill_between code.

Magic is the operative word.  It is sprinkled like pixie dust throughout 
mpl.  You may be able to figure it out by looking at the code for other 
functions that do support units.  You could look for recent commits by 
Ted Drain, if I remember correctly, and by John, both of whom fill gaps 
in units handling every now and then.

For example, note this line at the top of scatter:

         self._process_unit_info(xdata=x, ydata=y, kwargs=kwargs)


Eric

> 
> Ryan
> 

Ryan May wrote:
> Hi,
> 
> Is there any reason pyplot.fill() doesn't support masked arrays?  Or was 
> it just overlooked?

Looks like this is better handled by fill_between, nevermind.

Now, what about dates?  I'm having problems using dates for the x-axis for 
fill_between.  I know I can use date2num on my array, but I was wonder if there 
was some magic I could add to the fill_between code.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Hi,
> 
> Is there any reason pyplot.fill() doesn't support masked arrays?  Or was it just 
> overlooked?
> 

I think the reason is that it is not obvious what any filled region with 
masked vertices should look like.

Eric

Hi,

Is there any reason pyplot.fill() doesn't support masked arrays?  Or was it just 
overlooked?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Getting git-svn installed without root privileges is truly epic, given 
there are virtually no installation instructions for it, and its 
homepage seems to be down.  This doesn't bode well for git-svn adoption 
in managed environments like mine where users don't have root.  In 
fairness, the hard bit is Subversion and its perl bindings, but those do 
need to be current, and the commonly available advice to install 
Alien::SVN using cpan is totally broken for non-root installs.  I hope 
that the git-svn guys can simplify this down the road...

So, I thought I'd share my solution here to save others the trouble...

###Don't use cpan to install Alien::SVN -- it should have made this 
whole thing really easy, but it has a number of known bugs when 
installing without root.###

Here's what worked for me.  I have a folder ~/usr for my usual 
user-local installs, that's already been set up with the usual 
environment variables in my .bashrc:

   export PATH=~/usr/bin:$PATH
   export LD_LIBRARY_PATH=~/usr/lib:$LD_LIBRARY_PATH
   export PKG_CONFIG_PATH=~/usr/lib/pkgconfig:$PKG_CONFIG_PATH

1) Download and install openssl from www.openssl.org/source

   tar zvxf openssl-0.9.8i.tar.gz
   cd openssl-0.9.8i
   ./configure --prefix=/home/mdroe/usr
   make -j
   make install

2) Download subversion tarball

   cd ..
   tar jxvf subversion-1.5.4.tar.bz2
   cd subversion-1.5.4

3) Download neon inside the subversion source tree, and configure

    wget http://www.webdav.org/neon/neon-0.27.2.tar.gz
    tar zvxf neon-0.27.2.tar.gz
    mv neon-0.27.2 neon
    cd neon
    ./configure --prefix=/home/mdroe/usr --without-gssapi --with-ssl=openssl

4) Get apr and apr-util, and configure

    svn co http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x apr
    cd apr
    ./buildconf
    cd ..
    svn co http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x 
apr-util
    cd apr-util
    ./buildconf
    cd ..

5) Build subversion

    ./autogen.sh
    ./configure --prefix=/home/mdroe/usr --with-ssl --enable-shared
    make -j
    make install

6) Build perl bindings

    make swig-pl
    make swig-pl-lib
    make install-swig-pl-lib
    cd subversion/bindings/swig/perl/native
    perl Makefile.PL PREFIX=/home/mdroe/usr
    make install
    cd ../../../../../..

7) Download, build and install git

   tar zvxf get-1.6.0.tar.gz
   cd git-1.6.0
   ./configure --prefix=/home/mdroe/usr
   make install


... follow Andrew Straw's git instructions ... (???) ... profit!!!

Mike

   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA