matplotlib-devel Mailing List for matplotlib

Ugh. It seems I spoke too soon. The illustrious test_bbox_inches_tight 
test is failing again on master.
Mike
On 02/25/2013 05:35 PM, Michael Droettboom wrote:
> I spent the day getting our test suite into shape again so that it's
> passing on Travis.
>
> Just wanted to let you know, in case, like me, you've seen so many false
> positives that you started ignoring Travis.
>
> Mike
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I spent the day getting our test suite into shape again so that it's 
passing on Travis.
Just wanted to let you know, in case, like me, you've seen so many false 
positives that you started ignoring Travis.
Mike

Em 12-02-2013 13:48, Michael Droettboom escreveu:
> Great news!
>
> I've had a soft spot for Maemo (and it's successors) since I got a 
> N770 a few years ago. Loved the Debian package manager, gnome-ish 
> user space, Python bindings for just about everything on the system -- 
> it was everything a Linux geek would want in a tablet.
 Yeah, Maemo 5 OS (from 2009) has about 500 Python packages, while 
MeeGo Harmattan OS (from 2011) has almost 200 Python packages :
http://talk.maemo.org/showthread.php?t=80609
> It's a shame that Nokia left and Android is filling in the space. But 
> perhaps the open source community can carry the torch forward.
 Nokia ceased to sell Nokia N9 in many countries in 2012, but it is 
still available in other countries, sometimes at low price. It is 
estimated that Nokia N9 sold some million units in 2011 and 2012, e.g., 
in 2011/Q4 it sold more (1.5-2 million units) than Nokia Lumia. So there 
is a good MeeGo Harmattan community worldwide, and typical real Linux 
mobile users keep using their devices for some years.
 So I see MeeGo Harmattan OS on Nokia N9/N950 in its best moment, 
mature, with many fantastic projects (Inception, Open Mode Kernek, 
MultiBoot, NITDroid/Android 4.1, Easy Debian, Harmattan SDK on device, 
etc). And it will be easy to port many softwares to Sailfish OS and 
Ubuntu Phone OS, due to common Qt/Qt Quick use.

Great news!
I've had a soft spot for Maemo (and it's successors) since I got a N770 
a few years ago. Loved the Debian package manager, gnome-ish user 
space, Python bindings for just about everything on the system -- it was 
everything a Linux geek would want in a tablet.
It's a shame that Nokia left and Android is filling in the space. But 
perhaps the open source community can carry the torch forward.
Mike
On 02/11/2013 05:23 PM, Roberto Colistete Jr. wrote:
> Hi,
>
> Updating the post below, about MatPlotLib on Mobile OS.
>
> MatPlotLib 1.2.0 was released (in 09/02/2013) for MeeGo Harmattan OS 
> (for Nokia N9/N950). Including Qt4/PySide backend. See the Talk 
> Maemo.org topic :
> http://talk.maemo.org/showthread.php?p=1128672
>
> Also for MeeGo Harmattan OS :
> - NumPy 1.7.0 was released today (11/02/2013), just 1 day after the 
> mainstream release :
> http://talk.maemo.org/showthread.php?p=1322503
> - IPython 0.13.1, including Notebook and Qt console interfaces, was 
> released in 22/01/2013. See the Talk Maemo.org topic :
> http://talk.maemo.org/showthread.php?p=1123672
>
> See also my blog article comparing scientific Python tools for 
> computers, tablets and smartphones :
> http://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Frobertocolistete.wordpress.com%2F2012%2F12%2F26%2Fpython-cientifico-em-computadores-tablets-e-smartphones%2F 
>
>
> The conclusion is very simple : real mobile Linux (with glibc, 
> X11, dependencies, etc) are better for scientific Python. Like Maemo 5 
> OS and MeeGo Harmattan OS. And future Sailfish OS and Ubuntu Phone OS 
> can follow the same path.
>
> Best regards,
>
> Roberto Colistete Jr.
>
>
> -------- Mensagem original --------
> Assunto: 	MatPlotLib for Mobile OS
> Data: 	2011年11月25日 12:33:46 -0200
> De: 	Roberto Colistete Jr. <rob...@gm...>
> Para: 	mat...@li...
>
>
>
> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

 Hi,
 Updating the post below, about MatPlotLib on Mobile OS.
MatPlotLib 1.2.0 was released (in 09/02/2013) for MeeGo Harmattan OS 
(for Nokia N9/N950). Including Qt4/PySide backend. See the Talk 
Maemo.org topic :
http://talk.maemo.org/showthread.php?p=1128672
 Also for MeeGo Harmattan OS :
- NumPy 1.7.0 was released today (11/02/2013), just 1 day after the 
mainstream release :
http://talk.maemo.org/showthread.php?p=1322503
- IPython 0.13.1, including Notebook and Qt console interfaces, was 
released in 22/01/2013. See the Talk Maemo.org topic :
http://talk.maemo.org/showthread.php?p=1123672
 See also my blog article comparing scientific Python tools for 
