matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

Well, looks like we better get moving then ;-).  I have some time today to
do this (sorry for dropping out last week).  The only PR I see that perhaps
should go in is https://github.com/matplotlib/matplotlib/pull/961


Anything I'm missing?  I'm going to start testing this for the final
release and will put something out later today Sandro.


On Thu, Jun 21, 2012 at 1:01 PM, Sandro Tosi <mo...@de...> wrote:

> Hi all,
>
> On Sat, Jun 9, 2012 at 11:14 PM, John Hunter <jd...@gm...> wrote:
> > I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
>
> Is there a timeline for the final release? The Debian freeze is
> announced for June 30th.
>
> Cheers,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

Re: [matplotlib-devel] Fwd: Patch for errorbar, alpha kw did not apply to lines and cap markers

[Hans D. <han...@ki...>]

Hi!

Thanks for the answer! I think the linestyle and the color settings are 
ok. error bars that are not just lines look very ugly, i would not even 
dare to make dashed or dotted ones. the color of the error bars can be 
set separately with elinecolor while the default is to use the color of 
the markers.

Cheers,
Hans

On 06/22/2012 02:58 PM, Benjamin Root wrote:
>
> On Fri, Jun 22, 2012 at 5:58 AM, Hans Dembinski <han...@ki...
> <mailto:han...@ki...>> wrote:
>
>     Hi again,
>
>     I send this patch to the mailing list two weeks ago and did not get
>     any response. If you reject it, could you please explain why or how
>     I should improve?
>
>     Best regards.
>
>
>
> Our apologies, there aren't that many of us.  I see that you followed
> our documentation for submitting a patch:
>
> http://matplotlib.sourceforge.net/devel/gitwash/patching.html
>
> Looking at your patch, I think it makes sense to do what you did.  I
> only wonder if there are any other properties that should be taken care
> of here?  Color?  Linestyle? etc?
>
> Thoughts?
>
> Cheers!
> Ben Root
>
> Note to self: we need to update the docs to describe how to do Pull
> Requests on GitHub.
>

Re: [matplotlib-devel] Problem with a clipped line containing nan\'s (v1.1.1rc on Ubuntu 12.04)

[Julian T. <jta...@go...>]

Please also report these issues to Ubuntu.
If its significant enough it we can fix this issue in the package. But
we can't fix what we don't know about.

The option of updating the rc to the future final 1.1.1 is also open if
the bug fixed are worth it.

[matplotlib-devel] Strange bug when saving animations (with streamplot)

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

I'm having a tough time figuring this out: Saving an animation seems to
hang when using `streamplot`. The exact same animation runs without issue
when calling show.

On my system, the example below hangs consistently at frame 173. However,
the number of saved frames (before hanging) varies with density of stream
lines (i.e. number of line segments in streamplot): More frames saved for
lower density.

Seems to be a memory or file-size issue, but

   * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
frames to disk as opposed to memory.)
   * Saving the animation up to the frame just before it hangs gives modest
(~1MB) videos.
Maybe this is a limitation of `ffmpeg`?

Can someone confirm that the example hangs on their system? (Somehow, I
often run into bugs that are not reproducible.)

In case this is system dependent:
* OSX 10.6
* Python 2.6.1 (system install)
* matplotlib master
* ffmpeg 0.10

Simple plots seem to work fine, but I should probably try to reproduce
using something other than streamplot (maybe create the equivalent number
of line and arrow collections).

-Tony

#~~~ Example
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation

fig, ax = plt.subplots()

# do nothing function that prints frame
def update(frame_num):
    print frame_num
    return []

Y, X = np.mgrid[:1:100j, :1:100j]
U = np.ones_like(X)
V = np.ones_like(X)
ax.streamplot(X, Y, U, V, density=1)

ani = animation.FuncAnimation(fig, update, save_count=500)

# save hangs at frame 173 (this probably varies by system, if it's
reproducible).
ani.save('animation.avi')
# show animates all frames w/o issue.
#plt.show()

Re: [matplotlib-devel] Fwd: Patch for errorbar, alpha kw did not apply to lines and cap markers

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

On Fri, Jun 22, 2012 at 5:58 AM, Hans Dembinski <han...@ki...>wrote:

