matplotlib-users Mailing List for matplotlib

Seems like Axes.relim is what I was looking for. It does not take
collections into account but I don't need that for now.

2011/8/1, Goyo <goy...@gm...>:
> Hy all,
>
> I recently had a pretty hard time trying to figure out how to properly
> autoscale a plot after removing a line (see attached script). Finally
> I found at [1] that I have to explicitly refresh the axes dataLim
> before autoscaling.
>
> In [1] John Hunter says that computing the proper dataLim can be
> complicated if there are several types of artists in the axes, like
> polygons and collections an that "[it] would be useful to have an Axes
> method like "auto_datalim" to for the datalim to readjust to all the
> current data."
>
> My question is whether such a function has been implemented. Besides
> any suggestions about how to deal with this are welcome. I just need
> to adjust to lines right now but this may change in the future.
>
> Best regards
>
> Goyo
>
> [1] http://old.nabble.com/Removing-a-line-from-a-plot-td7249600.html
>

On Fri, Aug 5, 2011 at 2:41 PM, Amir Jahanshahi <paj...@gm...> wrote:

> Hi ,
>
> The code for image-windows and image-linx comes from here:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/errorbar_limits.html
>
> That is why I think the problem is in linux. And the pdf which is attached
> along with the png image named flow-rate are executed in linux which are
> different. in windows both are the same.
>
> Thanks,
> Amir
>
> Hi Amir,

So I guess there's two separate issues: 1) pdf vs png output. 2) windows vs
linux output.

1) I have no idea what could be causing the difference in pdf vs png output.
They're rendered the same on my system, so I can't be of much help.

2) I still think the linux output is correct---assuming you're using the
matplotlibrc file you attached. Yes, the example on the matplotlib website
has arrows on the error bars, but in your matplotlibrc file, you've set
lines.markeredgewidth to 0. Thus, you should expect the arrow heads/tails to
disappear. The default matplotlibrc has a nonzero markeredgewidth, which is
why the heads/tails are visible on the website. So to reiterate, linux seems
to be giving the correct behavior. Now, for the windows output, are you
certain you're using the same matplotlibrc? In other words, are you setting
markeredgewidth to 0. If so, then I'd say there's a bug in the windows
output.

-Tony

Hi ,

The code for image-windows and image-linx comes from here:
http://matplotlib.sourceforge.net/examples/pylab_examples/errorbar_limits.html

That is why I think the problem is in linux. And the pdf which is attached
along with the png image named flow-rate are executed in linux which are
different. in windows both are the same.

Thanks,
Amir


On Fri, Aug 5, 2011 at 5:59 PM, Tony Yu <ts...@gm...> wrote:

>
>
> On Fri, Aug 5, 2011 at 9:29 AM, Amir Jahanshahi <paj...@gm...>wrote:
>
>> Dear folks,
>>
>> I have this problem consistently in 0.99 installed via package
>> respiratory and also 1.0.1 from source. This only occurs in linux.
>> Windows is OK. see attachments please. If I run flow-rate.py the output
>> of plt.show() is different from what is written in pdf. both are
>> attached. Very weird problem.
>>
>> Looking forward to hearing from you,
>>
>> System:Linux Amir-Ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28
>> 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Hi Amir,
>
> It seems to me that the error is in the Windows output. In your code,
> you've set "mew" (i.e. marker edge width) to 0. So it makes sense that the
> markers don't show. On my system (OS X), the pdf and png output are the
> same.
>
> Best,
> -Tony
>
>

For a figure with just one subplot, I want to have a larger main title
(using figure.suptitle) and a smaller subtitle (using axes.set_title).
 However, using horizontalalignment = 'center' on both the suptitle
and title doesn't center the two relative to each other, because my
subplot varies in width (I change it depending on the y axis labels'
lengths).

How can I center the suptitle appropriately over the subplot?

Thanks,
Che

Hello,

Michael, since it is happening in my setup, if you are willing to
direct me, I could try to debug and see what could possibly be
happening. I don't discard, however, that this is something that
happens only to me, so, unless someone can reproduce the problem,
this could be marked as a low priority bug.

---
José Alexandre Nalon
na...@te...