computers, tablets and smartphones :
http://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Frobertocolistete.wordpress.com%2F2012%2F12%2F26%2Fpython-cientifico-em-computadores-tablets-e-smartphones%2F 
 The conclusion is very simple : real mobile Linux (with glibc, X11, 
dependencies, etc) are better for scientific Python. Like Maemo 5 OS and 
MeeGo Harmattan OS. And future Sailfish OS and Ubuntu Phone OS can 
follow the same path.
 Best regards,
 Roberto Colistete Jr.
-------- Mensagem original --------
Assunto: 	MatPlotLib for Mobile OS
Data: 	2011年11月25日 12:33:46 -0200
De: 	Roberto Colistete Jr. <rob...@gm...>
Para: 	mat...@li...
 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

Hi Tom,
Yes, I would find the version you suggested clearer. I mean now that I 
know how to read it the old version seems quite logical, but if it would 
have been written the way you suggested I would not have made my 
misinterpretation.
Thank you for your help,
Cheers,
Markus
Am 2013年02月09日 14:04, schrieb Thomas Caswell:
> My default interpretation of errors is always relative to the value
> because that is how they are reported (100+10-20 not 100+110-80).
>
> (got your 2nd email while writing this)
>
> Would you find this clearer? Maybe xerr and yerr should be split up
>
> xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
> If a scalar number, len(N) array-like object, or an Nx1 array-like
> object, errorbars are drawn x/y +/- value.
> If a sequence of shape 2xN, errorbars are drawn at x/y - row1 and x/y + row2
>
> Tom
>
> On Sat, Feb 9, 2013 at 12:49 PM, Markus Haider <mar...@ui...> wrote:
>> Hi Tom,
>>
>> Thank you very much for your answer. Indeed this solves my problem. However,
>> I was wondering if the documentation on this is correct.
>> At
>> http://matplotlib.org/api/axes_api.html?highlight=errorbar#matplotlib.axes.Axes.errorbar
>> it says:
>>
>> xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
>> If a scalar number, len(N) array-like object, or an Nx1 array-like object,
>> errorbars are drawn +/- value.
>> If a sequence of shape 2xN, errorbars are drawn at -row1 and +row2
>>
>> This sounds to me that for a 2xN argument it should be drawn from the actual
>> supplied value, or would you interpret this differently?
>>
>> Thanks,
>> Markus
>>
>> Am 2013年02月08日 22:02, schrieb Thomas Caswell:
>>
>>> The bar is drawn from `y - yerr_low` to `y + yerr_upp`
>>>
>>> ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
>>> y]],fmt='s',markersize=4)
>>>
>>> will get you what you want.
>>>
>>> Tom
>>>
>>> On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider <mar...@ui...>
>>> wrote:
>>>> Hi,
>>>>
>>>> I think I have a problem with errorbars in a log plot. The problem is
>>>> reproducible through the enclosed errorbar_log.py file. As you can see I
>>>> plot a point with y = 10**(-5) and I want the errorbars drawn from
>>>> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but
>>>> isn't.
>>>>
>>>> Here is the content of my errorbar_log.py file:
>>>>
>>>> #!/usr/bin/python
>>>> import numpy as np
>>>> import matplotlib.pyplot as plt
>>>>
>>>> fig = plt.figure()
>>>> ax = fig.add_subplot(111)
>>>> x = 0.0
>>>> y = 10**(-5.0)
>>>> yerr_low = 10**(-5.5)
>>>> yerr_upp = 10**(-4.5)
>>>> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
>>>> ax.set_xlim(-1.0,1.0)
>>>> ax.set_ylim(1E-6,1E-3)
>>>> ax.set_yscale('log')
>>>> plt.savefig('errorbar.png')
>>>>
>>>> ---------------------------------------------
>>>>
>>>> 10**(-5.5) = 3.162277660168379e-06
>>>> and 10**(-4.5) = 3.1622776601683795e-05
>>>>
>>>> but you can see that the lower boundary is not at the calculated value.
>>>> <http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png>
>>>>
>>>>
>>>> Do I misunderstand the behaviour of the errorbar function or is this a
>>>> bug?
>>>>
>>>> Cheers,
>>>> Markus
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
>>>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Free Next-Gen Firewall Hardware Offer
>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>> and get the hardware for free! Learn more.
>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>> --
>>> Thomas Caswell
>>> tca...@gm...
>>>
>
>
> --
> Thomas Caswell
> tca...@gm...
>

