matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] jsxgraph or flot backend (or interactive viewer for svg backend?)

[Jason G. <jas...@cr...>]

On 12/7/11 10:27 PM, Chris Barker wrote:
> On 12/5/11 9:49 PM, Jason Grout wrote:
>> Has anyone ever worked on a backend that generates javascript code for
>> one of the javascript plotters out there (like jsxgraph or flot)?
>> Alternatively, I suppose we could generate an svg or html5 plot and then
>> accompany it with the javascript code to trace the function, etc.
>
> Someone has worked on a html5 back-end, It was jsut discussed a bit on
> the thread "Using the Agg renderer by itself"
>
> Here's a cut and paste:
>
> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>   >
>   >  Ben is referring to mplh5canvas, available at
>   >  http://code.google.com/p/mplh5canvas/. The main advantage of this
>   >  approach is interactive zooming of plots within the browser. If this is
>   >  not important to you, it will probably be faster to generate static PNGs
>   >  or SVGs.
>   >
>   >  The HTML5 backend should be easy to try out, as it is a pure Python
>   >  package with no onerous dependencies.
>   >

Michael Droettboom played with this a little at the Sage Days in March, 
IIRC, and I seem to think he also whipped up an interactive demo using 
svg plots.  Michael, do you remember what your conclusions were?

Thanks,

Jason

Re: [matplotlib-devel] jsxgraph or flot backend (or interactive viewer for svg backend?)

[Chris B. <Chr...@no...>]

On 12/5/11 9:49 PM, Jason Grout wrote:
> Has anyone ever worked on a backend that generates javascript code for
> one of the javascript plotters out there (like jsxgraph or flot)?
> Alternatively, I suppose we could generate an svg or html5 plot and then
> accompany it with the javascript code to trace the function, etc.

Someone has worked on a html5 back-end, It was jsut discussed a bit on 
the thread "Using the Agg renderer by itself"

Here's a cut and paste:

On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
 >
 > Ben is referring to mplh5canvas, available at
 > http://code.google.com/p/mplh5canvas/. The main advantage of this
 > approach is interactive zooming of plots within the browser. If this is
 > not important to you, it will probably be faster to generate static PNGs
 > or SVGs.
 >
 > The HTML5 backend should be easy to try out, as it is a pure Python
 > package with no onerous dependencies.
 >

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] v1.1.x branch was (temporarily) wrong

[Benjamin R. <ben...@ou...>]

On Wed, Dec 7, 2011 at 8:56 AM, Michael Droettboom <md...@st...> wrote:

>  On 12/06/2011 10:10 PM, Benjamin Root wrote:
>
>
>
> On Tuesday, December 6, 2011, Michael Droettboom <md...@st...> wrote:
> > Yesterday I managed to accidentally move the v1.1.x branch pointer to
> > point to master.  I have since moved it back, but you may need to rebase
> > if you have any active branches based on the (wrong) v1.1.x branch.  The
> > following should suffice:
> >
> >    git fetch upstream
> >    git rebase upstream/v1.1.x
> >
> > Mike
> >
>
> I am getting a whole bunch of conflict errors.  I wonder if it is because
> I rebased already when v1.1.x was pointed to master?  Are we sure that
> v1.1.x is ok?  If so, I could just delete my copy and refetch it from
> upstream?
>
> It's quite possible to get conflict errors if you rebased on v1.1.x when
> it was the same as master and are now going back.  I'm really sorry for the
> inconvenience this mistake caused.
>
> But it should be possible to reapply your new commits on top of v1.1.x
> without too much trouble.  Feel free to contact me off list and maybe we
> can get to the bottom of what's going on for you.
>
> Cheers,
> Mike
>

As a note, it appears that doing "git rebase upstream/v1.1.x -s ours"
produces the correct result.  Although, I think it might have set my push
remote to point to the matplotlib repo and not my own github repo, but I
might be wrong on that.

Ben Root

Re: [matplotlib-devel] v1.1.x branch was (temporarily) wrong

[Michael D. <md...@st...>]

On 12/06/2011 10:10 PM, Benjamin Root wrote:
>
>
> On Tuesday, December 6, 2011, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
> > Yesterday I managed to accidentally move the v1.1.x branch pointer to
> > point to master.  I have since moved it back, but you may need to rebase
> > if you have any active branches based on the (wrong) v1.1.x branch.  The
> > following should suffice:
> >
> >    git fetch upstream
> >    git rebase upstream/v1.1.x
> >
> > Mike
> >
>
> I am getting a whole bunch of conflict errors.  I wonder if it is 
> because I rebased already when v1.1.x was pointed to master?  Are we 
> sure that v1.1.x is ok?  If so, I could just delete my copy and 
> refetch it from upstream?
It's quite possible to get conflict errors if you rebased on v1.1.x when 
it was the same as master and are now going back.  I'm really sorry for 
the inconvenience this mistake caused.