Em sex 05 ago 2011, às 12:49:27, Michael Droettboom escreveu:
> I'm still puzzled here.  The TeX file is definitely being generated with
> an unreasonably large size, which is what causes it to blow up.  It gets
> the size from the size of the matplotlib figure, which I assume is being
> incorrectly calculated by the tight bounding box code.  Of course, I
> can't reproduce that here, so I'm not sure what's going on.
> 
> Do any of the developers who understand the tight bounding box code have
> any theories?
> 
> Mike
> 
> On 08/05/2011 09:57 AM, José Alexandre Nalon wrote:
> > Hello!
> > 
> >> This is puzzling.  I can't reproduce this -- I even get nice commas.
> >> Are you running the locale_formatting branch exactly as it is (i.e. not
> >> applying it as a patch to another version of matplotlib)?  What platform
> >> are you on?  Which backend?  What does "echo $LANG" at the commandline
> >> say?
> > 
> > I actually am getting this error with a couple of scripts,
> > but both use bbox_inches='tight', and are 3D plots. I tried
> > 2D plots with this option and there was no problem. In every
> > script, I also get the commas. It is probably one of those
> > bugs that appear because of the configuration of the many
> > packages that are being used.
> > 
> > I gathered some information, and I hope it helps. I am using
> > Kubuntu 10.10, and Texlive distribution. I downloaded the
> > .tar.gz package from github in your branch, and built it.
> > At the time of compilation, I didn't have Tk or GTK headers
> > (since I don't use matplotlib interactively, I don't really
> > need them). Below, I also included the list of met dependencies,
> > according to the installation script. I got no errors during
> > compilation, only a warning (also listed below). Tex file
> > and others are attached with this message (since my /tmp
> > directory was wiped in reboot, I had to run the script again,
> > hence the different names). This is all the information that I
> > could think of, but if there is anything else, just send a
> > message. Thanks again for your work!
> > 
> > nalon@marvin:~/temp/test$ uname -a
> > Linux marvin 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:00:22 UTC
> > 2011 i686 GNU/Linux
> > 
> > nalon@marvin:~/temp/test$ echo $LANG
> > pt_BR.UTF-8
> > 
> > nalon@marvin:~/temp/test$ latex -v
> > pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
> > kpathsea version 5.0.0
> > Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
> > There is NO warranty.  Redistribution of this software is
> > covered by the terms of both the pdfTeX copyright and
> > the Lesser GNU General Public License.
> > For more information about these matters, see the file
> > named COPYING and the pdfTeX source.
> > Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh
> > (pdfTeX). Compiled with libpng 1.2.44; using libpng 1.2.44
> > Compiled with zlib 1.2.3.4; using zlib 1.2.3.4
> > Compiled with poppler version 0.14.2
> > 
> > nalon@marvin:~/temp/test$ python
> > Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
> > [GCC 4.4.5] on linux2
> > 
> >>>> numpy.__version__
> > 
> > '1.3.0'
> > 
> >>>> matplotlib.__version__
> > 
> > '1.1.0'
> > 
> >>>> print matplotlib.rcParams['backend']
> > 
> > agg
> > 
> > Here is a relation of met dependencies and their versions
> > (according to matplotlib installation script):
> > 
> > Qt: 4.7.0
> > PyQt: 4.8.1
> > Freetype2: 12.0.6
> > Cairo: 1.8.8
> > libpng: 1.2.44
> > dvipng: 1.13
> > ghostscript: 8.71
> > latex: 3.1415926
> > pdftops: 0.14.3
> > 
> > No errors during installation, only these warnings:
> > 
> > src/path.cpp: In member function ‘Py::Object
> > _path_module::convert_to_svg(const Py::Tuple&)’:
> > src/path.cpp:1590: warning: format not a string literal and no format
> > arguments
> > src/path.cpp:1590: warning: format not a string literal and no format
> > arguments
> > src/path.cpp:1593: warning: format not a string literal and no format
> > arguments
> > src/path.cpp:1593: warning: format not a string literal and no format
> > arguments
> > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y2’ may be
> > used uninitialized in this function
> > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x2’ may be
> > used uninitialized in this function
> > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y1’ may be
> > used uninitialized in this function
> > src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x1’ may be
> > used uninitialized in this function
> > 
> > ---
> > José Alexandre Nalon
> > na...@te...
> 
> ---------------------------------------------------------------------------
> --- BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Fri, Aug 5, 2011 at 9:29 AM, Amir Jahanshahi <paj...@gm...> wrote:

> Dear folks,
>
> I have this problem consistently in 0.99 installed via package
> respiratory and also 1.0.1 from source. This only occurs in linux.
> Windows is OK. see attachments please. If I run flow-rate.py the output
> of plt.show() is different from what is written in pdf. both are
> attached. Very weird problem.
>
> Looking forward to hearing from you,
>
> System:Linux Amir-Ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28
> 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
>
> Hi Amir,

It seems to me that the error is in the Windows output. In your code, you've
set "mew" (i.e. marker edge width) to 0. So it makes sense that the markers
don't show. On my system (OS X), the pdf and png output are the same.

Best,
-Tony

Hi, I am using add_subplot(...) to create a row of 4 plots, and have a tricky
question.
I have an image (a figure instance) composed of 4 subplots in a single row.
I'd like to know how to arrange a number of these rows in a bigger grid,
namely a grid of 10x3 plots, each plot made up of 1x4 subplots. The ideal
solution would be:
* function that returns 1x4 plots
* call that function repeatedly
I tried to do this with
def function(figure, which_one, index):
  grid = ImageGrid(figure, 10,3,index, nrows_ncols = (1, 4))
  grid[0].imshow(something(which_one))
  grid[1].imshow(.....)
  ...