Greetings,
I came across what I would consider an interesting text bug when using
AnchoredText. In summary, when trying to pass a horizontal alignment to the
text, anything but 'left' doesn't work. The text gets positioned around the
left-edge of the text space (left spine of text box + padding). This occurs
both with the "normal" plotting and the ImageGrid.
I went ahead and filed an issue, but didn't know if someone who doesn't'
check the issues list might have a work around. The git issue has a sample
script and image to illustrate the issue.
https://github.com/matplotlib/matplotlib/issues/1742
I'm not sure if this is a continuation of the issues reported in
Issue #1571 <https://github.com/matplotlib/matplotlib/issues/1571>
Pull Request #1081 <https://github.com/matplotlib/matplotlib/issues/1081>
Pull Request #1589 <https://github.com/matplotlib/matplotlib/issues/1589>
I'm in the midst of my dissertation, so I don't have the time right now to
dig into this. If no one else can, I'll take a crack at it in a couple
months when I'm done.
Cheers,
Patrick
---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
National Severe Storms Laboratory
http://www.patricktmarsh.com

My default interpretation of errors is always relative to the value
because that is how they are reported (100+10-20 not 100+110-80).
(got your 2nd email while writing this)
Would you find this clearer? Maybe xerr and yerr should be split up
xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
If a scalar number, len(N) array-like object, or an Nx1 array-like
object, errorbars are drawn x/y +/- value.
If a sequence of shape 2xN, errorbars are drawn at x/y - row1 and x/y + row2
Tom
On Sat, Feb 9, 2013 at 12:49 PM, Markus Haider <mar...@ui...> wrote:
> Hi Tom,
>
> Thank you very much for your answer. Indeed this solves my problem. However,
> I was wondering if the documentation on this is correct.
> At
> http://matplotlib.org/api/axes_api.html?highlight=errorbar#matplotlib.axes.Axes.errorbar
> it says:
>
> xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
> If a scalar number, len(N) array-like object, or an Nx1 array-like object,
> errorbars are drawn +/- value.
> If a sequence of shape 2xN, errorbars are drawn at -row1 and +row2
>
> This sounds to me that for a 2xN argument it should be drawn from the actual
> supplied value, or would you interpret this differently?
>
> Thanks,
> Markus
>
> Am 2013年02月08日 22:02, schrieb Thomas Caswell:
>
>> The bar is drawn from `y - yerr_low` to `y + yerr_upp`
>>
>> ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
>> y]],fmt='s',markersize=4)
>>
>> will get you what you want.
>>
>> Tom
>>
>> On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider <mar...@ui...>
>> wrote:
>>>
>>> Hi,
>>>
>>> I think I have a problem with errorbars in a log plot. The problem is
>>> reproducible through the enclosed errorbar_log.py file. As you can see I
>>> plot a point with y = 10**(-5) and I want the errorbars drawn from
>>> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but
>>> isn't.
>>>
>>> Here is the content of my errorbar_log.py file:
>>>
>>> #!/usr/bin/python
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>>
>>> fig = plt.figure()
>>> ax = fig.add_subplot(111)
>>> x = 0.0
>>> y = 10**(-5.0)
>>> yerr_low = 10**(-5.5)
>>> yerr_upp = 10**(-4.5)
>>> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
>>> ax.set_xlim(-1.0,1.0)
>>> ax.set_ylim(1E-6,1E-3)
>>> ax.set_yscale('log')
>>> plt.savefig('errorbar.png')
>>>
>>> ---------------------------------------------
>>>
>>> 10**(-5.5) = 3.162277660168379e-06
>>> and 10**(-4.5) = 3.1622776601683795e-05
>>>
>>> but you can see that the lower boundary is not at the calculated value.
>>> <http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png>
>>>
>>>
>>> Do I misunderstand the behaviour of the errorbar function or is this a
>>> bug?
>>>
>>> Cheers,
>>> Markus
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
>>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.
>>> http://p.sf.net/sfu/sophos-d2d-feb
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>>
>
--
Thomas Caswell
tca...@gm...