But it should be possible to reapply your new commits on top of v1.1.x 
without too much trouble.  Feel free to contact me off list and maybe we 
can get to the bottom of what's going on for you.

Cheers,
Mike

Re: [matplotlib-devel] v1.1.x branch was (temporarily) wrong

[Benjamin R. <ben...@ou...>]

On Tuesday, December 6, 2011, Michael Droettboom <md...@st...> wrote:
> Yesterday I managed to accidentally move the v1.1.x branch pointer to
> point to master.  I have since moved it back, but you may need to rebase
> if you have any active branches based on the (wrong) v1.1.x branch.  The
> following should suffice:
>
>    git fetch upstream
>    git rebase upstream/v1.1.x
>
> Mike
>

I am getting a whole bunch of conflict errors.  I wonder if it is because I
rebased already when v1.1.x was pointed to master?  Are we sure that v1.1.x
is ok?  If so, I could just delete my copy and refetch it from upstream?

Ben Root

[matplotlib-devel] bad link on matplotlib website

[Jim H. <lan...@gm...>]

I'm not sure if this is the right place to report this, but the link
to Python(x, y) on
http://matplotlib.sourceforge.net/users/installing.html points to a
page that no longer exists.

--
Jim Hunziker

[matplotlib-devel] v1.1.x branch was (temporarily) wrong

[Michael D. <md...@st...>]

Yesterday I managed to accidentally move the v1.1.x branch pointer to 
point to master.  I have since moved it back, but you may need to rebase 
if you have any active branches based on the (wrong) v1.1.x branch.  The 
following should suffice:

    git fetch upstream
    git rebase upstream/v1.1.x

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

[matplotlib-devel] jsxgraph or flot backend (or interactive viewer for svg backend?)

[Jason G. <jas...@cr...>]

Dan Drake on the Sage mailing list pointed out that google now has the 
ability to plot graphs:

https://www.google.com/search?q=sin(x)%2C+cos(x)

A nice javascript thing is generated and has automatic tracing, zooming, 
and panning turned on.  Of course, those are things we'd all love in the 
Sage project for our matplotlib-based graphics :).

Has anyone ever worked on a backend that generates javascript code for 
one of the javascript plotters out there (like jsxgraph or flot)? 
Alternatively, I suppose we could generate an svg or html5 plot and then 
accompany it with the javascript code to trace the function, etc.  Has 
anyone experimented with writing a javascript "viewer" for graphics, 
having some of the same features that the standard graphics window that 
pops up under qt, wx, gtk, etc.?

I think this would be interesting to work on next summer if I have extra 
time.

Thanks,

Jason

[matplotlib-devel] Bug in transform argument for some collections?

[Tony Yu <ts...@gm...>]

There seems to be a bug in the "transform" argument for CircleCollection,
EllipseCollection, and RegularPolyCollection. These classes override any
transform passed on instantiation and uses the IdentityTransform instead.

Take, for example, the init method CircleCollection:

#~~~
    def __init__(self, sizes, **kwargs):
        """
        *sizes*
            Gives the area of the circle in points^2

        %(Collection)s
        """
        Collection.__init__(self,**kwargs)
        self._sizes = sizes
        self.set_transform(transforms.IdentityTransform())
        self._paths = [mpath.Path.unit_circle()]
#~~~

If "transform" is passed as a kwarg, it gets updated by the call to
``Collection.__init__`` (this update is done in Artist, which is a parent
class of Collection). But a couple lines after that, the transform is
manually reset to the IdentityTransform. Is this a bug?

As it stands, setting the transform kwarg does nothing (and doesn't
complain), so I have to call the set_transform method after creating the
collection (not a big deal, but it's confusing that the first option
doesn't work).

A couple of notes:
* Artist already defaults to setting Artist._transform (and hence
Collection._transform) to the IdentityTransform.
* Nevertheless, the set_transform line above is *not* a do-nothing line:
not only does set_transform set the _transform attribute, it also sets the
_transformSet attribute.

A few solutions:
* Replace the set_transform line with ``self._transformSet = True``.
(preserves current behavior, without overriding a user-prescribed transform)
* Replace transform passed to self.set_transform with self.get_transform.
(same behavior as above.)
* Just remove the set_transform line. This changes the behavior since
self._transformSet is left False, but I'm not sure what the correct
behavior is.

-Tony

[matplotlib-devel] Who's packaging mpl for ubuntu? The package is doing something quite nasty on Oneiric..

[Fernando P. <fpe...@gm...>]

Howdy,

do we have the ubuntu packaging team on this list, or any way to contact them?

Today Stefan and I burned a few hours tracking this bug down, again,
which I'd already debugged a couple of months ago and totally
forgotten about:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176

It would be great if anyone here has any contacts with the ubuntu mpl
team and this could get fixed.  On launchpad there's been zero
response, so I'm trying this way now...

Cheers,

f

Re: [matplotlib-devel] Using the Agg renderer by itself

[Ludwig S. <lud...@gm...>]

Hi Chris and others,


On 11/23/11 12:39 PM, Chris Barker wrote:
> On 11/23/11 10:38 AM, Benjamin Root wrote:

> 
> 

> > There is an HTML5 backend, supposedly. Don't know how well documented it is, though.
> > 
> 



> Hmm -- coll idea -- I'll look into that at some point. However, as I
> don't need the MPL machinerey, but just the renderer, I'm not sure it
> would buy me much.
> 
> And I'm not sure I can:
> 
> a) count on html 5 on all browsers we need to support
> 
> or
> 
> b) get the drawing performance I want if I have to push all the data to
> the client to draw.
> 
> But something to keep an eye on, thanks.


