matplotlib-devel Mailing List for matplotlib (Page 9)

On Sun, Aug 9, 2009 at 2:01 PM, Jouni K. Seppänen<jk...@ik...> wrote:

> I think mirroring a directory structure is somewhat more complicated
> than caching a set of arbitrary URLs in a flat cache directory. For
> example, I think the remove_stale_files method will need to be changed
> to walk all subdirectories, and handling cases such as having a
> subdirectory named foo that is replaced by a file named foo could be
> complicated.
>
> One thing that's still missing is off-line usage: if the user does not
> have net connectivity at the moment but does have the file in the cache,
> it should not cause an error.
>
> Perhaps the base URL should be
> http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/
> instead of
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/sample_data/
> to avoid dependency on the viewvc service of SourceForge.

Would you like to take a crack at these fixes?  I have scipy coming up
and need to start getting my tutorial material together, so I am not
going to have a lot of time for bug fixes, though I would be happy to
get as many fixes and patches in next week and try to get one bugfix
0.99.1 out before scipy.

JDH

jas...@cr... wrote:
> Here are a few patches that we in Sage have been applying to our version 
> of matplotlib.  I'm wondering if some or all of these might be 
> incorporated into matplotlib, or if not, if you could comment on these 
> patches.  I've updated the following diffs to be against 0.99.0.  I've 
> separated the patches with a bunch of dashes.

Jason,

I have committed versions of all but the third to the v0.99 branch. 
Please check svn r7442-7444.  I also propagated them to the trunk.  If 
you have any questions or reservations about the modifications I made, 
please raise them!  (The modification to #1 is because blanket "except:" 
is highly discouraged in mpl, and seemed unnecessary here.  The 
modification to #4 is for code clarity, to make it even more obvious 
that the empty string is used as the version only in case of an exception.)

I did not commit #3.  Apart from my lack of c++ expertise, I don't know 
how to implement it so that it takes effect only in the Solaris case. 
Therefore I am leaving this for John; or maybe he will pass it to Mike 
when he comes back from vacation.  Below, I am deleting all but #3, to 
make it easier for John to see what we are talking about.

Eric