> Hi again,
>
> I send this patch to the mailing list two weeks ago and did not get any
> response. If you reject it, could you please explain why or how I should
> improve?
>
> Best regards.
>
>
>
Our apologies, there aren't that many of us.  I see that you followed our
documentation for submitting a patch:

http://matplotlib.sourceforge.net/devel/gitwash/patching.html

Looking at your patch, I think it makes sense to do what you did.  I only
wonder if there are any other properties that should be taken care of
here?  Color?  Linestyle? etc?

Thoughts?

Cheers!
Ben Root

Note to self: we need to update the docs to describe how to do Pull
Requests on GitHub.

[matplotlib-devel] Fwd: Patch for errorbar, alpha kw did not apply to lines and cap markers

[Hans D. <han...@ki...>]

Hi again,

I send this patch to the mailing list two weeks ago and did not get any 
response. If you reject it, could you please explain why or how I should 
improve?

Best regards.

-------- Original Message --------
Subject: Patch for errorbar, alpha kw did not apply to lines and cap markers
Date: Wed, 06 Jun 2012 17:57:31 +0200
From: Hans Dembinski <han...@ki...>
To: mat...@li...

Hi matplotlib developers,

this is my first commit to matplotlib. I am using it heavily in a
scientific context. I followed the How-to and send you an according
patch for what I consider a bug. If it doesn't make sense, please be
lenient with me for now, since it my first time. : )

As described in the subject line, I made the alpha keyword in the
errorbar command act also on the error bars and not only on the markers.
The previous behaviour seemed inconsistent.

Cheers,
Hans

Re: [matplotlib-devel] needed: OS X maintainer

[Russell E. O. <ro...@uw...>]

In article <4FD...@ha...>,
 Eric Firing <ef...@ha...> wrote:

> If you have expertise in python package building on OS X, including more 
> than one method and more than one OS X version, please see 
> https://github.com/matplotlib/matplotlib/issues/168.
> 
> Eric
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

I have commented and include the suggested change to setupext.py. I'm 
strongly in favor.

-- Russell

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

Hi all,

On Sat, Jun 9, 2012 at 11:14 PM, John Hunter <jd...@gm...> wrote:
> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site

Is there a timeline for the final release? The Debian freeze is
announced for June 30th.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[matplotlib-devel] needed: OS X maintainer

[Eric F. <ef...@ha...>]

If you have expertise in python package building on OS X, including more 
than one method and more than one OS X version, please see 
https://github.com/matplotlib/matplotlib/issues/168.

Eric

Re: [matplotlib-devel] Seams in a grid of images

[tcb <the...@gm...>]

On Thu, Jun 14, 2012 at 4:12 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Thu, Jun 14, 2012 at 11:08 AM, tcb <the...@gm...> wrote:
>
>> Hi,
>>
>> I'm trying to plot a grid of images with no spaces in between them and I
>> have problems with the snapping. The grid is computed in data coordinates
>> and the positions of the images are determined by the extents parameter
>>
>> ax.imshow(read_png(filename), extent=extent, snap=True)
>>
>>
>> The images and extents are always the same size and each image starts
>> where the last finished
>>
>> (x0, x0+dx, y0, y0+dy)
>> (x0+dx, x0+2*dx, y0, y0+dy)
>> etc...
>>
>>
>> but it seems something happens in the backend (both QT4 and GTKAgg) and
>> pixel seams are visible between the images at various zoom levels.
>>
>> It seems the ImageGrid was developed to fix this kind of problem, but I'm
>> not sure I can adapt my plot to use ImageGrid. I want to draw stuff over my
>> images and I need to position them in data coordinates.
>>
>> I've tried the snap=True parameter to imshow and it doesn't seem to
>> affect the output.
>>
>> Does anyone have a simple solution to this problem which eliminates the
>> seams?
>>
>> thanks,
>>
>>
>>
> Could you try out the latest version of matplotlib from the master
> branch?  There have been some work in this area in the past few months.  I
> don't know if any of that work went into the recently announced v1.1.1-rc2.
>
> Ben Root
>
>
hi,

I'm using the latest version from git.

Any idea what patches are part of that work? or even which
classes/functions were touched?

thanks,

Re: [matplotlib-devel] Seams in a grid of images

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

On Thu, Jun 14, 2012 at 11:08 AM, tcb <the...@gm...> wrote:

> Hi,
>
> I'm trying to plot a grid of images with no spaces in between them and I
> have problems with the snapping. The grid is computed in data coordinates
> and the positions of the images are determined by the extents parameter
>
> ax.imshow(read_png(filename), extent=extent, snap=True)
>
>
> The images and extents are always the same size and each image starts
> where the last finished
>
> (x0, x0+dx, y0, y0+dy)
> (x0+dx, x0+2*dx, y0, y0+dy)
> etc...
>
>
> but it seems something happens in the backend (both QT4 and GTKAgg) and
> pixel seams are visible between the images at various zoom levels.
>
> It seems the ImageGrid was developed to fix this kind of problem, but I'm
> not sure I can adapt my plot to use ImageGrid. I want to draw stuff over my
> images and I need to position them in data coordinates.
>
> I've tried the snap=True parameter to imshow and it doesn't seem to affect
> the output.
>
> Does anyone have a simple solution to this problem which eliminates the
> seams?
>
> thanks,
>
>
>
Could you try out the latest version of matplotlib from the master branch?
There have been some work in this area in the past few months.  I don't
know if any of that work went into the recently announced v1.1.1-rc2.

Ben Root

[matplotlib-devel] Seams in a grid of images

[tcb <the...@gm...>]

Hi,

I'm trying to plot a grid of images with no spaces in between them and I
have problems with the snapping. The grid is computed in data coordinates
and the positions of the images are determined by the extents parameter

ax.imshow(read_png(filename), extent=extent, snap=True)


The images and extents are always the same size and each image starts where
the last finished

(x0, x0+dx, y0, y0+dy)
(x0+dx, x0+2*dx, y0, y0+dy)
etc...


but it seems something happens in the backend (both QT4 and GTKAgg) and
pixel seams are visible between the images at various zoom levels.

It seems the ImageGrid was developed to fix this kind of problem, but I'm
not sure I can adapt my plot to use ImageGrid. I want to draw stuff over my
images and I need to position them in data coordinates.

I've tried the snap=True parameter to imshow and it doesn't seem to affect
the output.

Does anyone have a simple solution to this problem which eliminates the
seams?

thanks,

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

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

I don't think this has anything to do with matplotlib, but instead just 
with pygobject (or perhaps just gtk itself) on Fedora 17.

I suspect that this fedora bug is responsible:

https://bugzilla.redhat.com/show_bug.cgi?id=790053

Importing gtk is enough to produce this warning:

In [1]: import gtk

** (process:15013): WARNING **: Trying to register gtype 
'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:15013): WARNING **: Trying to register gtype 
'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:15013): WARNING **: Trying to register gtype 
'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'

Mike

On 06/13/2012 05:40 PM, Neal Becker wrote:
> Since installing this on fedora f17 x86_64, I see this warning:
>
> ipython -pylab
> ...
>
> ** (process:26729): WARNING **: Trying to register gtype 'GMountMountFlags' as
> enum when in fact it is of type 'GFlags'
>
> ** (process:26729): WARNING **: Trying to register gtype 'GDriveStartFlags' as
> enum when in fact it is of type 'GFlags'
>
> ** (process:26729): WARNING **: Trying to register gtype 'GSocketMsgFlags' as
> enum when in fact it is of type 'GFlags'
>
> Welcome to pylab, a matplotlib-based Python environment [backend: GTKAgg].
> For more information, type 'help(pylab)'.
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Neal B. <ndb...@gm...>]

Since installing this on fedora f17 x86_64, I see this warning:

ipython -pylab
...

** (process:26729): WARNING **: Trying to register gtype 'GMountMountFlags' as 
enum when in fact it is of type 'GFlags'

** (process:26729): WARNING **: Trying to register gtype 'GDriveStartFlags' as 
enum when in fact it is of type 'GFlags'

** (process:26729): WARNING **: Trying to register gtype 'GSocketMsgFlags' as 
enum when in fact it is of type 'GFlags'

Welcome to pylab, a matplotlib-based Python environment [backend: GTKAgg].
For more information, type 'help(pylab)'.

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Wed, Jun 13, 2012 at 1:03 PM, Michael Droettboom <md...@st...> wrote:
> Is there a slight mix-up in the commits?  In the email John sent out, it had
> commit f763cd11f50437568f8146b822ca8f25647cbb61 at the top of the log
> (alternative baseline image for mathfont_stix_14.png).