Ben is referring to mplh5canvas, available at http://code.google.com/p/mplh5canvas/. The main advantage of this approach is interactive zooming of plots within the browser. If this is not important to you, it will probably be faster to generate static PNGs or SVGs.

The HTML5 backend should be easy to try out, as it is a pure Python package with no onerous dependencies.

I'll try to address your concerns mentioned above:

a) The Canvas element is quite well supported in modern browsers, but the WebSocket component (used to communicate between the matplotlib backend "server" code in Python and the "client" code on the browser in JavaScript) is a bit trickier to support.

b) Here the matplotlib machinery actually helps, by reducing the primitives to draw via path simplification before sending them to the client browser.

We have also used flot (http://code.google.com/p/flot/) for simple time-series plots without matplotlib. I'm not sure how well it performs on large data sets, though.

Regards,
Ludwig

Re: [matplotlib-devel] mplot3d "set_zlim" x "set_zlim3d" ?

[Benjamin R. <ben...@ou...>]

On Sunday, November 27, 2011, Roberto Colistete Jr. <
rob...@gm...> wrote:
>     Hi,
>
>     In MatPlotLib 1.0.0 the example 'mplot3d/surface3d_demo.py' has the
> line :
> ax.set_zlim3d(-1.01, 1.01)
> while the same file in MatPlotLib 1.1.0 has :
> ax.set_zlim(-1.01, 1.01)
>
>     If I try to use ax.set_zlim(-1.01, 1.01) with MatPlotLib 1.0.0 I get :
> "$ python surface3d_demo.py
> Traceback (most recent call last):
>   File "surface3d_demo.py", line 16, in <module>
>     ax.set_zlim(-1.01, 1.01)
> AttributeError: 'Axes3DSubplot' object has no attribute 'set_zlim'"
>
>    So what is the recommended way for maximum compatibility
> (1.0.0/1.1.0) ? Use 'set_zlim' or 'set_zlim3d ?
>
>         Thanks in advance,
>
>         Roberto
>

What is recommended is to upgrade to v1.1.0 where the behavior is much more
intuitive and follows expected conventions. If that is not possible, then
use set_*lim3d().

Ben Root

[matplotlib-devel] mplot3d "set_zlim" x "set_zlim3d" ?

[Roberto C. Jr. <rob...@gm...>]

     Hi,

     In MatPlotLib 1.0.0 the example 'mplot3d/surface3d_demo.py' has the 
line :
ax.set_zlim3d(-1.01, 1.01)
while the same file in MatPlotLib 1.1.0 has :
ax.set_zlim(-1.01, 1.01)

     If I try to use ax.set_zlim(-1.01, 1.01) with MatPlotLib 1.0.0 I get :
"$ python surface3d_demo.py
Traceback (most recent call last):
   File "surface3d_demo.py", line 16, in <module>
     ax.set_zlim(-1.01, 1.01)
AttributeError: 'Axes3DSubplot' object has no attribute 'set_zlim'"

    So what is the recommended way for maximum compatibility 
(1.0.0/1.1.0) ? Use 'set_zlim' or 'set_zlim3d ?

         Thanks in advance,

         Roberto

Re: [matplotlib-devel] Using the Agg renderer by itself

[Chris B. <Chr...@no...>]

On 11/23/11 10:13 AM, Friedrich Romstedt wrote:
> 2011/11/23 Chris.Barker<Chr...@no...>:
>> I've got some drawing to do (for a web app). I don't need all the MPL
>> machinery, but I do need a high quality, fast, renderer.
>
> http://www.effbot.org/zone/aggdraw-index.htm

I've been wondering about that -- it doesn't look terribly maintained -- 
no updates for a long time, and I'm concerned about performance 99 if 
you are drawing something simple, but with lot's of points, all that 
conversion from numpy types to python type to C types is going to be an 
issue.

> http://www.effbot.org/imagingbook/imagedraw.htm

this is definitely slow for what I'm doing.

Thanks,
   -Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[matplotlib-devel] MatPlotLib for Mobile OS

[Roberto C. Jr. <rob...@gm...>]

     Hi,

     It is my first post to matplotlib-dev. I am a theoretical physicist 
interested a lot in Python/IPython/SymPy/NumPy/MatPlotLib/etc. Both for 
desktop OS and mobile OS.

     About mobile OS (for smartphones/tablets), MatPlotLib is packaged 
and works well in :

- MeeGo 1.2 Harmattan OS on Nokia N9/N950, released in 2011, with Nokia 
N9 selling since September/October. MatPlotLib 1.0.0 was  released 
yesterday by me (as a maintainer) :
http://forum.meego.com/showthread.php?t=5231
http://talk.maemo.org/showthread.php?p=1128672

- Maemo 5 (Fremantle) OS on Nokia N900, released in 11/2009 and 
currently difficult to buy brand new. Install using "# apt-get install 
python-matplotlib" :
http://maemo.org/packages/view/python-matplotlib/

NumPy, SymPy and IPython are also available for both OS. I have searched 
and found that there is no MatPlotLib for Android OS, iOS and Symbian.

     So it seems that the only smartphone selling today with MatPlotLib 
support is Nokia N9 (MeeGo 1.2 Harmattan OS). The repositories for Nokia 
N9 :
http://harmattan-dev.nokia.com/unstable/beta3/Fremantle_Update7_vs_Harmattan_Beta3_content_comparison.html 

show about 170 Python packages.
     MeeGo Harmattan is also a developer's paradise, with more than 10 
programming languages available now (via "apt-get install" or already 
installed) : gcc/g++ (3.4, 4.2, 4.4), gfortran 4.4, gpc (GNU Pascal 
2.2), Lua 5.1, Perl 5.8, Prolog, Python 2.5/2.6/3.1, Ruby 1.8, TCL 
8.4/8.5, Vala 0.12, etc. Also Qt/C++, Qt/Qt Quick, Qt/Python (PySide).

         Best regards from Brazil,

         Roberto

Re: [matplotlib-devel] Using the Agg renderer by itself

[Chris.Barker <Chr...@no...>]

On 11/23/11 10:38 AM, Benjamin Root wrote:

> On Wednesday, November 23, 2011, Chris.Barker <Chr...@no...
> <mailto:Chr...@no...>> wrote:
>  > Hi Folks,
>  >
>  > I've got some drawing to do (for a web app). I don't need all the MPL
>  > machinery, but I do need a high quality, fast, renderer.

> There is an HTML5 backend, supposedly.  Don't know how well documented
> it is, though.

Hmm -- coll idea -- I'll look into that at some point. However, as I 
don't need the MPL machinerey, but just the renderer, I'm not sure it 
would buy me much.

And I'm not sure I can:

a) count on html 5 on all browsers we need to support