> ---------------------------------------------------------------------------------------------------------------------------------------
> ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` = 
> "SunOS".  The comment is: Copy patched version of pprdrv_tt2.cpp for 
> Solaris 10 that builds with gcc 4.3.2.
> 
> 
> --- src/ttconv/pprdrv_tt2.cpp    2009-08-01 12:15:15.000000000 -0700
> +++ patches/pprdrv_tt2.cpp    2009-08-08 23:33:24.000000000 -0700
> @@ -104,7 +104,8 @@
>      {                /* have a log of points. */
>      if(stack_depth == 0)
>          {
> -            stream.put_char('{');
> +            //  Note the below is a hack to make it compile on Solaris 
> 10 with gcc 4.3.2
> +            stream.puts("{");
>              stack_depth=1;
>              }
>  
> 
> 
> --------------------------------------------------------------------------------------------------------------------------------------------

John Hunter <jd...@gm...> writes:

> * I commented out the random number appending, because I do not see
> the use case, but we can re-add it when you enlighten me :-)

I did that in case someone wanted to retrieve files from several
different locations -- my version of the cache handler was not tied to
any particular base URL. Since all cached files were in one flat
directory, there was the danger of filename collisions. 

> * I added support for nested subdirs, so you can now do, as in
> examples/misc/sample_data_test.py::
>
>     datafile = 'testdir/subdir/testsub.csv'
>     fh = cbook.get_sample_data(datafile)

I think mirroring a directory structure is somewhat more complicated
than caching a set of arbitrary URLs in a flat cache directory. For
example, I think the remove_stale_files method will need to be changed
to walk all subdirectories, and handling cases such as having a
subdirectory named foo that is replaced by a file named foo could be
complicated.

One thing that's still missing is off-line usage: if the user does not
have net connectivity at the moment but does have the file in the cache,
it should not cause an error.

Perhaps the base URL should be 
http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/
instead of
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/sample_data/
to avoid dependency on the viewvc service of SourceForge.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi John,

I've seen them both and will apply try to fix them. I've also
submitted a support request to sourceforge to see if they can fix the
bug assignment issue. It's ok if you assign mplot3d bugs to me then.

Cheers,
Reinier

On Sat, Aug 8, 2009 at 2:33 PM, John Hunter<jd...@gm...> wrote:
> On Fri, Aug 7, 2009 at 8:27 AM, Reinier Heeres<re...@he...> wrote:
>> Hi,
>>
>> This looks great! I'd be happy to try and work on this for mplot3d as well.
>>
>> Ryan: as for your patch, I'll look at it over the weekend or next week
>> and see if I can apply it to trunk.
>
> Hey Reinier, while you are looking these over, I just wanted to make
> sure you saw these two mplo3d bugs posted on the tracker
>
>  https://sourceforge.net/tracker/?func=detail&aid=2830483&group_id=80706&atid=560720
>  https://sourceforge.net/tracker/?func=detail&aid=2834105&group_id=80706&atid=560720
>
> Normally, I can assign bugs on the tracker to a developer, but for
> some reason even though you are permissioned in the
> "Members" area for the tracker, your sf login isn't showing up in the
> drop down of developers on the bugs page.  If you are unable o manage
> the bug, eg to change the resolution or status, let me know after you
> have taken a look at these and I can close or update them as
> necessary.
>
> JDH
>



-- 
Reinier Heeres
Tel: +31 6 10852639

Here are a few patches that we in Sage have been applying to our version 
of matplotlib.  I'm wondering if some or all of these might be 
incorporated into matplotlib, or if not, if you could comment on these 
patches.  I've updated the following diffs to be against 0.99.0.  I've 
separated the patches with a bunch of dashes.


lib/matplotlib/cbook.py: The background information for this patch is 
found at http://trac.sagemath.org/sage_trac/ticket/1967 and 
http://groups.google.com/group/sage-support/browse_thread/thread/edcf2740f7276e6a?hl=en#78ee7d78a0a99f12

--- src/lib/matplotlib/cbook.py    2009-08-01 12:15:07.000000000 -0700
+++ patches/cbook.py    2009-08-08 23:15:21.000000000 -0700
@@ -14,7 +14,10 @@
 
 
 # on some systems, locale.getpreferredencoding returns None, which can 
break unicode
-preferredencoding = locale.getpreferredencoding()
+try:
+    preferredencoding = locale.getpreferredencoding()
+except:
+    preferredencoding = None
 
 def unicode_safe(s):
     if preferredencoding is None: return unicode(s)



-----------------------------------------------------------------------------------------------------------------------------------------------


lib/matplotlib/patches.py:  The comment attached to this patch was  '* 
Add a patch for patches.py, which ignores the errors generated when 
trying to draw arrows that are "too short".'  I actually made this 
patch, so if it isn't obvious what the patch is doing and why it was 
causing an error before, I can try to remember and construct an example.

--- src/lib/matplotlib/patches.py    2009-08-01 12:15:07.000000000 -0700
+++ patches/patches.py    2009-08-08 23:25:09.000000000 -0700
@@ -2326,15 +2326,21 @@
                 x, y = path.vertices[0]
                 insideA = inside_circle(x, y, shrinkA)
 
-                left, right = split_path_inout(path, insideA)
-                path = right
+                try:
+                    left, right = split_path_inout(path, insideA)
+                    path = right
+                except ValueError:
+                    pass
 
             if shrinkB:
                 x, y = path.vertices[-1]
                 insideB = inside_circle(x, y, shrinkB)
 
-                left, right = split_path_inout(path, insideB)
-                path = left
+                try:
+                    left, right = split_path_inout(path, insideB)
+                    path = left
+                except ValueError:
+                    pass
 
             return path
 


---------------------------------------------------------------------------------------------------------------------------------------
ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` = 
"SunOS".  The comment is: Copy patched version of pprdrv_tt2.cpp for 
Solaris 10 that builds with gcc 4.3.2.