The tag is correct, the email log had an extra commit in it that is
not in the rc.  My bad.

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

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

On 06/13/2012 01:29 PM, Benjamin Root wrote:
>
>
> On Mon, Jun 11, 2012 at 2:23 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     On 06/11/2012 02:17 PM, John Hunter wrote:
>     > On Mon, Jun 11, 2012 at 10:30 AM, Michael
>     Droettboom<md...@st... <mailto:md...@st...>>  wrote:
>     >> John: Do you know which git revision you made the tarballs
>     from?  I'll go
>     >> ahead and tag it.
>     >
>     https://github.com/matplotlib/matplotlib/commit/97f713098a71c70d70c46602794c2a0fd126b614
>     Thanks.  Done.
>
>     Here's what it was, if curious:
>
>      >git tag v1.1.1-rc2 97f713098a71c70d70c46602794c2a0fd126b614
>      >git push --tags upstream
>     Total 0 (delta 0), reused 0 (delta 0)
>     To gi...@gi...:matplotlib/matplotlib.git
>      * [new tag]         v1.1.1-rc2 -> v1.1.1-rc2
>
>     Mike
>
>
> Is there a slight mix-up in the commits?  In the email John sent out, 
> it had commit f763cd11f50437568f8146b822ca8f25647cbb61 at the top of 
> the log (alternative baseline image for mathfont_stix_14.png).
>
> Just checking.

Which e-mail is this?  I couldn't figure out what commit the tarball was 
based on which is why I asked John.  If we can confirm the correct 
commit, I'm happy to move the tag.

Mike

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

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

On Mon, Jun 11, 2012 at 2:23 PM, Michael Droettboom <md...@st...> wrote:

> On 06/11/2012 02:17 PM, John Hunter wrote:
> > On Mon, Jun 11, 2012 at 10:30 AM, Michael Droettboom<md...@st...>
>  wrote:
> >> John: Do you know which git revision you made the tarballs from?  I'll
> go
> >> ahead and tag it.
> >
> https://github.com/matplotlib/matplotlib/commit/97f713098a71c70d70c46602794c2a0fd126b614
> Thanks.  Done.
>
> Here's what it was, if curious:
>
>  >git tag v1.1.1-rc2 97f713098a71c70d70c46602794c2a0fd126b614
>  >git push --tags upstream
> Total 0 (delta 0), reused 0 (delta 0)
> To gi...@gi...:matplotlib/matplotlib.git
>  * [new tag]         v1.1.1-rc2 -> v1.1.1-rc2
>
> Mike
>
>
Is there a slight mix-up in the commits?  In the email John sent out, it
had commit f763cd11f50437568f8146b822ca8f25647cbb61 at the top of the log
(alternative baseline image for mathfont_stix_14.png).

Just checking.

Ben Root

Re: [matplotlib-devel] Problem with a clipped line containing nan's (v1.1.1rc on Ubuntu 12.04)

[Alan G. <ala...@gm...>]

On Sun, Jun 10, 2012 at 5:24 AM, Jouni K. Seppänen <jk...@ik...> wrote:
> Alan Griffiths <ala...@gm...> writes:
>
>> I've come across a problem (possibly a bug in cleanup_path) after
>> plotting a line containing nan's and then scaling the axes so that the
>> line is clipped by the axes.
>>
>> Instead of a gap at the position of the nan value, two extra segments
>> appear - back to the start and then onto the next-plus-one valid
>> point.
>
> This sounds a lot like
>
> https://github.com/matplotlib/matplotlib/issues/804
>

Thanks, yes it's fixed in 1.1.1rc2

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

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

On 06/11/2012 02:17 PM, John Hunter wrote:
> On Mon, Jun 11, 2012 at 10:30 AM, Michael Droettboom<md...@st...>  wrote:
>> John: Do you know which git revision you made the tarballs from?  I'll go
>> ahead and tag it.
> https://github.com/matplotlib/matplotlib/commit/97f713098a71c70d70c46602794c2a0fd126b614
Thanks.  Done.

Here's what it was, if curious:

 >git tag v1.1.1-rc2 97f713098a71c70d70c46602794c2a0fd126b614
 >git push --tags upstream
Total 0 (delta 0), reused 0 (delta 0)
To gi...@gi...:matplotlib/matplotlib.git
  * [new tag]         v1.1.1-rc2 -> v1.1.1-rc2