or

b) get the drawing performance I want if I have to push all the data to 
the client to draw.

But something to keep an eye on, thanks.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] Using the Agg renderer by itself

[Benjamin R. <ben...@ou...>]

On Wednesday, November 23, 2011, Chris.Barker <Chr...@no...> wrote:
> Hi Folks,
>
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.
>
> Other options:
>
>  - The python bindings to GD seem to not really being maintained
>
>  - PyCairo is a pain to install, and not fast for Python (doesn't know
> about numpy arrays of points, for instance)
>
>  - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick
> to install (at least without EPD or PythonXY or something)
>
>
> So I thought I'd give MPL's AGG wrappers a try. I've managed to get
> things working, but I do have a couple questions:
>
> 1) are there docs somewhere? What I've found is very sparse, and doc
> strings are minimal -- though I've got the source, so only so much or a
> complaint.
>
> 2) It looks like the AGG renderers take floats for almost everything --
> makes sense, with anti-aliasing and sub-pixel rendering. But is it
> float32 or float64 internally? It seems either will work, but I'm going
> for maximum performance, so I'd like to use the native format.
>
>
> Testing drawing a polygon, I'm a bit confused about GraphicsContext vs
> the renderer. If I do:
>
> gc = GraphicsContextBase()
> transform = Affine2D() # default unit transform
>
> ## draw the polygon:
> ## create a path for a polygon:
> points =
np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)
>
> p = Path(points)
>
> gc.set_linewidth(4)
> gc.set_alpha(0.75)
>
> fill_color = (0.0, 1.0, 0.0)
> line_color = (1.0, 0.0, 0.0)
>
> #gc._rgb = line_color
> gc.set_foreground(line_color)
>
> Canvas.draw_path(gc, p, transform, fill_color)
>
> I get a green polygon with a red border, like I'd expect. However:
>
> Why is the outline color set in the GraphicsContext, but the fill color
> passed in to the draw_path call? Or am I doing that wrong?
>
>
> Thanks for input,
>
> -Chris
>
>