--- src/ttconv/pprdrv_tt2.cpp    2009-08-01 12:15:15.000000000 -0700
+++ patches/pprdrv_tt2.cpp    2009-08-08 23:33:24.000000000 -0700
@@ -104,7 +104,8 @@
     {                /* have a log of points. */
     if(stack_depth == 0)
         {
-            stream.put_char('{');
+            //  Note the below is a hack to make it compile on Solaris 
10 with gcc 4.3.2
+            stream.puts("{");
             stack_depth=1;
             }
 


--------------------------------------------------------------------------------------------------------------------------------------------

setupext.py: The background for this patch is here: 
http://trac.sagemath.org/sage_trac/ticket/4176


--- src/setupext.py     2009-08-01 12:15:24.000000000 -0700
+++ patches/setupext.py 2009-08-08 23:43:29.000000000 -0700
@@ -1034,6 +1038,7 @@
         #      of distros.
 
         # Query Tcl/Tk system for library paths and version string
+        tk_ver = ''
         try:
             tcl_lib_dir, tk_lib_dir, tk_ver = query_tcltk()
         except:



Thanks!

Jason

On Fri, Aug 7, 2009 at 8:27 AM, Reinier Heeres<re...@he...> wrote:
> Hi,
>
> This looks great! I'd be happy to try and work on this for mplot3d as well.
>
> Ryan: as for your patch, I'll look at it over the weekend or next week
> and see if I can apply it to trunk.

Hey Reinier, while you are looking these over, I just wanted to make
sure you saw these two mplo3d bugs posted on the tracker

  https://sourceforge.net/tracker/?func=detail&aid=2830483&group_id=80706&atid=560720
  https://sourceforge.net/tracker/?func=detail&aid=2834105&group_id=80706&atid=560720

Normally, I can assign bugs on the tracker to a developer, but for
some reason even though you are permissioned in the
"Members" area for the tracker, your sf login isn't showing up in the
drop down of developers on the bugs page.  If you are unable o manage
the bug, eg to change the resolution or status, let me know after you
have taken a look at these and I can close or update them as
necessary.

JDH

Eric Firing wrote:
> Michael Droettboom wrote:
>> I've tracked it down to this revision 7395
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395 
>>
> 
> That was John's.  I knew there was a reason why I had written it the way 
> it was before his change, but I didn't remember what that reason was, 
> and didn't spend any time thinking about it.
>> was was in response to bug *2832575*
>>
>> http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720 
>>
>>
>> I think this is reaching my limit of understanding of the color mapping 
>> code, so I'm hoping someone else has a solution that will fix one bug 
>> without creating another ;)
> 
> Yes, this will require some thought.  It is just another aspect of the 
> alpha mess in mpl in general.
> I think there may be at least a crude fix for both the old bug and the 
> new one.  I will look at it later.

OK, I applied the crude fix.  I think it is good enough, and makes sense 
within the present framework.  The basic idea is that the default for 
colormapping missing data was, and now again is, to use alpha=0 so as 
not to show it at all.  It can be overridden by using the set_bad() 
method of the colormap.  The problem was that the over- and under-range 
colors were being excluded from global alpha-setting, along with the bad 
color. Now over- and under- are treated like the rest of the colormap, 
but alpha for the bad values defaults to zero and must be set explicitly 
to another value if desired.

The svnmerge afterwards (r7425) makes me a little nervous, because it 
pulled in a lot of things that I did not change and that I know nothing 
about.  Upon a quick scan the changes look plausible.

Eric

> 
> Eric
> 

Jae-Joon Lee wrote:
> My understanding is that MOVETO in the middle of the path serve as a
> CLOSEPOLY when the path is filled. So, I don't think it actually
> matters how holes are connected each other. And as you can see, the
> largest hole is actually composed of three different polygons that
> overlaps, and the funny pattern is due to this overlaps.
> 
> The attached is my attempt to solve this problem. "remove_cuts"
> removes the cuts in a way that a hole becomes a single closed polygon,
> although I'm not sure if the code is rigorous enough. It seems to work
> okay for your sample data. It assumes that cuts are always vertical
> lines but this assumption can be dropped if we do bookkepping of all
> the path segments.
> I hope the code turns out to be work okay in general.
> 
> Ideally, it would be better if something similar would be done inside
> the contouring routine.

An implementation of the path conversion is now in the reorder() 
function in cntr.c; as of svn r7422, it is used by contourf (and by 
contour, although for line contours it is merely copying data into the 
output arrays).  In addition to the contourf_demo.py, I have tested it 
with basemap's simpletest.py and with random data, without detecting any 
obvious artifacts.  More testing is welcome, of course.

Eric

> 
> -JJ
> 
> 
> 
> On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
>> Mike,
>>
>> When I eliminate the cuts from filled contour paths, I do find pathological
>> cases where the filling works correctly with the cuts in place, but not
>> without them.  Attached are a data file and a script to plot it,
>> illustrating the problem.  Is this due to a known limitation of filled
>> paths?  In the example, the top two holes are connected to the lower hole,
>> instead of being connected directly to the outer boundary of the filled
>> region.  Is this illegal?  If so, I think we are stuck, because rearranging
>> the paths that cntr makes to eliminate this type of case would likely be
>> very difficult.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> ------------------------------------------------------------------------
>>