Actually never mind, I think I just interpreted it wrong. However it 
could perhaps be more clear if it would say something like
If a sequence of shape 2xN, errorbars are drawn at y +/- row1/row2
Thanks,
Markus
Am 2013年02月09日 13:49, schrieb Markus Haider:
> Hi Tom,
>
> Thank you very much for your answer. Indeed this solves my problem.
> However, I was wondering if the documentation on this is correct.
> At
> http://matplotlib.org/api/axes_api.html?highlight=errorbar#matplotlib.axes.Axes.errorbar
> it says:
>
> xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
> If a scalar number, len(N) array-like object, or an Nx1 array-like
> object, errorbars are drawn +/- value.
> If a sequence of shape 2xN, errorbars are drawn at -row1 and +row2
>
> This sounds to me that for a 2xN argument it should be drawn from the
> actual supplied value, or would you interpret this differently?
>
> Thanks,
> Markus
>
> Am 2013年02月08日 22:02, schrieb Thomas Caswell:
>> The bar is drawn from `y - yerr_low` to `y + yerr_upp`
>>
>> ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
>> y]],fmt='s',markersize=4)
>>
>> will get you what you want.
>>
>> Tom
>>
>> On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider <mar...@ui...> wrote:
>>> Hi,
>>>
>>> I think I have a problem with errorbars in a log plot. The problem is
>>> reproducible through the enclosed errorbar_log.py file. As you can see I
>>> plot a point with y = 10**(-5) and I want the errorbars drawn from
>>> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't.
>>>
>>> Here is the content of my errorbar_log.py file:
>>>
>>> #!/usr/bin/python
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>>
>>> fig = plt.figure()
>>> ax = fig.add_subplot(111)
>>> x = 0.0
>>> y = 10**(-5.0)
>>> yerr_low = 10**(-5.5)
>>> yerr_upp = 10**(-4.5)
>>> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
>>> ax.set_xlim(-1.0,1.0)
>>> ax.set_ylim(1E-6,1E-3)
>>> ax.set_yscale('log')
>>> plt.savefig('errorbar.png')
>>>
>>> ---------------------------------------------
>>>
>>> 10**(-5.5) = 3.162277660168379e-06
>>> and 10**(-4.5) = 3.1622776601683795e-05
>>>
>>> but you can see that the lower boundary is not at the calculated value.
>>> <http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png>
>>>
>>>
>>> Do I misunderstand the behaviour of the errorbar function or is this a bug?
>>>
>>> Cheers,
>>> Markus
>>>
>>>
>>>
>>> --
>>> View this message in context: http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
>>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>>
>>> ------------------------------------------------------------------------------
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.
>>> http://p.sf.net/sfu/sophos-d2d-feb
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi Tom,
Thank you very much for your answer. Indeed this solves my problem. 
However, I was wondering if the documentation on this is correct.
At 
http://matplotlib.org/api/axes_api.html?highlight=errorbar#matplotlib.axes.Axes.errorbar 
it says:
xerr/yerr: [ scalar | N, Nx1, or 2xN array-like ]
If a scalar number, len(N) array-like object, or an Nx1 array-like 
object, errorbars are drawn +/- value.
If a sequence of shape 2xN, errorbars are drawn at -row1 and +row2
This sounds to me that for a 2xN argument it should be drawn from the 
actual supplied value, or would you interpret this differently?
Thanks,
Markus
Am 2013年02月08日 22:02, schrieb Thomas Caswell:
> The bar is drawn from `y - yerr_low` to `y + yerr_upp`
>
> ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
> y]],fmt='s',markersize=4)
>
> will get you what you want.
>
> Tom
>
> On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider <mar...@ui...> wrote:
>> Hi,
>>
>> I think I have a problem with errorbars in a log plot. The problem is
>> reproducible through the enclosed errorbar_log.py file. As you can see I
>> plot a point with y = 10**(-5) and I want the errorbars drawn from
>> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't.
>>
>> Here is the content of my errorbar_log.py file:
>>
>> #!/usr/bin/python
>> import numpy as np
>> import matplotlib.pyplot as plt
>>
>> fig = plt.figure()
>> ax = fig.add_subplot(111)
>> x = 0.0
>> y = 10**(-5.0)
>> yerr_low = 10**(-5.5)
>> yerr_upp = 10**(-4.5)
>> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
>> ax.set_xlim(-1.0,1.0)
>> ax.set_ylim(1E-6,1E-3)
>> ax.set_yscale('log')
>> plt.savefig('errorbar.png')
>>
>> ---------------------------------------------
>>
>> 10**(-5.5) = 3.162277660168379e-06
>> and 10**(-4.5) = 3.1622776601683795e-05
>>
>> but you can see that the lower boundary is not at the calculated value.
>> <http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png>
>>
>>
>> Do I misunderstand the behaviour of the errorbar function or is this a bug?
>>
>> Cheers,
>> Markus
>>
>>
>>
>> --
>> View this message in context: http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
>> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>>
>> ------------------------------------------------------------------------------
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> --
> Thomas Caswell
> tca...@gm...
>

On Feb 8, 2013 11:14 PM, "Benjamin Root" <ben...@ou...> wrote:
>
> Just a crazy thought, but why are we trying to treat "title" and such as
properties? When I think of properties for matplotlib, I think of
edgecolors, fontsize, and linestyles. Why don't we solve that problem
first?
In my mind there are several reasons.
First, I personally see things like "title" as properties as well. I can
see why not everyone would, but that would seem to me a reason to keep the
setter functions at least in some cases rather than a reason to not
implement properties.
Second, it is more consistent. Users wouldn't need to remember on a
case-by-basis whether to use a setter or a property.
Third, it would require making sure the API is clan and consistent behind
the scenes. The more complex setters like title would just be wrappers
around the properties or property functions, so there would need to be ways
to access the individual arguments on their own.
That being said, it would be possible to implement properties in stages,
with simpler ones done first and more complex ones done later.
However, there are three reasons I did not include this in my proposed
plan. First, it would mean we lose consistency, perhaps for a few releases.
Second, it could lead to the API breakage being split over several releases
rather than happening all at once. Third, if we do the behind-the-scenes
cleanups first then this isn't an issue to begin with since complexities
will already be dealt with.