There is an HTML5 backend, supposedly.  Don't know how well documented it
is, though.

Ben Root

Re: [matplotlib-devel] Using the Agg renderer by itself

[Friedrich R. <fri...@gm...>]

2011/11/23 Chris.Barker <Chr...@no...>:
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.

http://www.effbot.org/zone/aggdraw-index.htm

http://www.effbot.org/imagingbook/imagedraw.htm

Don't know if this suffices your needs.

Friedrich

Re: [matplotlib-devel] Using the Agg renderer by itself

[Chris.Barker <Chr...@no...>]

On 11/23/11 9:52 AM, Chris.Barker wrote:
> I've got some drawing to do (for a web app). I don't need all the MPL
> machinery, but I do need a high quality, fast, renderer.

One more question. I see:

     def draw_markers(self, *kl, **kw):
         # for filtering to work with rastrization, methods needs to be 
wrapped.
         # maybe there is better way to do it.
         return self._renderer.draw_markers(*kl, **kw)

What do I pass in to this function?

Thanks,
   -Chris




> Other options:
>
>    - The python bindings to GD seem to not really being maintained
>
>    - PyCairo is a pain to install, and not fast for Python (doesn't know
> about numpy arrays of points, for instance)
>
>    - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick
> to install (at least without EPD or PythonXY or something)
>
>
> So I thought I'd give MPL's AGG wrappers a try. I've managed to get
> things working, but I do have a couple questions:
>
> 1) are there docs somewhere? What I've found is very sparse, and doc
> strings are minimal -- though I've got the source, so only so much or a
> complaint.
>
> 2) It looks like the AGG renderers take floats for almost everything --
> makes sense, with anti-aliasing and sub-pixel rendering. But is it
> float32 or float64 internally? It seems either will work, but I'm going
> for maximum performance, so I'd like to use the native format.
>
>
> Testing drawing a polygon, I'm a bit confused about GraphicsContext vs
> the renderer. If I do:
>
> gc = GraphicsContextBase()
> transform = Affine2D() # default unit transform
>
> ## draw the polygon:
> ## create a path for a polygon:
> points = np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)
>
> p = Path(points)
>
> gc.set_linewidth(4)
> gc.set_alpha(0.75)
>
> fill_color = (0.0, 1.0, 0.0)
> line_color = (1.0, 0.0, 0.0)
>
> #gc._rgb = line_color
> gc.set_foreground(line_color)
>
> Canvas.draw_path(gc, p, transform, fill_color)
>
> I get a green polygon with a red border, like I'd expect. However:
>
> Why is the outline color set in the GraphicsContext, but the fill color
> passed in to the draw_path call? Or am I doing that wrong?
>
>
> Thanks for input,
>
> -Chris
>
>
>
>
>
>
>
>
>
>
>
>
>


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

[matplotlib-devel] Using the Agg renderer by itself

[Chris.Barker <Chr...@no...>]

Hi Folks,

I've got some drawing to do (for a web app). I don't need all the MPL 
machinery, but I do need a high quality, fast, renderer.

Other options:

  - The python bindings to GD seem to not really being maintained

  - PyCairo is a pain to install, and not fast for Python (doesn't know 
about numpy arrays of points, for instance)

  - Kiva appears to be quite enmeshed with ETS, and thus a bit of trick 
to install (at least without EPD or PythonXY or something)


So I thought I'd give MPL's AGG wrappers a try. I've managed to get 
things working, but I do have a couple questions:

1) are there docs somewhere? What I've found is very sparse, and doc 
strings are minimal -- though I've got the source, so only so much or a 
complaint.

2) It looks like the AGG renderers take floats for almost everything -- 
makes sense, with anti-aliasing and sub-pixel rendering. But is it 
float32 or float64 internally? It seems either will work, but I'm going 
for maximum performance, so I'd like to use the native format.


Testing drawing a polygon, I'm a bit confused about GraphicsContext vs 
the renderer. If I do:

gc = GraphicsContextBase()
transform = Affine2D() # default unit transform

## draw the polygon:
## create a path for a polygon:
points = np.array(((10,10),(10,190),(150,100),(290,10),(10,10)),np.float64)

p = Path(points)

gc.set_linewidth(4)
gc.set_alpha(0.75)

fill_color = (0.0, 1.0, 0.0)
line_color = (1.0, 0.0, 0.0)

#gc._rgb = line_color
gc.set_foreground(line_color)

Canvas.draw_path(gc, p, transform, fill_color)