Michael Droettboom wrote:
> I've tracked it down to this revision 7395
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395 
> 

That was John's.  I knew there was a reason why I had written it the way 
it was before his change, but I didn't remember what that reason was, 
and didn't spend any time thinking about it.
> 
> was was in response to bug *2832575*
> 
> http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720 
> 
> 
> I think this is reaching my limit of understanding of the color mapping 
> code, so I'm hoping someone else has a solution that will fix one bug 
> without creating another ;)

Yes, this will require some thought.  It is just another aspect of the 
alpha mess in mpl in general.
I think there may be at least a crude fix for both the old bug and the 
new one.  I will look at it later.

Eric


> 
> Cheers,
> Mike
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, Aug 7, 2009 at 11:54 AM, Andrew Straw<str...@as...> wrote:

>> But would this also make the spine have the larger limits?  Basically,
>> I want know if the spines can be used to create Tufte-style
>> range-frames.  Am I correct in thinking that these spines provide that?
> Although I don't have a precise definition of "Tufte-style range
> frame"to go by, I think my intention was to do exactly what you're after.

One thing you want with range frames is to have the length of the
spine equal the span of your dataset.  Can we currently or with not
too much effort define the line segment of the spine to be in data
coords?  Then we could make the axes as wide as we want with the ylim
to maintain the clipping region, but the spine would cover just the
span of the data (or whatever the user specified) rather than always
being ymin...ymax if it is defined as 0..1 in axes coords.

JDH

On Fri, Aug 7, 2009 at 2:42 PM, Ryan Wagner<rw...@vn...> wrote:
> Works for me :)

Ditto -- thanks for the quick fix.

JDH

Works for me :)

Should be fixed in SVN now.

Mike

John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
>   
>> Mike, do you see this on your side?
>>
>> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>>     
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
>   

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

I think I almost have a solution.  Just running backend_driver.py now.

Mike

John Hunter wrote:
> On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
>   
>> Mike, do you see this on your side?
>>
>> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
>> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***
>>     
>
> I'm seeing a core dump on this one (clean build and install of HEAD).
>
> johnh@:svn> cd ~/mpl/examples/mplot3d/
> johnh@:mplot3d> python surface3d_demo.py
> Segmentation Fault (core dumped)
> johnh@:mplot3d> uname -a
> SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc
>   

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

On Fri, Aug 7, 2009 at 2:19 PM, Ryan Wagner<rw...@vn...> wrote:
> Mike, do you see this on your side?
>
> ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py
> *** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***

I'm seeing a core dump on this one (clean build and install of HEAD).

johnh@:svn> cd ~/mpl/examples/mplot3d/
johnh@:mplot3d> python surface3d_demo.py
Segmentation Fault (core dumped)
johnh@:mplot3d> uname -a
SunOS userver210 5.10 Generic_138889-06 i86pc i386 i86pc

Mike, do you see this on your side?

ryan@ubuntu-desktop:~/matplotlib/examples/mplot3d$ python surface3d_demo.py 
*** glibc detected *** python: free(): invalid pointer: 0xbffb3d10 ***

-----Original Message-----
From: Michael Droettboom [mailto:md...@st...] 
Sent: Friday, August 07, 2009 1:00 PM
To: John Hunter
Cc: Reinier Heeres; Ryan Wagner; mat...@li...
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

John Hunter wrote:
>
> BTW, it looks like the edges of the polys are aliased in the "masked"
> side of the figure.  Have you noticed this?
>   
Yeah -- the right hand side is still using the old code path, which is 
aliased by default.

Cheers,
Mike

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

Wow, no kidding John, what a difference! Great work Mike!

-----Original Message-----
From: John Hunter [mailto:jd...@gm...] 
Sent: Friday, August 07, 2009 12:54 PM
To: Michael Droettboom
Cc: Reinier Heeres; Ryan Wagner; mat...@li...
Subject: Re: [matplotlib-devel] Adding Shades Keyword to 3D routines.

On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<md...@st...> wrote:

> I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
> really sufficient for drawing interpolated quad meshes, because of the
> effect described here:
>
> http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false
>
> Running quadmesh_demo.py, you can see some sharp edges between triangles in
> the same quad, but it's not too bad in all places.  If anyone has any ideas
> about how to ameliorate that effect, feel free to have a crack at it.  I
> just wanted to get a proof-of-concept starting point in before heading on
> vacation for a few days.