The bar is drawn from `y - yerr_low` to `y + yerr_upp`
ax.errorbar(x + .5,y,yerr=[[y - yerr_low],[yerr_upp -
y]],fmt='s',markersize=4)
will get you what you want.
Tom
On Fri, Feb 8, 2013 at 8:41 PM, Markus Haider <mar...@ui...> wrote:
> Hi,
>
> I think I have a problem with errorbars in a log plot. The problem is
> reproducible through the enclosed errorbar_log.py file. As you can see I
> plot a point with y = 10**(-5) and I want the errorbars drawn from
> 10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't.
>
> Here is the content of my errorbar_log.py file:
>
> #!/usr/bin/python
> import numpy as np
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> x = 0.0
> y = 10**(-5.0)
> yerr_low = 10**(-5.5)
> yerr_upp = 10**(-4.5)
> ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4)
> ax.set_xlim(-1.0,1.0)
> ax.set_ylim(1E-6,1E-3)
> ax.set_yscale('log')
> plt.savefig('errorbar.png')
>
> ---------------------------------------------
>
> 10**(-5.5) = 3.162277660168379e-06
> and 10**(-4.5) = 3.1622776601683795e-05
>
> but you can see that the lower boundary is not at the calculated value.
> <http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png>
>
>
> Do I misunderstand the behaviour of the errorbar function or is this a bug?
>
> Cheers,
> Markus
>
>
>
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
> Sent from the matplotlib - devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Thomas Caswell
tca...@gm...

Hi, 
I think I have a problem with errorbars in a log plot. The problem is
reproducible through the enclosed errorbar_log.py file. As you can see I
plot a point with y = 10**(-5) and I want the errorbars drawn from
10**(-5.5) to 10**(-4.5) which should be symmetric in this plot but isn't. 
Here is the content of my errorbar_log.py file: 
#!/usr/bin/python 
import numpy as np 
import matplotlib.pyplot as plt 
fig = plt.figure() 
ax = fig.add_subplot(111) 
x = 0.0 
y = 10**(-5.0) 
yerr_low = 10**(-5.5) 
yerr_upp = 10**(-4.5) 
ax.errorbar(x,y,yerr=[[yerr_low],[yerr_upp]],fmt='o',markersize=4) 
ax.set_xlim(-1.0,1.0) 
ax.set_ylim(1E-6,1E-3) 
ax.set_yscale('log') 
plt.savefig('errorbar.png') 
--------------------------------------------- 
10**(-5.5) = 3.162277660168379e-06 
and 10**(-4.5) = 3.1622776601683795e-05 
but you can see that the lower boundary is not at the calculated value. 
<http://matplotlib.1069221.n5.nabble.com/file/n40412/errorbar.png> 
Do I misunderstand the behaviour of the errorbar function or is this a bug? 
Cheers, 
Markus 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Errorbar-problem-tp40412.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Yes, I realize that this (or the += approach) was overdoing it. Separating
the stuff in two different properties is probably more the way to go (at
least, it's less crazy).
Even the ax.title += (string, options) approach has the problem that this
would imply ax.title (in the sense of ax.__dict__["title"].__get__(ax))
cannot be a string anymore, so this would involve some wrapper object. Ugh.
Antony
2013年2月8日 Todd <tod...@gm...>
> On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee <ant...@be...>wrote:
>
>> Hi,
>>
>> I saw that a discussion started on transitioning to the use of properties
>> instead of explicit getters and setters, which seems like a very good idea
>> to me... so I thought this would be a good idea to get involved in
>> matplotlib-devel :)
>>
>> Right now an issue raised is what to do with set_* that take multiple
>> arguments. Taking set_title, which takes both positional and keyword
>> arguments, as an example, my idea would be to do
>>
>> ax.title = "A title"
>> ax.title.fontdict = fontdict
>>
>> Basically, a property "foo" (in the matplotlib meaning of the word)
>> becomes a descriptor with __get__ => get_foo and __set__ => set_foo, and
>> keyword arguments to the old property setter become themselves descriptors
>> on that descriptor.
>>
>> Antony
>>
>>
> I think this makes it over-complicated. It is much simpler, more
> explicit, and more consistent to have two properties here, one that only
> deals with a string, and a second that only deals with a text object. Then
> you can do something like (where titletext returns the text object):
>
> ax.titletext.fontdict
>
> That way we automatically get what you want without any additional work or
> fancy tricks in a much cleaner, more explicit, and more predictable manner.
>
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Just a crazy thought, but why are we trying to treat "title" and such as
properties? When I think of properties for matplotlib, I think of
edgecolors, fontsize, and linestyles. Why don't we solve that problem
first?
Cheers!
Ben Root