I get a green polygon with a red border, like I'd expect. However:

Why is the outline color set in the GraphicsContext, but the fill color 
passed in to the draw_path call? Or am I doing that wrong?


Thanks for input,

-Chris













-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] nxutils

[Michael D. <md...@st...>]

I'm sorry this fell through the cracks.  It was removed from the build 
because it does not currently build on Python 3.x, and then when I saw 
the functionality was redundant, I think it necessary to invest effort 
porting it.  None of the test suite uses this code.  The source should 
have been removed at the same time, as well as updating the mlab usage.  
You'll see I did add a "TODO" above it that should have been addressed 
before merging into master.

This shows a hole in the test coverage -- we should add a test that uses 
mlab.inside_poly as part of fixing this.

Mike

On 11/18/2011 10:48 AM, James Evans wrote:
>
> I was just shocked to find the source code still present, just not 
> compiled during the build step and at least one completely broken 
> function call still referencing the un-built module and no apparent 
> reason for removal.
>
> I have updated mlab.inside_poly to use Path instead and will submit it 
> later today.
>
> --James
>
> *From:*Michael Droettboom [mailto:md...@st...]
> *Sent:* Friday, November 18, 2011 6:23 AM
> *To:* mat...@li...
> *Subject:* Re: [matplotlib-devel] nxutils
>
> Perhaps another alternative is to just include a small compatibility 
> module that would call the new functionality under the hood.
>
> Mike
>
> On 11/18/2011 09:07 AM, Michael Droettboom wrote:
>
> nxutils has been removed from master because it is completely 
> redundant to the Path functionality that has been in matplotlib since 
> 0.98.  In the process of porting to Python 3, I felt it was important 
> to reduce code duplication, because every additional line requires 
> additional testing.
>
> That said, there seems to be a lot of push back on this.  We can 
> reinstate it, but I would suggest raising DeprecationWarnings for one 
> release and then removing it entirely in the next.
>
> Mike
>
> On 11/18/2011 12:21 AM, Benjamin Root wrote:
>
> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
> And, if I remember right, Path uses that to calculate contains().
>
> Ben Root
>
> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> >> Most of what was in nxutils has been superseded by things in Numpy, and
> >> it makes more sense for it to be over there.
> >>
> >> In the case of points_inside_poly, you can use the Path object in
> >> path.py and the "contains_point" method.
> >>
> >> Mike
> >
> > Mike,
> >
> > This, however, brings us back to the plea by Volker Blum:
> >
> > 
> http://www.mail-archive.com/mat...@li.../msg22669.html
> >
> > There is a real tension between the need to clean things up and simplify
> > them, and users' desire for minimal loss of backwards compatibility.
> > Personally, my instincts are in the "clean it up" camp, but a good
> > balance has to be found.
> >
> > nxutils was definitely a vestige of an earlier era; but I don't think it
> > went through any official, publicized, deprecation process, did it?
> > Maybe it didn't need to; I don't know.  Perhaps we need to formulate and
> > write down a deprecation policy.
> >
> > Eric
> >
> >>
> >> On 11/17/2011 12:03 PM, James Evans wrote:
> >>>
> >>> All,
> >>>
> >>> I have not touched the code for several months, so it has taken me up
> >>> until just now to realize that nxutils has been removed from the 
> build.
> >>>
> >>> I there any real reason for this? Particularly when you consider that
> >>> there are still functions present that use it and now they just fail.
> >>>
> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
> >>> using 'nxutils.points_inside_poly' directly, but the end result is the
> >>> same.
> >>>
> >>> Thanks,
> >>>
> >>> --James Evans
> >>>
> >>>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> All the data continuously generated in your IT infrastructure
> >>> contains a definitive record of customers, application performance,
> >>> security threats, fraudulent activity, and more. Splunk takes this
> >>> data and makes sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-novd2d
> >>>
> >>>
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-novd2d
> >>
> >>
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> > 
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li... 
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...  <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...  <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Subject: Re: Another colormap

[Pim S. <P.S...@as...>]

Dear Tony,

I tried the example with several colormaps (have you checked out
cubehelix which nicely resembles the grey scale visual intensity
distribution in color) and I definitely agree that it would be good
for matplotlib to switch to a more sensible default color map. My
personal vote goes to coolwarm which has well defined behaviour and is
suitable (e.g. looks nice) for a wide range of applications.

Kind regards,

Pim Schellart

P.S. Although cubehelix also has well defined behaviour it is less
optimal as a default since it does not look nice in all use cases (but
is very good in some, particularly for cases where the percieved
intensity distribution needs to be the same when viewed on screen and
printed in black and white).

Re: [matplotlib-devel] nxutils

[James E. <jre...@ea...>]

I was just shocked to find the source code still present, just not compiled
during the build step and at least one completely broken function call still
referencing the un-built module and no apparent reason for removal. 

 