Wow -- hat tip to you!  With productivity like this, how can we afford
to lose you for a few days to vacation :-)

I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56.  Very nice.

I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend.  Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach  <wink>

BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure.  Have you noticed this?

JDH

John Hunter wrote:
>
> BTW, it looks like the edges of the polys are aliased in the "masked"
> side of the figure.  Have you noticed this?
>   
Yeah -- the right hand side is still using the old code path, which is 
aliased by default.

Cheers,
Mike

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

On Fri, Aug 7, 2009 at 1:39 PM, Michael Droettboom<md...@st...> wrote:

> I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are
> really sufficient for drawing interpolated quad meshes, because of the
> effect described here:
>
> http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false
>
> Running quadmesh_demo.py, you can see some sharp edges between triangles in
> the same quad, but it's not too bad in all places.  If anyone has any ideas
> about how to ameliorate that effect, feel free to have a crack at it.  I
> just wanted to get a proof-of-concept starting point in before heading on
> vacation for a few days.

Wow -- hat tip to you!  With productivity like this, how can we afford
to lose you for a few days to vacation :-)

I had to run the example with mpl99 to appreciate the changes, since
you decreased the n from 56 to 12 to show off the effects of the
interpolation, and the interpolation with n=12 is about as visually
good as the grid w/o with n=56.  Very nice.

I don't have time to dig into the code now since I have some pressing
work stuff, but I look forward to doing a read-through over the
weekend.  Enjoy your vacation, but don't forget your computer graphics
texts and laptop -- I think lighting, shadows and several shaders
should get you through a few days on the beach  <wink>

BTW, it looks like the edges of the polys are aliased in the "masked"
side of the figure.  Have you noticed this?

JDH

I have experimental support for Gouraud-shaded pcolormeshes with the Agg 
backend only in SVN trunk.  The backend interface will likely change to 
better support PDF, where doing multiple triangles at a time is much 
more efficient.  This is just the easiest and far from optimal way to do it.

I'm not sure if Gouraud triangles (as supported by Agg, PDF and PS) are 
really sufficient for drawing interpolated quad meshes, because of the 
effect described here:

http://books.google.com/books?id=19SpFYj82owC&lpg=PA280&ots=r3gnxKn9As&dq=shading%20quadrilaterals%20with%20gouraud%20triangles&pg=PA281#v=onepage&q=&f=false

Running quadmesh_demo.py, you can see some sharp edges between triangles 
in the same quad, but it's not too bad in all places.  If anyone has any 
ideas about how to ameliorate that effect, feel free to have a crack at 
it.  I just wanted to get a proof-of-concept starting point in before 
heading on vacation for a few days.

Cheers,
Mike

Reinier Heeres wrote:
> Hi,
>
> This looks great! I'd be happy to try and work on this for mplot3d as well.
>
> Ryan: as for your patch, I'll look at it over the weekend or next week
> and see if I can apply it to trunk.
>
> Regards,
> Reinier
>
> On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<md...@st...> wrote:
>   
>> Nevermind -- this is in Agg 2.4 as well.  Don't know why I missed it
>> yesterday.  I'll have a look into this to see how well we can integrate it.
>>
>> Cheers,
>> Mike
>>
>> Michael Droettboom wrote:
>>     
>>> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
>>> Isn't this a no-go for us because it's GPL'd?
>>>
>>> Cheers,
>>> Mike
>>>
>>> John Hunter wrote:
>>>
>>>       
>>>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>>>
>>>>
>>>>
>>>>         
>>>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>>>> map, and here we need to at least interpolate between the three points of a
>>>>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>>>>> it's just that the gradient code won't help us.
>>>>>
>>>>>
>>>>>           
>>>> I checked in with the antigrain mailing list, as was pointed to
>>>> examples/gouraud.cpp.  This looks like what we want, no?
>>>>
>>>> wget http://www.antigrain.com/agg-2.5.tar.gz
>>>> tar xvfz agg-2.5.tar.gz
>>>> cd agg-2.5
>>>> make
>>>> cd examples/X11/
>>>> make gouraud
>>>> ./gouraud
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>         
>>>       
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>     
>
>   

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

I've tracked it down to this revision 7395

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395

was was in response to bug *2832575*

http://sourceforge.net/tracker/?func=detail&aid=2832575&group_id=80706&atid=560720