On Fri, Feb 8, 2013 at 2:40 AM, Antony Lee <ant...@be...> wrote:
> Hi,
>
> I saw that a discussion started on transitioning to the use of properties
> instead of explicit getters and setters, which seems like a very good idea
> to me... so I thought this would be a good idea to get involved in
> matplotlib-devel :)
>
> Right now an issue raised is what to do with set_* that take multiple
> arguments. Taking set_title, which takes both positional and keyword
> arguments, as an example, my idea would be to do
>
> ax.title = "A title"
> ax.title.fontdict = fontdict
>
> Basically, a property "foo" (in the matplotlib meaning of the word)
> becomes a descriptor with __get__ => get_foo and __set__ => set_foo, and
> keyword arguments to the old property setter become themselves descriptors
> on that descriptor.
>
> Antony
>
>
I think this makes it over-complicated. It is much simpler, more explicit,
and more consistent to have two properties here, one that only deals with a
string, and a second that only deals with a text object. Then you can do
something like (where titletext returns the text object):
ax.titletext.fontdict
That way we automatically get what you want without any additional work or
fancy tricks in a much cleaner, more explicit, and more predictable manner.

On Fri, Feb 8, 2013 at 3:38 AM, Jason Grout <jas...@cr...>wrote:
> On 2/7/13 8:08 PM, Erik Bray wrote:
> > A couple easier solutions: Allow
> > the `.title` (and other such attributes) to be assigned to with a
> > (value, options) tuple where the value is the title itself, and the
> > options is a dictionary or tuple of supported options for the title.
>
> Interesting. Just brainstorming here...then
>
> ax.title += (None, moreoptions)
>
> could set more options (without changing the title text or already set
> options), or
>
> ax.title -= (None, deleteoptions)
>
> could reset just certain options to default values.
>
> Thanks,
>
> Jason
>
I am not a fan of this approach. It seems to be trying to force a property
to behave like a function when it isn't meant to behave like a function.
In my mind a property is just that, a single aspect of an object. If you
want to change another aspect, you need to change another property. So
these "moreoptions" need to have their own properties, either in the axes
object or, better yet, since they are properties of the title text, have
them as properties of a text object.

On Fri, Feb 8, 2013 at 10:04 AM, Antony Lee <ant...@be...> wrote:
> 2013年2月7日 Erik Bray <eri...@gm...>
>
>> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee <ant...@be...>
>> wrote:
>> > Hi,
>> >
>> > I saw that a discussion started on transitioning to the use of
>> properties
>> > instead of explicit getters and setters, which seems like a very good
>> idea
>> > to me... so I thought this would be a good idea to get involved in
>> > matplotlib-devel :)
>> >
>> > Right now an issue raised is what to do with set_* that take multiple
>> > arguments. Taking set_title, which takes both positional and keyword
>> > arguments, as an example, my idea would be to do
>> >
>> > ax.title = "A title"
>> > ax.title.fontdict = fontdict
>> >
>> > Basically, a property "foo" (in the matplotlib meaning of the word)
>> becomes
>> > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword
>> > arguments to the old property setter become themselves descriptors on
>> that
>> > descriptor.
>>
>> Unfortunately descriptors don't really work like that, because when
>> you do `.title` on an instance that doesn't return the descriptor
>> itself, it just returns the result of `__get__` on the descriptor. So
>> in your example `.fontdict` would have to be an attribute on any
>> string assigned as the title. So what you really have to do for this
>> to work is to wrap every value returned by the descriptor in some kind
>> of proxy that adds the appropriate extra attributes. It also has to
>> do so in a way that the proxy can behave transparently like the
>> wrapped object, and that none of the wrapped objects attributes are
>> overshadowed. And it has to hypothetically work with instances any
>> any arbitrary type or class.
>>
>> While this is somewhat doable for a limited set cases it's really more
>> of a can of worms than it's worth. Believe me, I've tried to solve
>> similar problems to this one before. A couple easier solutions: Allow
>> the `.title` (and other such attributes) to be assigned to with a
>> (value, options) tuple where the value is the title itself, and the
>> options is a dictionary or tuple of supported options for the title.
>> Another solution is to just keep set_title() for cases like this if
>> one wishes to set the title with additional options (while still
>> allowing `.title = 'foo'` for the simple case).
>>
>
> Indeed, good catch. But another issue comes to my mind: should ax1.title
> (that is, "ax1..title.__get__(ax1)" where ".." means no descriptor invoked)
> return a string (like now) or something that contains all the properties of
> the title? Returning a string copies the current behavior of get_title,
> but "ax2.title = ax1.title" would not do what I expect (I would expect
> every property related to the title to be copied). Now, if we want
> "ax2.title = ax1.title" to work as I expect (what do other people think
> here?), then there is no choice but to wrap the return value of __set__.
>
> Antony
>
>
I think you are trying to make this too smart for its own good. I think
things should work in a simple, consistent manner. If the property is set
using a string, then it should return a string. If you assign a string to
something, it should assign a string only. If you want to start copying
other properties, we can use a separate property that accepts and returns a
different object, which I am pretty sure was part of my proposal. This
should be described in the documentation.
So if you want the title fontdict, you get something like
ax1.titletext.fontdict (where titletext is the property for a text object).
Currently ax1.get_title returns a string, so ax2.set_title(ax1.get_title())
will only copy the string. If we want to change the defaults, so that the
title-related methods work with text objects instead of strings, that is
possible (although would be a major backwards-incompatible API break). But
that is a separate discussion from MEP13, which only deals with the
transition to properties. In all cases, under this proposal, I think
properties should be kept as similar as possible to their setters and
getters. API breaks should be a separate issue.