I have updated mlab.inside_poly to use Path instead and will submit it later
today.

 

--James

 

 

From: Michael Droettboom [mailto:md...@st...] 
Sent: Friday, November 18, 2011 6:23 AM
To: mat...@li...
Subject: Re: [matplotlib-devel] nxutils

 

Perhaps another alternative is to just include a small compatibility module
that would call the new functionality under the hood.

Mike

On 11/18/2011 09:07 AM, Michael Droettboom wrote: 

nxutils has been removed from master because it is completely redundant to
the Path functionality that has been in matplotlib since 0.98.  In the
process of porting to Python 3, I felt it was important to reduce code
duplication, because every additional line requires additional testing.

That said, there seems to be a lot of push back on this.  We can reinstate
it, but I would suggest raising DeprecationWarnings for one release and then
removing it entirely in the next.

Mike

On 11/18/2011 12:21 AM, Benjamin Root wrote: 

Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if
I remember right, Path uses that to calculate contains().

Ben Root

On Thursday, November 17, 2011, Eric Firing <ef...@ha...> wrote:
> On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> Most of what was in nxutils has been superseded by things in Numpy, and
>> it makes more sense for it to be over there.
>>
>> In the case of points_inside_poly, you can use the Path object in
>> path.py and the "contains_point" method.
>>
>> Mike
>
> Mike,
>
> This, however, brings us back to the plea by Volker Blum:
>
>
http://www.mail-archive.com/mat...@li.../msg22669.
html
>
> There is a real tension between the need to clean things up and simplify
> them, and users' desire for minimal loss of backwards compatibility.
> Personally, my instincts are in the "clean it up" camp, but a good
> balance has to be found.
>
> nxutils was definitely a vestige of an earlier era; but I don't think it
> went through any official, publicized, deprecation process, did it?
> Maybe it didn't need to; I don't know.  Perhaps we need to formulate and
> write down a deprecation policy.
>
> Eric
>
>>
>> On 11/17/2011 12:03 PM, James Evans wrote:
>>>
>>> All,
>>>
>>> I have not touched the code for several months, so it has taken me up
>>> until just now to realize that nxutils has been removed from the build.
>>>
>>> I there any real reason for this? Particularly when you consider that
>>> there are still functions present that use it and now they just fail.
>>>
>>> In particular I am referring to 'mlab.inside_poly'. In my case I was
>>> using 'nxutils.points_inside_poly' directly, but the end result is the
>>> same.
>>>
>>> Thanks,
>>>
>>> --James Evans
>>>
>>>
>>>
>>>
----------------------------------------------------------------------------
--
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>>
----------------------------------------------------------------------------
--
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
----------------------------------------------------------------------------
--
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 




----------------------------------------------------------------------------
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d






_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel







----------------------------------------------------------------------------
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d






_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

 

Re: [matplotlib-devel] nxutils

[Michael D. <md...@st...>]

Perhaps another alternative is to just include a small compatibility 
module that would call the new functionality under the hood.

Mike