I think this is reaching my limit of understanding of the color mapping 
code, so I'm hoping someone else has a solution that will fix one bug 
without creating another ;)

Cheers,
Mike

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

John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rw...@vn...> wrote:
>>> Does your workaround work for all supported backends, and with alpha
>>> less than 1?  If so, what is it?
>> I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!
> 
> I agree with Eric that lw=0 should mean draw no line at all.  In
> postscript, linewidth=0 means "draw the thinnest line you can" but
> early on we overrode this behavior to make the postscript backend
> consistent with other mpl backends, so that linewidth=0 means draw no
> line at all.  I think 3D should be consistent with this.  But setting
> the edgecolors=facecolors should be fine too -- either of these or
> both can be tested to see what gives the best behavior at the edges.
> 
> JDH


edgecolors=facecolors may cause artifacts with alpha < 1; at least that 
was the experience when we last experimented with similar problems in 
filled contours.

Eric

Brian Granger wrote:
>  
>
>     I think this happens in all mpl graphs, you just don't see it.  The
>     axis limits are set to -2..2, and the sine is draw from -2..2.  The
>     linewidth extends beyond 2, so it is clipped by the axes clipping to
>     the bounding rectangle.  Normally you don't see this, because visually
>     it is under the surrounding axes black edge.  
>
>
> Yes, I saw that it looks like it happens under the axes clipping.
>
>  
>
>     You can either set the
>     ylimits wider:
>
>       ax.set_ylim(-2.1, 2.1)
>
>
> But would this also make the spine have the larger limits?  Basically, 
> I want know if the spines can be used to create Tufte-style 
> range-frames.  Am I correct in thinking that these spines provide that?
Although I don't have a precise definition of "Tufte-style range 
frame"to go by, I think my intention was to do exactly what you're after.

I don't know how hard it would be to automatically increase the clipping 
box size by the size (line width or marker size, including edge width) 
of any artists on the border -- I imagine it may require querying 
backends in a way they don't currently support. I'll talk about this 
with John at SciPy 09.

>   Or is there another way to get a range-frame?
>  
>
>     or turn clipping off
>
>      ax.plot(x,y, clip_on=False)
>
>
> This looks hopeful and I will give it a shot.
That's what I've been doing.

Hi,

This looks great! I'd be happy to try and work on this for mplot3d as well.

Ryan: as for your patch, I'll look at it over the weekend or next week
and see if I can apply it to trunk.

Regards,
Reinier

On Fri, Aug 7, 2009 at 3:02 PM, Michael Droettboom<md...@st...> wrote:
> Nevermind -- this is in Agg 2.4 as well.  Don't know why I missed it
> yesterday.  I'll have a look into this to see how well we can integrate it.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
>> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.
>> Isn't this a no-go for us because it's GPL'd?
>>
>> Cheers,
>> Mike
>>
>> John Hunter wrote:
>>
>>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>>
>>>
>>>
>>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>>> map, and here we need to at least interpolate between the three points of a
>>>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>>>> it's just that the gradient code won't help us.
>>>>
>>>>
>>> I checked in with the antigrain mailing list, as was pointed to
>>> examples/gouraud.cpp.  This looks like what we want, no?
>>>
>>> wget http://www.antigrain.com/agg-2.5.tar.gz
>>> tar xvfz agg-2.5.tar.gz
>>> cd agg-2.5
>>> make
>>> cd examples/X11/
>>> make gouraud
>>> ./gouraud
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA

-- 
Reinier Heeres
Tel: +31 6 10852639

Nevermind -- this is in Agg 2.4 as well.  Don't know why I missed it 
yesterday.  I'll have a look into this to see how well we can integrate it.

Cheers,
Mike

Michael Droettboom wrote:
> Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.  
> Isn't this a no-go for us because it's GPL'd?
>
> Cheers,
> Mike
>
> John Hunter wrote:
>   
>> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>>
>>   
>>     
>>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>>> map, and here we need to at least interpolate between the three points of a
>>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>>> it's just that the gradient code won't help us.
>>>     
>>>       
>> I checked in with the antigrain mailing list, as was pointed to
>> examples/gouraud.cpp.  This looks like what we want, no?
>>
>> wget http://www.antigrain.com/agg-2.5.tar.gz
>> tar xvfz agg-2.5.tar.gz
>> cd agg-2.5
>> make
>> cd examples/X11/
>> make gouraud
>> ./gouraud
>>   
>>
>> ------------------------------------------------------------------------
>>
>>     
>
>   

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