however the plots apparently share the y axis, which for me is unfeasable
as:
1) the first of 4 images has about 10000 pixels, while the others have 24
(6x4 pixels): no chance they can be on the same scale!
2) I want to plot a colorbar on top of the 6x4 subplots.
3) I want to write labels on top of the 6x4 subplots.

This is what grid produces: an ugly white space if y axes don't have the
same length.
http://old.nabble.com/file/p32203453/grid.png 

This is my best attempt, still a lot of work to do, but don't know how to
tile several of these in a 10x3 array.
http://old.nabble.com/file/p32203453/ifu1_1plot.png 

Thank you very much.

Desperately,
astabada
-- 
View this message in context: http://old.nabble.com/Subplot-of-subplots.-tp32203453p32203453.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I'm still puzzled here.  The TeX file is definitely being generated with 
an unreasonably large size, which is what causes it to blow up.  It gets 
the size from the size of the matplotlib figure, which I assume is being 
incorrectly calculated by the tight bounding box code.  Of course, I 
can't reproduce that here, so I'm not sure what's going on.

Do any of the developers who understand the tight bounding box code have 
any theories?

Mike

On 08/05/2011 09:57 AM, José Alexandre Nalon wrote:
> Hello!
>
>> This is puzzling.  I can't reproduce this -- I even get nice commas.
>> Are you running the locale_formatting branch exactly as it is (i.e. not
>> applying it as a patch to another version of matplotlib)?  What platform
>> are you on?  Which backend?  What does "echo $LANG" at the commandline say?
> I actually am getting this error with a couple of scripts,
> but both use bbox_inches='tight', and are 3D plots. I tried
> 2D plots with this option and there was no problem. In every
> script, I also get the commas. It is probably one of those
> bugs that appear because of the configuration of the many
> packages that are being used.
>
> I gathered some information, and I hope it helps. I am using
> Kubuntu 10.10, and Texlive distribution. I downloaded the
> .tar.gz package from github in your branch, and built it.
> At the time of compilation, I didn't have Tk or GTK headers
> (since I don't use matplotlib interactively, I don't really
> need them). Below, I also included the list of met dependencies,
> according to the installation script. I got no errors during
> compilation, only a warning (also listed below). Tex file
> and others are attached with this message (since my /tmp
> directory was wiped in reboot, I had to run the script again,
> hence the different names). This is all the information that I
> could think of, but if there is anything else, just send a
> message. Thanks again for your work!
>
> nalon@marvin:~/temp/test$ uname -a
> Linux marvin 2.6.35-30-generic #56-Ubuntu SMP Mon Jul 11 20:00:22 UTC 2011
> i686 GNU/Linux
>
> nalon@marvin:~/temp/test$ echo $LANG
> pt_BR.UTF-8
>
> nalon@marvin:~/temp/test$ latex -v
> pdfTeX 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian)
> kpathsea version 5.0.0
> Copyright 2009 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
> There is NO warranty.  Redistribution of this software is
> covered by the terms of both the pdfTeX copyright and
> the Lesser GNU General Public License.
> For more information about these matters, see the file
> named COPYING and the pdfTeX source.
> Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX).
> Compiled with libpng 1.2.44; using libpng 1.2.44
> Compiled with zlib 1.2.3.4; using zlib 1.2.3.4
> Compiled with poppler version 0.14.2
>
> nalon@marvin:~/temp/test$ python
> Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
> [GCC 4.4.5] on linux2
>
>>>> numpy.__version__
> '1.3.0'
>>>> matplotlib.__version__
> '1.1.0'
>>>> print matplotlib.rcParams['backend']
> agg
>
> Here is a relation of met dependencies and their versions
> (according to matplotlib installation script):
>
> Qt: 4.7.0
> PyQt: 4.8.1
> Freetype2: 12.0.6
> Cairo: 1.8.8
> libpng: 1.2.44
> dvipng: 1.13
> ghostscript: 8.71
> latex: 3.1415926
> pdftops: 0.14.3
>
> No errors during installation, only these warnings:
>
> src/path.cpp: In member function ‘Py::Object
> _path_module::convert_to_svg(const Py::Tuple&)’:
> src/path.cpp:1590: warning: format not a string literal and no format
> arguments
> src/path.cpp:1590: warning: format not a string literal and no format
> arguments
> src/path.cpp:1593: warning: format not a string literal and no format
> arguments
> src/path.cpp:1593: warning: format not a string literal and no format
> arguments
> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y2’ may be used
> uninitialized in this function
> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x2’ may be used
> uninitialized in this function
> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::y1’ may be used
> uninitialized in this function
> src/path.cpp:1502: warning: ‘clip_rect.agg::rect_base<double>::x1’ may be used
> uninitialized in this function
>
> ---
> José Alexandre Nalon
> na...@te...

Dear folks,

I have this problem consistently in 0.99 installed via package
respiratory and also 1.0.1 from source. This only occurs in linux.
Windows is OK. see attachments please. If I run flow-rate.py the output
of plt.show() is different from what is written in pdf. both are
attached. Very weird problem.

Looking forward to hearing from you,

System:Linux Amir-Ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28
15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Other info:gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)