Indeed, good catch. But another issue comes to my mind: should ax1.title
(that is, "ax1..title.__get__(ax1)" where ".." means no descriptor invoked)
return a string (like now) or something that contains all the properties of
the title? Returning a string copies the current behavior of get_title,
but "ax2.title = ax1.title" would not do what I expect (I would expect
every property related to the title to be copied). Now, if we want
"ax2.title = ax1.title" to work as I expect (what do other people think
here?), then there is no choice but to wrap the return value of __set__.
Antony
2013年2月7日 Erik Bray <eri...@gm...>
> On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee <ant...@be...>
> wrote:
> > Hi,
> >
> > I saw that a discussion started on transitioning to the use of properties
> > instead of explicit getters and setters, which seems like a very good
> idea
> > to me... so I thought this would be a good idea to get involved in
> > matplotlib-devel :)
> >
> > Right now an issue raised is what to do with set_* that take multiple
> > arguments. Taking set_title, which takes both positional and keyword
> > arguments, as an example, my idea would be to do
> >
> > ax.title = "A title"
> > ax.title.fontdict = fontdict
> >
> > Basically, a property "foo" (in the matplotlib meaning of the word)
> becomes
> > a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword
> > arguments to the old property setter become themselves descriptors on
> that
> > descriptor.
>
> Unfortunately descriptors don't really work like that, because when
> you do `.title` on an instance that doesn't return the descriptor
> itself, it just returns the result of `__get__` on the descriptor. So
> in your example `.fontdict` would have to be an attribute on any
> string assigned as the title. So what you really have to do for this
> to work is to wrap every value returned by the descriptor in some kind
> of proxy that adds the appropriate extra attributes. It also has to
> do so in a way that the proxy can behave transparently like the
> wrapped object, and that none of the wrapped objects attributes are
> overshadowed. And it has to hypothetically work with instances any
> any arbitrary type or class.
>
> While this is somewhat doable for a limited set cases it's really more
> of a can of worms than it's worth. Believe me, I've tried to solve
> similar problems to this one before. A couple easier solutions: Allow
> the `.title` (and other such attributes) to be assigned to with a
> (value, options) tuple where the value is the title itself, and the
> options is a dictionary or tuple of supported options for the title.
> Another solution is to just keep set_title() for cases like this if
> one wishes to set the title with additional options (while still
> allowing `.title = 'foo'` for the simple case).
>

On 2/7/13 8:08 PM, Erik Bray wrote:
> A couple easier solutions: Allow
> the `.title` (and other such attributes) to be assigned to with a
> (value, options) tuple where the value is the title itself, and the
> options is a dictionary or tuple of supported options for the title.
Interesting. Just brainstorming here...then
ax.title += (None, moreoptions)
could set more options (without changing the title text or already set 
options), or
ax.title -= (None, deleteoptions)
could reset just certain options to default values.
Thanks,
Jason

On Thu, Feb 7, 2013 at 8:40 PM, Antony Lee <ant...@be...> wrote:
> Hi,
>
> I saw that a discussion started on transitioning to the use of properties
> instead of explicit getters and setters, which seems like a very good idea
> to me... so I thought this would be a good idea to get involved in
> matplotlib-devel :)
>
> Right now an issue raised is what to do with set_* that take multiple
> arguments. Taking set_title, which takes both positional and keyword
> arguments, as an example, my idea would be to do
>
> ax.title = "A title"
> ax.title.fontdict = fontdict
>
> Basically, a property "foo" (in the matplotlib meaning of the word) becomes
> a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword
> arguments to the old property setter become themselves descriptors on that
> descriptor.
Unfortunately descriptors don't really work like that, because when
you do `.title` on an instance that doesn't return the descriptor
itself, it just returns the result of `__get__` on the descriptor. So
in your example `.fontdict` would have to be an attribute on any
string assigned as the title. So what you really have to do for this
to work is to wrap every value returned by the descriptor in some kind
of proxy that adds the appropriate extra attributes. It also has to
do so in a way that the proxy can behave transparently like the
wrapped object, and that none of the wrapped objects attributes are
overshadowed. And it has to hypothetically work with instances any
any arbitrary type or class.
While this is somewhat doable for a limited set cases it's really more
of a can of worms than it's worth. Believe me, I've tried to solve
similar problems to this one before. A couple easier solutions: Allow
the `.title` (and other such attributes) to be assigned to with a
(value, options) tuple where the value is the title itself, and the
options is a dictionary or tuple of supported options for the title.
Another solution is to just keep set_title() for cases like this if
one wishes to set the title with additional options (while still
allowing `.title = 'foo'` for the simple case).

