matplotlib-users Mailing List for matplotlib

2011年5月12日 David Andrews <irb...@gm...>:
> Hi,
>
> I've come across something I don't entirely understand in the
> behaviour of gridspec. It's not obvious from the code & docs for this
> module, but is it only supposed to be able to deal with 'square'
> layouts, e.g. 3x3, 4x4 etc?
>
> Taking some code from an example on the gridspec page ...
>
> import matplotlib.pylab as plt
> import matplotlib.gridspec as gridspec
> #gs = gridspec.GridSpec(3, 3) # OK
> gs = gridspec.GridSpec(6, 3) # Will cause an error later on
> ax1 = plt.subplot(gs[0, :])
> ax2 = plt.subplot(gs[1,:-1])
> ax3 = plt.subplot(gs[1:,-1])
> ax4 = plt.subplot(gs[-1,0])
> ax5 = plt.subplot(gs[-1,-2])
> plt.show()
>
> ... will fail if that line is uncommented, giving an index error.
Works for me.
Ubuntu 11.04 Natty, stock python 2.7.1 and matplotlib 1.0.1 from
https://launchpad.net/~valavanisalex/+archive/matplotlib.

Hi,
I've come across something I don't entirely understand in the
behaviour of gridspec. It's not obvious from the code & docs for this
module, but is it only supposed to be able to deal with 'square'
layouts, e.g. 3x3, 4x4 etc?
Taking some code from an example on the gridspec page ...
import matplotlib.pylab as plt
import matplotlib.gridspec as gridspec
#gs = gridspec.GridSpec(3, 3) # OK
gs = gridspec.GridSpec(6, 3) # Will cause an error later on
ax1 = plt.subplot(gs[0, :])
ax2 = plt.subplot(gs[1,:-1])
ax3 = plt.subplot(gs[1:,-1])
ax4 = plt.subplot(gs[-1,0])
ax5 = plt.subplot(gs[-1,-2])
plt.show()
... will fail if that line is uncommented, giving an index error. I
don't see any reason why these slices should fail however, though
obviously it won't use all the available space within the whole grid?
Substituting a 'square' grid for the (6,3), e.g. (4,4), (5,5) etc
seems to be fine though.
I'm quite interested in getting involved with mpl development, partly
as a way to get my head around python & numpy and aid porting a bunch
of stuff I use over to python from IDL. Unless I'm doing something
totally wrong by expecting the above snippet to work, then I'd happily
spend some time looking into this in more detail, having written some
similar code in IDL. The docs for that module also look like they
could benefit from some work.
Cheers,
Dave
---------
David Andrews
PhD Student, Radio & Space Plasma Physics Group, University of Leicester, UK

2011年5月11日 calle <ka...@we...>:
> [...]
> So is there for example a way to set sth like
>
> axes([0.125,0.2,0.95-0.125,0.95-0.2])
>
> or alike without the need to repeat it for every single plot?
Not that I'm aware of. But in what sense is that worst than repeat
subplot() for every single plot? Yes there are magic numbers there but
subplot also uses magic numbers under the hood, if I'm not wrong.
You can wrap your axes call into another function so at least the
magic numbers are not visible in the higher level code if they are
always the same.
Goyo

On Wed, May 11, 2011 at 4:31 PM, Eric Firing <ef...@ha...> wrote:
> On 05/11/2011 09:11 AM, Benjamin Root wrote:
> >
> >
> > On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...
> > <mailto:tod...@gm...>> wrote:
> >
> > On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...
> > <mailto:ben...@ou...>> wrote:
> > >
> > >
> > > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> > <bre...@br... <mailto:bre...@br...>>
> > > wrote:
> > >> One thing I've always wondered: is it fundamentally
> > impossible to
> > >> change the fact that, in matplotlib, you cannot know how big a
> drawn
> > >> object will be until you actually draw it? When I was doing some
> > >> animation stuff a while back this caused me a lot of headache,
> > for the
> > >> reasons Tony Yu mentioned: it means you have to draw everything
> > >> multiple times. It would really help if it were possible to
> specify
> > >> objects' parameters and get their sizes without drawing them.
> > >>
> > >> -- Brendan Barnwell
> > >> "Do not follow where the path may lead. Go, instead, where there
> > is no
> > >> path, and leave a trail." --author unknown
> > >>
> > >
> > > Most things, we do know the sizes of. It is my understanding
> > that it is the
> > > text objects that is the unknown. If this could be solved, then
> > a layout
> > > engine would be much more feasible. The problem is that even
> > LaTeX has to
> > > re-render things multiple times to get this right for an
> > arbitrary font. If
> > > we were to restrict ourselves to particular fonts and package
> > those fonts
> > > with matplotlib, then we could have an internal table of size
> > information
> > > for each glyph and compute it on the fly and lay everything out
> > right. But,
> > > that would cause us to give up significant benefits for another
> > benefit.
> > >
> > > I think the pain of the bootstrapping/re-rendering approach could
> > be reduced
> > > significantly if we could get various aspects of matplotlib
> > figure building
> > > to be faster. Last time I checked, there is significant amount of
> > > processing time spent in calculating the ticks for the axes.
> > Maybe if we
> > > focus some efforts in improving the efficiency of certain parts of
> > > matplotlib, maybe we could introduce a convenience function like
> > the one
> > > earlier in this thread that some users can choose to use with
> > only a slight
> > > penalty in speed. I personally would not want to make it
> > default, but
> > > certainly would consider highly advertising such a function.
> > >
> > > Just my two cents,
> > > Ben Root
> >
> > Perhaps there could be three options:
> >
> > 1. Manual mode: current behavior
> > 2. Database mode: uses a list of known fonts. When a font not found
> > in the database is used, it falls back to manual mode.
> > 3. Automatic mode: uses a list of known fonts. When a font not found
> > in the database is used, it renders the text alone in an invisible
> > figure to calculate the space needed, then uses that information to
> > set the margins. Alternatively, create a temporary mini font
> database
> > just for the characters needed. The former approach may be faster,
> > but the latter may be easier to program since it could share a lot of
> > code with the database.
> >
> > There could also be a function to scan a particular font and add to
> > the database (there would probably be a separate user database in
> your
> > matplotlib configuration directory that this would use, as well as
> > probably caching the measurements from text used in automatic mode
> for
> > future versions of the figure).
> >
> > -Todd
> >
> >
> > That might be a possible direction. Obviously, any route taken will
> > have to be well thought-out and designed. What is great about moving
> > over to git is that the user community can easily experiment on larger
> > changes to the code-base, and make it easier for others to test out
> > experimental designs and collaborate. I encourage those in this thread
> > to make a fork of matplotlib on github and experiment with some of these
> > ideas and we all can play around with some of these parts.
> >
> > As a further bit of information, I believe that there is an old project
> > that attempted a layout engine for matplotlib
> > (https://github.com/matplotlib/mplsizer). I have never used it, nor do I
> > have any idea if it still works, but it may be an interesting codebase
> > to start from.
> >
> > As a further comment about a database of text size information. An
> > interesting complication I just noticed are fonts that allow certain
> > combinations of characters to overlap a bit. For example, right now I
> > noticed that using Gils Sans in LibreOffice that the word "Tracking" has
> > the 'r' in with the 'T'. Calculating the amount of space a particular
> > set of characters might take up may not be very straight-forward.
>
> The calculation doesn't have to be perfect, it just has to be good
> enough for layout purposes. If one were to ignore kerning, the
> predicted width of a text string would be slightly larger than the
> actual size. I don't think this would cause serious layout problems.
>
> But--is doing the calculation this way actually much faster than letting
> the renderer do it? Enough to be worth building and maintaining all the
> extra machinery?
>
> Eric
>
>
Kerning, that's the term. I couldn't think of it...
As for the issue about is it worth it to have all of this extra machinery,
that was pretty much my point of the email. If someone wants to see if they
can make an elegant solution that works well and is easy to maintain, then I
would have no problem including it into the codebase. However, I am very
doubtful of that and I would rather see effort in improving the efficiency
of various parts of matplotlib so that various brute-force approaches to
layout will have less time penalty. Plus, it wouldn't hurt to have faster
graphics generation for the rest of us, either!
Ben Root

On 05/11/2011 09:11 AM, Benjamin Root wrote:
>
>
> On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...
> <mailto:tod...@gm...>> wrote:
>
> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
> >
> >
> > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell
> <bre...@br... <mailto:bre...@br...>>
> > wrote:
> >> One thing I've always wondered: is it fundamentally
> impossible to
> >> change the fact that, in matplotlib, you cannot know how big a drawn
> >> object will be until you actually draw it? When I was doing some
> >> animation stuff a while back this caused me a lot of headache,
> for the
> >> reasons Tony Yu mentioned: it means you have to draw everything
> >> multiple times. It would really help if it were possible to specify
> >> objects' parameters and get their sizes without drawing them.
> >>
> >> -- Brendan Barnwell
> >> "Do not follow where the path may lead. Go, instead, where there
> is no
> >> path, and leave a trail." --author unknown
> >>
> >
> > Most things, we do know the sizes of. It is my understanding
> that it is the
> > text objects that is the unknown. If this could be solved, then
> a layout
> > engine would be much more feasible. The problem is that even
> LaTeX has to
> > re-render things multiple times to get this right for an
> arbitrary font. If
> > we were to restrict ourselves to particular fonts and package
> those fonts
> > with matplotlib, then we could have an internal table of size
> information
> > for each glyph and compute it on the fly and lay everything out
> right. But,
> > that would cause us to give up significant benefits for another
> benefit.
> >
> > I think the pain of the bootstrapping/re-rendering approach could
> be reduced
> > significantly if we could get various aspects of matplotlib
> figure building
> > to be faster. Last time I checked, there is significant amount of
> > processing time spent in calculating the ticks for the axes.
> Maybe if we
> > focus some efforts in improving the efficiency of certain parts of
> > matplotlib, maybe we could introduce a convenience function like
> the one
> > earlier in this thread that some users can choose to use with
> only a slight
> > penalty in speed. I personally would not want to make it
> default, but
> > certainly would consider highly advertising such a function.
> >
> > Just my two cents,
> > Ben Root
>
> Perhaps there could be three options:
>
> 1. Manual mode: current behavior
> 2. Database mode: uses a list of known fonts. When a font not found
> in the database is used, it falls back to manual mode.
> 3. Automatic mode: uses a list of known fonts. When a font not found
> in the database is used, it renders the text alone in an invisible
> figure to calculate the space needed, then uses that information to
> set the margins. Alternatively, create a temporary mini font database
> just for the characters needed. The former approach may be faster,
> but the latter may be easier to program since it could share a lot of
> code with the database.
>
> There could also be a function to scan a particular font and add to
> the database (there would probably be a separate user database in your
> matplotlib configuration directory that this would use, as well as
> probably caching the measurements from text used in automatic mode for
> future versions of the figure).
>
> -Todd
>
>
> That might be a possible direction. Obviously, any route taken will
> have to be well thought-out and designed. What is great about moving
> over to git is that the user community can easily experiment on larger
> changes to the code-base, and make it easier for others to test out
> experimental designs and collaborate. I encourage those in this thread
> to make a fork of matplotlib on github and experiment with some of these
> ideas and we all can play around with some of these parts.
>
> As a further bit of information, I believe that there is an old project
> that attempted a layout engine for matplotlib
> (https://github.com/matplotlib/mplsizer). I have never used it, nor do I
> have any idea if it still works, but it may be an interesting codebase
> to start from.
>
> As a further comment about a database of text size information. An
> interesting complication I just noticed are fonts that allow certain
> combinations of characters to overlap a bit. For example, right now I
> noticed that using Gils Sans in LibreOffice that the word "Tracking" has
> the 'r' in with the 'T'. Calculating the amount of space a particular
> set of characters might take up may not be very straight-forward.
The calculation doesn't have to be perfect, it just has to be good 
enough for layout purposes. If one were to ignore kerning, the 
predicted width of a text string would be slightly larger than the 
actual size. I don't think this would cause serious layout problems.
But--is doing the calculation this way actually much faster than letting 
the renderer do it? Enough to be worth building and maintaining all the 
extra machinery?
Eric
>
> Just another 2 cents,
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, May 11, 2011 at 1:43 PM, todd rme <tod...@gm...> wrote:
> On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <
> bre...@br...>
> > wrote:
> >> One thing I've always wondered: is it fundamentally impossible to
> >> change the fact that, in matplotlib, you cannot know how big a drawn
> >> object will be until you actually draw it? When I was doing some
> >> animation stuff a while back this caused me a lot of headache, for the
> >> reasons Tony Yu mentioned: it means you have to draw everything
> >> multiple times. It would really help if it were possible to specify
> >> objects' parameters and get their sizes without drawing them.
> >>
> >> -- Brendan Barnwell
> >> "Do not follow where the path may lead. Go, instead, where there is no
> >> path, and leave a trail." --author unknown
> >>
> >
> > Most things, we do know the sizes of. It is my understanding that it is
> the
> > text objects that is the unknown. If this could be solved, then a layout
> > engine would be much more feasible. The problem is that even LaTeX has
> to
> > re-render things multiple times to get this right for an arbitrary font.
> If
> > we were to restrict ourselves to particular fonts and package those fonts
> > with matplotlib, then we could have an internal table of size information
> > for each glyph and compute it on the fly and lay everything out right.
> But,
> > that would cause us to give up significant benefits for another benefit.
> >
> > I think the pain of the bootstrapping/re-rendering approach could be
> reduced
> > significantly if we could get various aspects of matplotlib figure
> building
> > to be faster. Last time I checked, there is significant amount of
> > processing time spent in calculating the ticks for the axes. Maybe if we
> > focus some efforts in improving the efficiency of certain parts of
> > matplotlib, maybe we could introduce a convenience function like the one
> > earlier in this thread that some users can choose to use with only a
> slight
> > penalty in speed. I personally would not want to make it default, but
> > certainly would consider highly advertising such a function.
> >
> > Just my two cents,
> > Ben Root
>
> Perhaps there could be three options:
>
> 1. Manual mode: current behavior
> 2. Database mode: uses a list of known fonts. When a font not found
> in the database is used, it falls back to manual mode.
> 3. Automatic mode: uses a list of known fonts. When a font not found
> in the database is used, it renders the text alone in an invisible
> figure to calculate the space needed, then uses that information to
> set the margins. Alternatively, create a temporary mini font database
> just for the characters needed. The former approach may be faster,
> but the latter may be easier to program since it could share a lot of
> code with the database.
>
> There could also be a function to scan a particular font and add to
> the database (there would probably be a separate user database in your
> matplotlib configuration directory that this would use, as well as
> probably caching the measurements from text used in automatic mode for
> future versions of the figure).
>
> -Todd
>
>
That might be a possible direction. Obviously, any route taken will have to
be well thought-out and designed. What is great about moving over to git is
that the user community can easily experiment on larger changes to the
code-base, and make it easier for others to test out experimental designs
and collaborate. I encourage those in this thread to make a fork of
matplotlib on github and experiment with some of these ideas and we all can
play around with some of these parts.
As a further bit of information, I believe that there is an old project that
attempted a layout engine for matplotlib (
https://github.com/matplotlib/mplsizer). I have never used it, nor do I have
any idea if it still works, but it may be an interesting codebase to start
from.
As a further comment about a database of text size information. An
interesting complication I just noticed are fonts that allow certain
combinations of characters to overlap a bit. For example, right now I
noticed that using Gils Sans in LibreOffice that the word "Tracking" has the
'r' in with the 'T'. Calculating the amount of space a particular set of
characters might take up may not be very straight-forward.
Just another 2 cents,
Ben Root

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <bre...@br...>
> wrote:
>>    One thing I've always wondered: is it fundamentally impossible to
>> change the fact that, in matplotlib, you cannot know how big a drawn
>> object will be until you actually draw it? When I was doing some
>> animation stuff a while back this caused me a lot of headache, for the
>> reasons Tony Yu mentioned: it means you have to draw everything
>> multiple times. It would really help if it were possible to specify
>> objects' parameters and get their sizes without drawing them.
>>
>> -- Brendan Barnwell
>> "Do not follow where the path may lead. Go, instead, where there is no
>> path, and leave a trail." --author unknown
>>
>
> Most things, we do know the sizes of. It is my understanding that it is the
> text objects that is the unknown. If this could be solved, then a layout
> engine would be much more feasible. The problem is that even LaTeX has to
> re-render things multiple times to get this right for an arbitrary font. If
> we were to restrict ourselves to particular fonts and package those fonts
> with matplotlib, then we could have an internal table of size information
> for each glyph and compute it on the fly and lay everything out right. But,
> that would cause us to give up significant benefits for another benefit.
>
> I think the pain of the bootstrapping/re-rendering approach could be reduced
> significantly if we could get various aspects of matplotlib figure building
> to be faster. Last time I checked, there is significant amount of
> processing time spent in calculating the ticks for the axes. Maybe if we
> focus some efforts in improving the efficiency of certain parts of
> matplotlib, maybe we could introduce a convenience function like the one
> earlier in this thread that some users can choose to use with only a slight
> penalty in speed. I personally would not want to make it default, but
> certainly would consider highly advertising such a function.
>
> Just my two cents,
> Ben Root
Perhaps there could be three options:
1. Manual mode: current behavior
2. Database mode: uses a list of known fonts. When a font not found
in the database is used, it falls back to manual mode.
3. Automatic mode: uses a list of known fonts. When a font not found
in the database is used, it renders the text alone in an invisible
figure to calculate the space needed, then uses that information to
set the margins. Alternatively, create a temporary mini font database
just for the characters needed. The former approach may be faster,
but the latter may be easier to program since it could share a lot of
code with the database.
There could also be a function to scan a particular font and add to
the database (there would probably be a separate user database in your
matplotlib configuration directory that this would use, as well as
probably caching the measurements from text used in automatic mode for
future versions of the figure).
-Todd

On Wed, May 11, 2011 at 1:59 PM, Benjamin Root <ben...@ou...> wrote:
> ...
> Most things, we do know the sizes of. It is my understanding that it is
> the text objects that is the unknown. If this could be solved, then a
> layout engine would be much more feasible. The problem is that even LaTeX
> has to re-render things multiple times to get this right for an arbitrary
> font. If we were to restrict ourselves to particular fonts and package
> those fonts with matplotlib, then we could have an internal table of size
> information for each glyph and compute it on the fly and lay everything out
> right. But, that would cause us to give up significant benefits for another
> benefit.
> ...
>
I suppose a compromise would be to have that internal table for a fixed set
of fonts, and if the user asks for a font that's not shipped with
matplotlib, then they fall back to the current (presumably slower) method.
Would probably complicate things in the layout code, though.
 Justin

On Wed, May 11, 2011 at 12:47 PM, Brendan Barnwell <bre...@br...>wrote:
> [Accidentally sent this reply privately the first time, natch.]
>
> On 2011年05月11日 04:29, Jae-Joon Lee wrote:
> > > On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
> > > <dan...@go...> wrote:
> >> >> Hi Jae-Loon,
> >> >>
> >> >> thanks for your comments! Of course I do agree that a figure
> layout
> >> >> should not change in interactive mode. However, I don't see
> why this
> >> >> should happen upon a panning action. A different case is when the
> >> >> label or title font sizes are changed, but I was assuming this is
> >> >> adjusted prior to the creation of the figure.
> >> >>
> > >
> > > Since you said the current design is broken, I thought you want
> things
> > > adjusted *whenever* a figure is updated.
> > >
> > > So, I guess what you want is some functionality like what Tony's
> script does?
> > > One of the reason that I was not very inclined to Tony's approach is
> > > that it only works for subplots (and I guess it only works with
> > > subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
> > > is better than nothing. I'll consider how things can be improved.
>
> One thing I've always wondered: is it fundamentally impossible to
> change the fact that, in matplotlib, you cannot know how big a drawn
> object will be until you actually draw it? When I was doing some
> animation stuff a while back this caused me a lot of headache, for the
> reasons Tony Yu mentioned: it means you have to draw everything
> multiple times. It would really help if it were possible to specify
> objects' parameters and get their sizes without drawing them.
>
> -- Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is no
> path, and leave a trail." --author unknown
>
>
Most things, we do know the sizes of. It is my understanding that it is the
text objects that is the unknown. If this could be solved, then a layout
engine would be much more feasible. The problem is that even LaTeX has to
re-render things multiple times to get this right for an arbitrary font. If
we were to restrict ourselves to particular fonts and package those fonts
with matplotlib, then we could have an internal table of size information
for each glyph and compute it on the fly and lay everything out right. But,
that would cause us to give up significant benefits for another benefit.
I think the pain of the bootstrapping/re-rendering approach could be reduced
significantly if we could get various aspects of matplotlib figure building
to be faster. Last time I checked, there is significant amount of
processing time spent in calculating the ticks for the axes. Maybe if we
focus some efforts in improving the efficiency of certain parts of
matplotlib, maybe we could introduce a convenience function like the one
earlier in this thread that some users can choose to use with only a slight
penalty in speed. I personally would not want to make it default, but
certainly would consider highly advertising such a function.
Just my two cents,
Ben Root

[Accidentally sent this reply privately the first time, natch.]
On 2011年05月11日 04:29, Jae-Joon Lee wrote:
 > > On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
 > > <dan...@go...> wrote:
 >> >> Hi Jae-Loon,
 >> >>
 >> >> thanks for your comments! Of course I do agree that a figure 
layout
 >> >> should not change in interactive mode. However, I don't see 
why this
 >> >> should happen upon a panning action. A different case is when the
 >> >> label or title font sizes are changed, but I was assuming this is
 >> >> adjusted prior to the creation of the figure.
 >> >>
 > >
 > > Since you said the current design is broken, I thought you want 
things
 > > adjusted *whenever* a figure is updated.
 > >
 > > So, I guess what you want is some functionality like what Tony's 
script does?
 > > One of the reason that I was not very inclined to Tony's approach is
 > > that it only works for subplots (and I guess it only works with
 > > subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
 > > is better than nothing. I'll consider how things can be improved.
	One thing I've always wondered: is it fundamentally impossible to
change the fact that, in matplotlib, you cannot know how big a drawn
object will be until you actually draw it? When I was doing some
animation stuff a while back this caused me a lot of headache, for the
reasons Tony Yu mentioned: it means you have to draw everything
multiple times. It would really help if it were possible to specify
objects' parameters and get their sizes without drawing them.
-- Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no 
path, and leave a trail." --author unknown

On Wed, May 11, 2011 at 11:07 AM, C M <cmp...@gm...> wrote:
> On Wed, May 11, 2011 at 12:29 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> I think I fixed a similar bug at some point but I'm not sure if that
>> is related with this.
>> Are you using the *make_axes_area_auto_adjustable* from the current
>> git master (check
>> examples/axes_grid/make_room_for_ylabel_using_axesgrid.py)? If not can
>> you try that? Also please post your code.
>
I have not set up with git since Matplotlib made the change from svn.
I just downloaded git to get started but don't know how to use it yet;
for now is there a way to just check out the files I need to test
this, or is there some other (non-git) way to get this update?
Thanks,
Che

Hi,
we're running Matplotlib 1.0.0 with Python 2.6.2 on CentOS 5.6. When 
importing from matplotlib._path, users get an error message
"undefined symbol: 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l"
I'm at a loss. There were no errors during the installation
Generating the error:
$ python-2.6
Python 2.6.2 (r262:71600, Aug 5 2010, 14:21:11)
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from matplotlib._path import affine_transform
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: 
/g/software/linux/pack/python-2.6/lib/python2.6/site-packages/matplotlib/_path.so: 
undefined symbol: 
_ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
 >>> exit()
$
Anyone has seen this before and/or knows a fix? There are some reports 
about such an error on the web, but they are all quite old and I cannot 
relate them to the current issue.
Thanks in advance
 frank

hi, just curious if anyone wants to add some publication formating
settings? if you send me the rc params, and publication infos i add them
to the project. 
http://code.google.com/p/mplrc/
On Sat, 2011年04月16日 at 14:21 -0400, alex arsenovic wrote:
> i created the project for 'mplrc' here
> https://code.google.com/p/mplrc/
> 
> let me know what you all think. if you all send me your publications'
> settings i can add them, or if you want an account ill make you one. 
> 
> one thing to mention is that the params dictionary probably should set
> all possible settings so that there is no ambiguity. i have yet to do
> this.
> 
> here is an example of my ieee format
> 
> 
> On Fri, 2011年04月15日 at 14:09 -0400, Tony Yu wrote:
> > 
> > 
> > On Fri, Apr 15, 2011 at 8:36 AM, Auré Gourrier
> > <aur...@ya...> wrote:
> > Good Idea !
> > I'm also using mpl for other publications than ieee and it
> > sounds like a small mplrc data base with targeted journal
> > specifications would be worthwhile doing ! I would be ready to
> > contribute.
> > Cheers,
> > Auré
> > 
> > 
> > 
> > 
> > Is there any reason this needs to done with rc files? I prefer to put
> > document-specific configuration into modules. For example, you could
> > have a module that looks like:
> > 
> > mplrc/
> > __init__.py
> > aps_fullpage.py
> > aps_twocolumn.py
> > ieee.py
> > ...
> > 
> > (`aps` could even be directory). And each module would set rc
> > parameters using function calls; for example, aps_twocolumn.py might
> > look like:
> > 
> > import matplotlib.pyplot as plt
> > plt.rc('axes', labelsize=10)
> > plt.rc('text', fontsize=10)
> > plt.rc('legend', fontsize=10)
> > plt.rc('xtick', labelsize=8)
> > plt.rc('ytick', labelsize=8)
> > plt.rc('text', usetex=False)
> > plt.rc('figure', figsize=(3.4039, 2.1037))
> > 
> > (Alternatively, you could create a separate rc file and just have the
> > module load that rc file). The advantage of this module-based approach
> > is that you could simply import the module whenever you need it (e.g.,
> > just add `import mplrc.aps_twocolumn` at the top of your script). If I
> > used an rc file instead, I'd have to copy the rc file to my working
> > directory each time, or somehow, manually load the rc file from a
> > path.
> > 
> > Just a suggestion.
> > 
> > -Tony
> > 
> 

Hi again,
>> Hi Jae-Loon,
>>
>> thanks for your comments! Of course I do agree that a figure layout
>> should not change in interactive mode. However, I don't see why this
>> should happen upon a panning action. A different case is when the
>> label or title font sizes are changed, but I was assuming this is
>> adjusted prior to the creation of the figure.
>>
>
> Since you said the current design is broken, I thought you want things
> adjusted *whenever* a figure is updated.
>
> So, I guess what you want is some functionality like what Tony's script does?
> One of the reason that I was not very inclined to Tony's approach is
> that it only works for subplots (and I guess it only works with
> subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
> is better than nothing. I'll consider how things can be improved.
I do sense a match of ideas here :) This is exactly what I am missing!
It is very good to hear that you are so open to suggestions and
possible improvements!
It is a great pleasure to work with Scipy/Matplotlib and interact with
the community!
Best regards,
Daniel

On Wed, May 11, 2011 at 5:03 PM, Daniel Mader
<dan...@go...> wrote:
> Hi Jae-Loon,
>
> thanks for your comments! Of course I do agree that a figure layout
> should not change in interactive mode. However, I don't see why this
> should happen upon a panning action. A different case is when the
> label or title font sizes are changed, but I was assuming this is
> adjusted prior to the creation of the figure.
>
Since you said the current design is broken, I thought you want things
adjusted *whenever* a figure is updated.
So, I guess what you want is some functionality like what Tony's script does?
One of the reason that I was not very inclined to Tony's approach is
that it only works for subplots (and I guess it only works with
subplots with pure n x m grid. Correct me if I'm wrong). But maybe it
is better than nothing. I'll consider how things can be improved.
Regards,
-JJ
> For the time being I am very happy with Tony's solution. It works nice
> most of the time, only very complex figures take forever now to be
> drawn.
>
> The current behavior *looks* broken to any user who does not
> understand the internals. And it's too likely that even simple figures
> look horrible. I'd definitely vote for a more end-user friendly
> solution (with end users I have scientific users in mind who generally
> appreciate the beauty of the generated plots but who don't integrated
> the library into some other application).
>
> Best regards,
> Daniel
>

Hej,
Being a student of Geophysics, I regularly have to hand in some reports, for
which I'm doing a lot of plotting. I am using a latex-template of my own,
inserting the graphics from pdf. 
Now I am looking for a convenient way to set some defaults for the format of
plots I am using. I have created a module to easily set my default values
(square format, normal format, subplot-format, default colors, linestyles
etc.). The problem is, that there are some parameters I need to change with
every single plot command (like the space to annotate the axis in the small
subplots) because they are not accessible via matplotlibrc or rcParams. That
is some tedious work and not very convenient regarding the consistency of my
reports. 
So is there for example a way to set sth like 
axes([0.125,0.2,0.95-0.125,0.95-0.2])
or alike without the need to repeat it for every single plot?
Thank you very much in advance,
Calle
-- 
View this message in context: http://old.nabble.com/Setting-defaults-that-are-not-accessible-via-rcParams-tp31592659p31592659.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi Jae-Loon,
thanks for your comments! Of course I do agree that a figure layout
should not change in interactive mode. However, I don't see why this
should happen upon a panning action. A different case is when the
label or title font sizes are changed, but I was assuming this is
adjusted prior to the creation of the figure.
For the time being I am very happy with Tony's solution. It works nice
most of the time, only very complex figures take forever now to be
drawn.
The current behavior *looks* broken to any user who does not
understand the internals. And it's too likely that even simple figures
look horrible. I'd definitely vote for a more end-user friendly
solution (with end users I have scientific users in mind who generally
appreciate the beauty of the generated plots but who don't integrated
the library into some other application).
Best regards,
Daniel
2011年5月11日 Jae-Joon Lee <lee...@gm...>:
> On Fri, May 6, 2011 at 5:20 PM, Daniel Mader
> <dan...@go...> wrote:
>> From many postings here I have learned that
>> this is the absolute intention, i.e. it is broken by design unless the
>> programmer takes care about this.
>
> I think there are pros and cons, and I don't think the current design
> is simply broken.
> For example, it will be very distracting if the axes area changes
> while you're doing some interactive stuff (e.g., panning). Anyhow I
> admit that the default layout may not be optimal for figures with
> multiple subplots, and there is a room for improvement.
>
> There are a few approach you can take.
>
> * If you're only interested in saved outputs, you may use savefig
> with bbox_inches="tight". Note that this changes the size of figure.
>
> * Use Tony's script to adjust the subplot params automatically.
>
> * use axes_grid1 toolkit which enables you to change the axes
> position on the fly. Check
> http://www.mail-archive.com/mat...@li.../msg18743.html.
> For current git master branch, check
> examples/axes_grid/make_room_for_ylabel_using_axesgrid.py
>
> Regards,
>
> -JJ
>

On Fri, May 6, 2011 at 5:20 PM, Daniel Mader
<dan...@go...> wrote:
> From many postings here I have learned that
> this is the absolute intention, i.e. it is broken by design unless the
> programmer takes care about this.
I think there are pros and cons, and I don't think the current design
is simply broken.
For example, it will be very distracting if the axes area changes
while you're doing some interactive stuff (e.g., panning). Anyhow I
admit that the default layout may not be optimal for figures with
multiple subplots, and there is a room for improvement.
There are a few approach you can take.
 * If you're only interested in saved outputs, you may use savefig
with bbox_inches="tight". Note that this changes the size of figure.
 * Use Tony's script to adjust the subplot params automatically.
 * use axes_grid1 toolkit which enables you to change the axes
position on the fly. Check
http://www.mail-archive.com/mat...@li.../msg18743.html.
For current git master branch, check
examples/axes_grid/make_room_for_ylabel_using_axesgrid.py
Regards,
-JJ

I think I fixed a similar bug at some point but I'm not sure if that
is related with this.
Are you using the *make_axes_area_auto_adjustable* from the current
git master (check
examples/axes_grid/make_room_for_ylabel_using_axesgrid.py)? If not can
you try that? Also please post your code.
Regards,
-JJ
On Tue, May 10, 2011 at 3:06 AM, C M <cmp...@gm...> wrote:
> On Thu, Sep 30, 2010 at 7:55 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> On Thu, Sep 23, 2010 at 10:31 AM, C M <cmp...@gm...> wrote:
>>> Until a more permanent solution is figured out, can anyone recommend
>>> any workarounds, even if they are a little clunky? I'm embedding mpl
>>> plots in wxPython and am also finding this issue suboptimal.
>>>
>>> Che
>>>
>>
>> A (partial) workaround is possible using the axes_grid1 toolkit (i.e.,
>> you need matplotlib 1.0).
>> Attached is a module I just cooked up (based on my previous attempt @
>> http://www.mail-archive.com/mat...@li.../msg18129.html),
>> and it seems to work quite well.
>> The usage is simple.
>>
>>
>>    ax = plt.axes([0,0,1,1])
>>
>>    ax.set_yticks([0.5])
>>    ax.set_yticklabels(["very long label"])
>>
>>    make_axes_area_auto_adjustable(ax) # This is where axes_grid1 comes in
>>
>> Then, the axes area(including ticklabels and axis label) will be
>> automatically adjusted to fit in the given extent ([0, 0, 1, 1] in the
>> above case).
>>
>> While this is mainly for a single axes plot, you may use it with
>> multi-axes plot (but somewhat trickier to use). A few examples are
>> included in the module.
>>
>
> Although this has been a big improvement, there is a lingering issue
> that I want to get around to cleaning up now.
>
> When I use this workaround that Jae Joon provided, it works just fine
> except that if I call canvas.draw() (because I am adding a star to a
> particular marker when point picking), it causes the whole canvas to
> "jump" a little bit.
>
> What happens is that on the first call to .draw() the plot area
> increases vertically a tiny amount and the title moves up slightly.
> On subsequent calls, the plot surface doesn't increase vertically but
> the title text moves slightly up and then down quickly. This happens
> each time I point pick for the first 5 or so times, and then it stops
> doing it. I don't even have to add any new points to the plot, just
> call canvas.draw() and it will do this.
>
> It is visually distracting and a look and feel demerit for the app for sure.
>
> I've tried to make a sample that is not embedded in wxPython but so
> far I can't reproduce the problem.
>
> Jae Joon or anyone, any ideas about why this is occurring and how to
> prevent it? If need be I will try to work up a sample that
> demonstrates it, but so far I've failed in that.
>
> Thanks,
> Che
>