Mike

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Mon, Jun 11, 2012 at 10:30 AM, Michael Droettboom <md...@st...> wrote:
> John: Do you know which git revision you made the tarballs from?  I'll go
> ahead and tag it.

https://github.com/matplotlib/matplotlib/commit/97f713098a71c70d70c46602794c2a0fd126b614

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

On Mon, Jun 11, 2012 at 3:40 PM, RuiDC <ru...@ya...> wrote:
>
> Testing looks good only two known fails for me against the rc2 binaries that
> I spotted on SF on both Windows7 amd64 and Windows XP x86_32 (both Python
> 2.7.3).
>
> The only thing out of the ordinary for me is the following on both:
>
> matplotlib.tests.test_axes.test_markevery_line.test ... ok
> C:\Python27\lib\site-packages\matplotlib\lines.py:461: RuntimeWarning:
> invalid value encountered in greater_equal
>  return np.alltrue(x[1:]-x[0:-1]>=0)
> matplotlib.tests.test_axes.test_nonfinite_limits.test ... ok
>
> I'd seen this on Sandro Tosi's output on this ML, is this a known numpy
> issue? (using the Christoph Gohlke 1.6.2 MKL binaries)

yep: http://mail.scipy.org/pipermail/numpy-discussion/2012-June/062734.html

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

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

John: Do you know which git revision you made the tarballs from?  I'll 
go ahead and tag it.

Mike

On 06/09/2012 09:52 PM, Benjamin Root wrote:
> Don't forget to tag the rc in git!
>
> On Sat, Jun 9, 2012 at 6:40 PM, John Hunter <jd...@gm... 
> <mailto:jd...@gm...>> wrote:
>
>     On Sat, Jun 9, 2012 at 5:33 PM, John Hunter <jd...@gm...
>     <mailto:jd...@gm...>> wrote:
>     > On Sat, Jun 9, 2012 at 5:27 PM, Eric Firing <ef...@ha...
>     <mailto:ef...@ha...>> wrote:
>     >> It also has backend_gdk.c (supposed to be a temporary copy of
>     >> _backend_gdk.c) and some others like it.
>     >
>     > OK, I'll rebuild them super clean...  I know what went wrong.
>
>      Just uploaded two new files built from clean git checkouts.
>
>     ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[RuiDC <ru...@ya...>]

Testing looks good only two known fails for me against the rc2 binaries that
I spotted on SF on both Windows7 amd64 and Windows XP x86_32 (both Python
2.7.3).

The only thing out of the ordinary for me is the following on both:

matplotlib.tests.test_axes.test_markevery_line.test ... ok
C:\Python27\lib\site-packages\matplotlib\lines.py:461: RuntimeWarning:
invalid value encountered in greater_equal
  return np.alltrue(x[1:]-x[0:-1]>=0)
matplotlib.tests.test_axes.test_nonfinite_limits.test ... ok

I'd seen this on Sandro Tosi's output on this ML, is this a known numpy
issue? (using the Christoph Gohlke 1.6.2 MKL binaries)

Thanks,
RuiDC
-- 
View this message in context: http://old.nabble.com/v1.1.1rc2-tarballs-are-up-tp33987325p33993195.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

On Sat, Jun 9, 2012 at 11:14 PM, John Hunter <jd...@gm...> wrote:
> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/

Debian package built and uploaded - thanks!

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

[matplotlib-devel] axes.arrow and FancyArrow documentation and concerns

[Mike K. <mc...@gm...>]

Hi all,

I just sent in a pull request #941 to update the documentation for 
axes.arrow, because width,head_width,head_length, etc weren't 
documented, but I ran into a couple of concerns that I thought to discuss:

1. the default width of 0.001 seems absurdly small. 0.05 seems better. 
You can tell there's actually an arrowhead there with reasonable x- and 
y-limits.

2. I believe that length_includes_head ought to default to True. 
especially since the doc says: Draws arrow on specified axis from (*x*, 
*y*) to (*x* + *dx*, *y* + *dy*), one would expect by default the tip of 
the arrow to end at *x* + *dx*, *y* + *dy*

3. for the 'shape' arg, 'left' and 'right' seem to be backwards to me. 
Given that the arrow defines a vector direction, say \hat{x}, then 
'left' to me means only the part of the arrow in the +y half of the 
plane should be drawn.

M