On Wed, Jan 30, 2013 at 9:27 PM, Damon McDougall
<dam...@gm...> wrote:
> On Wed, Jan 30, 2013 at 8:44 AM, Michael Droettboom <md...@st...> wrote:
>> In discussions with Perry Greenfield at STScI, it seems we are in the
>> position of being able to get some financial support to pay for a
>> continuous integration system.
>>
>> Travis has shown itself to be rather glitchy for matplotlib. The tight
>> integration with Github PRs is really convenient. However, matplotlib
>> has longer test runs and more dependencies than many projects. The
>> frequent false positives start to wear down at a certain point. And we
>> still aren't testing everything because we can't aren't installing
>> Inkscape and other things in the Travis VM.
>>
>> So we're looking to add another paid, hosted continuous integration
>> service that will better meet our needs. A hosted service is nice
>> because it's easy to give multiple developers access to the system so
>> anyone can tweak it and keep it going -- the bottleneck of a single
>> developer responsible for maintenance of the build machine was a problem
>> years ago when we were using buildbot. This may remain "in addition to"
>> rather than "instead of" Travis for some time.
>>
>> An obvious first choice to me is ShiningPanda, as I have experience
>> using it for astropy. Jenkins (the software Shining Panda is based on),
>> is a really easy-to-use system, for those not familiar with it. And we
>> can store the output of the tests (i.e. the result_images) for later
>> inspection. I think this feature alone is huge for matplotlib. They
>> also offer Windows build slaves. There is no OS-X (probably because
>> Apple licensing doesn't really allow for use in a VM), but results can
>> be "published" to their Jenkins instance.
>>
>> Are there any other similar alternatives we should consider before we
>> move forward?
>>
>> Mike
>
> I think hosted infrastructure is the right choice. I was initially
> going to suggest that we try and work with a bespoke solution. That
> way we could roll our own build architectures.
>
> On reflection I think the maintenance headache of managing our own
> build slaves outweighs the convenience of having it hosted, as you
> point out.
Of course, you're still going to need people who are willing/able to
maintain OSX build slaves if you want to do testing on OSX (which
obviously you should). It's easy with Jenkins to run your own
instances and have it push results to the Shining Panda instance or
any other hosted service. But otherwise you're back to square one in
terms of having to rely on the people running the OSX builds. We've
had this problem on Astropy in that I'm maintaining our current only
Windows machine (ShingingPanda does have Windows support but a a cost)
and so whenever the build bot itself breaks on Windows it's up to me
to do anything about it. It also makes it hard for other admins to
make tweaks to the build configuration.
Unfortunately you're probably going to have that problem with OSX and
probably Windows with any other hosted service as well.
Erik

Hi,
I saw that a discussion started on transitioning to the use of properties
instead of explicit getters and setters, which seems like a very good idea
to me... so I thought this would be a good idea to get involved in
matplotlib-devel :)
Right now an issue raised is what to do with set_* that take multiple
arguments. Taking set_title, which takes both positional and keyword
arguments, as an example, my idea would be to do
ax.title = "A title"
ax.title.fontdict = fontdict
Basically, a property "foo" (in the matplotlib meaning of the word) becomes
a descriptor with __get__ => get_foo and __set__ => set_foo, and keyword
arguments to the old property setter become themselves descriptors on that
descriptor.
Antony

On 02/01/2013 09:11 AM, Todd wrote:
> Is there a process that someone needs to go through to get a pull 
> request merged into master?
Is there a particular pull request that you think has stalled, or you 
just want to know the process in general?
If the former -- just ping us on the mailing list if you think something 
has been stuck for too long.
If the latter, there is documentation here:
http://matplotlib.org/devel/gitwash/index.html
Is this page is a checklst of the things to include in a complete pull 
request:
http://matplotlib.org/devel/coding_guide.html
Mike
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Usually, just simply pinging the devs via the comments in your PR is enough
to bring our attention back to the PR. The squeaky wheel gets the grease.
Cheers!
Ben Root