On 11/18/2011 09:07 AM, Michael Droettboom wrote:
> nxutils has been removed from master because it is completely 
> redundant to the Path functionality that has been in matplotlib since 
> 0.98.  In the process of porting to Python 3, I felt it was important 
> to reduce code duplication, because every additional line requires 
> additional testing.
>
> That said, there seems to be a lot of push back on this.  We can 
> reinstate it, but I would suggest raising DeprecationWarnings for one 
> release and then removing it entirely in the next.
>
> Mike
>
> On 11/18/2011 12:21 AM, Benjamin Root wrote:
>> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
>> And, if I remember right, Path uses that to calculate contains().
>>
>> Ben Root
>>
>> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
>> <mailto:ef...@ha...>> wrote:
>> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
>> >> Most of what was in nxutils has been superseded by things in 
>> Numpy, and
>> >> it makes more sense for it to be over there.
>> >>
>> >> In the case of points_inside_poly, you can use the Path object in
>> >> path.py and the "contains_point" method.
>> >>
>> >> Mike
>> >
>> > Mike,
>> >
>> > This, however, brings us back to the plea by Volker Blum:
>> >
>> > 
>> http://www.mail-archive.com/mat...@li.../msg22669.html
>> >
>> > There is a real tension between the need to clean things up and 
>> simplify
>> > them, and users' desire for minimal loss of backwards compatibility.
>> > Personally, my instincts are in the "clean it up" camp, but a good
>> > balance has to be found.
>> >
>> > nxutils was definitely a vestige of an earlier era; but I don't 
>> think it
>> > went through any official, publicized, deprecation process, did it?
>> > Maybe it didn't need to; I don't know.  Perhaps we need to 
>> formulate and
>> > write down a deprecation policy.
>> >
>> > Eric
>> >
>> >>
>> >> On 11/17/2011 12:03 PM, James Evans wrote:
>> >>>
>> >>> All,
>> >>>
>> >>> I have not touched the code for several months, so it has taken me up
>> >>> until just now to realize that nxutils has been removed from the 
>> build.
>> >>>
>> >>> I there any real reason for this? Particularly when you consider that
>> >>> there are still functions present that use it and now they just fail.
>> >>>
>> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
>> >>> using 'nxutils.points_inside_poly' directly, but the end result 
>> is the
>> >>> same.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> --James Evans
>> >>>
>> >>>
>> >>>
>> >>> 
>> ------------------------------------------------------------------------------
>> >>> All the data continuously generated in your IT infrastructure
>> >>> contains a definitive record of customers, application performance,
>> >>> security threats, fraudulent activity, and more. Splunk takes this
>> >>> data and makes sense of it. IT sense. And common sense.
>> >>> http://p.sf.net/sfu/splunk-novd2d
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Matplotlib-devel mailing list
>> >>> Mat...@li... 
>> <mailto:Mat...@li...>
>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >>
>> >>
>> >> 
>> ------------------------------------------------------------------------------
>> >> All the data continuously generated in your IT infrastructure
>> >> contains a definitive record of customers, application performance,
>> >> security threats, fraudulent activity, and more. Splunk takes this
>> >> data and makes sense of it. IT sense. And common sense.
>> >> http://p.sf.net/sfu/splunk-novd2d
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li... 
>> <mailto:Mat...@li...>
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> >
>> > 
>> ------------------------------------------------------------------------------
>> > All the data continuously generated in your IT infrastructure
>> > contains a definitive record of customers, application performance,
>> > security threats, fraudulent activity, and more. Splunk takes this
>> > data and makes sense of it. IT sense. And common sense.
>> > http://p.sf.net/sfu/splunk-novd2d
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li... 
>> <mailto:Mat...@li...>
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] nxutils

[Michael D. <md...@st...>]

nxutils has been removed from master because it is completely redundant 
to the Path functionality that has been in matplotlib since 0.98.  In 
the process of porting to Python 3, I felt it was important to reduce 
code duplication, because every additional line requires additional testing.

That said, there seems to be a lot of push back on this.  We can 
reinstate it, but I would suggest raising DeprecationWarnings for one 
release and then removing it entirely in the next.

Mike

On 11/18/2011 12:21 AM, Benjamin Root wrote:
> Huh? Nxutils removed? Then how am I still using points_inside_poly? 
> And, if I remember right, Path uses that to calculate contains().
>
> Ben Root
>
> On Thursday, November 17, 2011, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> > On 11/17/2011 10:19 AM, Michael Droettboom wrote:
> >> Most of what was in nxutils has been superseded by things in Numpy, and
> >> it makes more sense for it to be over there.
> >>
> >> In the case of points_inside_poly, you can use the Path object in
> >> path.py and the "contains_point" method.
> >>
> >> Mike
> >
> > Mike,
> >
> > This, however, brings us back to the plea by Volker Blum:
> >
> > 
> http://www.mail-archive.com/mat...@li.../msg22669.html
> >
> > There is a real tension between the need to clean things up and simplify
> > them, and users' desire for minimal loss of backwards compatibility.
> > Personally, my instincts are in the "clean it up" camp, but a good
> > balance has to be found.
> >
> > nxutils was definitely a vestige of an earlier era; but I don't think it
> > went through any official, publicized, deprecation process, did it?
> > Maybe it didn't need to; I don't know.  Perhaps we need to formulate and
> > write down a deprecation policy.
> >
> > Eric
> >
> >>
> >> On 11/17/2011 12:03 PM, James Evans wrote:
> >>>
> >>> All,
> >>>
> >>> I have not touched the code for several months, so it has taken me up
> >>> until just now to realize that nxutils has been removed from the 
> build.
> >>>
> >>> I there any real reason for this? Particularly when you consider that
> >>> there are still functions present that use it and now they just fail.
> >>>
> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was
> >>> using 'nxutils.points_inside_poly' directly, but the end result is the
> >>> same.
> >>>
> >>> Thanks,
> >>>
> >>> --James Evans
> >>>
> >>>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> All the data continuously generated in your IT infrastructure
> >>> contains a definitive record of customers, application performance,
> >>> security threats, fraudulent activity, and more. Splunk takes this
> >>> data and makes sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-novd2d
> >>>
> >>>
> >>> _______________________________________________
> >>> Matplotlib-devel mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-novd2d
> >>
> >>
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> > 
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure
> > contains a definitive record of customers, application performance,
> > security threats, fraudulent activity, and more. Splunk takes this
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li... 
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel