matplotlib-users Mailing List for matplotlib (Page 8)

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
>

On Tue, May 10, 2011 at 9:25 AM, Jonathan Slavin <js...@cf...>wrote:
> Hi,
>
> I would like to create a plot with a series of parallel 2-D slices in
> order to illustrate 3-D data. I got excited when I saw the example of
> translucent bar plots, which is similiar in some ways to what I had in
> mind. But it seems that there is no imshow method in Axes3D. How hard
> would that be to add? (By the way, I do know about mayavi and have used
> it, but there are things about it that make it somewhat difficult to
> work with.)
>
> Jon
>
imshow() and friends work a little bit differently from the other plotting
commands. Unlike the other plotting functions, imshow() does not return any
Collection objects, rather it returns an AxesImage object. Most of the
other functions are merely wrappers around their 2D equivalent with a few
extra keyword arguments and a 2D to 3D converter call for the collection
objects returned. In order to support imshow() in Axes3D, a 3D version of
the AxesImage object will need to be made and should be able to be created
from an existing 2D version.
If someone wants to create a 3D version of AxesImage and add it to art3d.py,
I would be more than happy to take the patch. But at this time, I am too
unfamiliar with AxesImage objects and am more focused on fixing the current
feature-set.
Ben Root

Hi,
I would like to create a plot with a series of parallel 2-D slices in
order to illustrate 3-D data. I got excited when I saw the example of
translucent bar plots, which is similiar in some ways to what I had in
mind. But it seems that there is no imshow method in Axes3D. How hard
would that be to add? (By the way, I do know about mayavi and have used
it, but there are things about it that make it somewhat difficult to
work with.)
Jon
-- 
______________________________________________________________
Jonathan D. Slavin Harvard-Smithsonian CfA
js...@cf... 60 Garden Street, MS 83
phone: (617) 496-7981 Cambridge, MA 02138-1516
 cell: (781) 363-0035 USA
______________________________________________________________

Hi, I like this, too.
However, I don't understand why it works at all. Usually, when I apply
a colormap, I need to take care about the scaling myself, i.e. divide
the range up into the number of elements to plot:
import pylab as pl
import matplotlib.cm as cm
xval = pl.arange(0, 20, 0.2)
n = 256
for i in range(n):
# pl.plot(xval, pl.sin(xval)+i, c=cm.hot(i), lw=5)
 pl.plot(xval, pl.sin(xval)+i, c=cm.hot(1.*i/n), lw=5)
Can anyone tell me why this is not necessary here but essential for
example here:
for i,infile in enumerate(infiles):
 ## title for plot
 tname = os.path.splitext(infile)[0]
 ## read data
 f = FileHelpers.BlockedFile(infile)
 alldata = scipy.array([[],[]])
 for ii in ['+', '2', 'x', '1']: # use for markers, too
# for ii in [4,3,2,1]: # use for markers, too
 try:
 f.next_block()
 data = scipy.loadtxt(f).T
 alldata = scipy.concatenate((alldata, data), axis=1)
# ax.plot(data[0],data[1], '%s'%ii,
color=cm.hot(1.*i/len(infiles)), mew=1.5 )
 ax.plot(data[0],data[1], '%s'%ii, c=cm.hot(i), mew=1.5 )
 except Exception, e:
 print e
 break
Thanks in advance,
Daniel
>> I have found a simple and better way. One can chose from colors from a
>> color
>> map:
>>
>> >>import pylab as pl
>> >>import matplotlib.cm as cm
>> >>xval = pl.arange(0, 20, 0.2)
>> >>for i in range(256):
>>   ... pl.plot(xval, pl.sin(xval)+i, c=cm.hot(i), lw=5)
>>
>> This one if, for instance, picking from a color map called "hot". If one
>> wants to the colors to fade away, or darken, the "alpha" option can be
>> utilized or another color map in which colors darken or fade into another
>> color.
>>
>> There is no need for a long sophisticated script.

On Mon, May 9, 2011 at 5:11 PM, Pythonified <net...@gm...>wrote:
>
>
> Pythonified wrote:
> >
> > I have been trying to assign different colors for each line I plot, where
> > the colors are incrementally darkened (or lightened), or selected from a
> > colorbar (e.g. rainbow).
> >
> > Any ideas?
> >
>
> I have found a simple and better way. One can chose from colors from a
> color
> map:
>
> >>import pylab as pl
> >>import matplotlib.cm as cm
> >>xval = pl.arange(0, 20, 0.2)
> >>for i in range(256):
> ... pl.plot(xval, pl.sin(xval)+i, c=cm.hot(i), lw=5)
>
> This one if, for instance, picking from a color map called "hot". If one
> wants to the colors to fade away, or darken, the "alpha" option can be
> utilized or another color map in which colors darken or fade into another
> color.
>
> There is no need for a long sophisticated script.
>
> Enjoy,
> Pythonified
>
Nice trick. This can go into the gallery or somewhere else in scipy
cookbook.
-- 
Gökhan

Pythonified wrote:
> 
> I have been trying to assign different colors for each line I plot, where
> the colors are incrementally darkened (or lightened), or selected from a
> colorbar (e.g. rainbow).
> 
> Any ideas?
> 
I have found a simple and better way. One can chose from colors from a color
map:
>>import pylab as pl
>>import matplotlib.cm as cm
>>xval = pl.arange(0, 20, 0.2)
>>for i in range(256):
 ... pl.plot(xval, pl.sin(xval)+i, c=cm.hot(i), lw=5)
This one if, for instance, picking from a color map called "hot". If one
wants to the colors to fade away, or darken, the "alpha" option can be
utilized or another color map in which colors darken or fade into another
color.
There is no need for a long sophisticated script.
Enjoy,
Pythonified
-- 
View this message in context: http://old.nabble.com/incremental-colors-for-lines-tp31546719p31581404.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

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

Hello Eric,
Thanks to you, the problem is resolved! 
> No, I don't think this is a bug in matplotlib; there are many mpl users, 
> and at least to some extent some devs, who use Macs, so if this were a 
> general bug in 1.0.1 it would have turned up long ago. 
Since you were convinced that mpl is not buggy, I decided to look at EPD. However, before that, and for the record, yes, I did try running your commands by saving them to a file and by invoking 
$Python foo.py 
in my bash shell (where Python was the 64-bit python or path to the 32-bit python). This still caused the crashes, and may not have helped in locating the actual snag.
> Similarly, I doubt it is the case that EPD is simply broken. I would be surprised if 
> Enthought did not test EPD versions prior to release! 
There is a very recent thread in epd-users that is similar in flavor to my problem https://mail.enthought.com/pipermail/epd-users/2011-May/000379.html. As in that thread, I too had my DYLD_LIBRARY_PATH set to something in .profile, in my case simply /usr/local/lib. I do not know whether I set it (possibly for CVXOPT to work) or whether an earlier version of EPD installer or some other installer added it. In any case, not having it defined solved my problem (at least this one; don't know if it would break something else though!).
By the way, I know that this particular environment variable has been around in my .profile for quite some time now, so I suspect that something changed in EPD 7.0-2 that causes the trouble (does not appear evident from their change log though). Again, for the record, less than three weeks ago, on EPD 7.0-1, everything was working smoothly. Also, I shall bring this discussion to the attention of those in the epd-users' thread. 
Thanks again! 
-Kaushik

On 05/08/2011 11:42 AM, Kaushik Kalyanaraman wrote:
> Hello Eric,
>
> Thanks for your reply and suggestions!
>
>> Do you see the problem with any plot at all? E.g.,
> <snip>
>> Can you eliminate all traces of EPD, and then just cleanly install one version, and see if the problem still appears?
>
> I cleanly installed EPD. Now, with only a single version (EPD 7.0-2, Python 2.7.1), I find that, interestingly,
>
> a) In the 32-bit version (both when independent of and concurrent with 64-bit EPD), simply calling plot() crashes Python, both in bash and IPython shells.
> b) In the 64-bit version, plot() goes through and creates the correct plot window but savefig() causes a crash when attempting to save in any format (pdf, ps, svg, png).
>
> As in my original mail the error messages echoed to terminal are "Abort trap" and "Bus error" for 64-bit and 32-bit versions, respectively.
>
> Thus, I wish to believe that there is some bug in matplotlib which is possibly not local to savefig() alone (at least for the 32-bit version). In this regard, I wish to request you as well as list members to advise me as to whether I should use version 1.0.0 ? If so, should I build from source or can I simply use the disk image file (and have it easy!) if I wish to replace the EPD bundled matplotlib ?
>
No, I don't think this is a bug in matplotlib; there are many mpl users, 
and at least to some extent some devs, who use Macs, so if this were a 
general bug in 1.0.1 it would have turned up long ago. Similarly, I 
doubt it is the case that EPD is simply broken. I would be surprised if 
Enthought did not test EPD versions prior to release! Most likely there 
is something out of the ordinary about your particular system that is 
causing the problem; there is still a version conflict or corrupted file 
somewhere.
Did you try saving the code snippet in my last message to a file, and 
running it? The point of it was to eliminate the use of an interactive 
backend.
I don't have any more ideas; maybe someone else can suggest the next 
troubleshooting steps.
Eric
> Thanks and Regards,
> Kaushik
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello Eric,
Thanks for your reply and suggestions!
> Do you see the problem with any plot at all? E.g.,
<snip>
> Can you eliminate all traces of EPD, and then just cleanly install one version, and see if the problem still appears?
I cleanly installed EPD. Now, with only a single version (EPD 7.0-2, Python 2.7.1), I find that, interestingly,
a) In the 32-bit version (both when independent of and concurrent with 64-bit EPD), simply calling plot() crashes Python, both in bash and IPython shells.
b) In the 64-bit version, plot() goes through and creates the correct plot window but savefig() causes a crash when attempting to save in any format (pdf, ps, svg, png).
As in my original mail the error messages echoed to terminal are "Abort trap" and "Bus error" for 64-bit and 32-bit versions, respectively.
Thus, I wish to believe that there is some bug in matplotlib which is possibly not local to savefig() alone (at least for the 32-bit version). In this regard, I wish to request you as well as list members to advise me as to whether I should use version 1.0.0 ? If so, should I build from source or can I simply use the disk image file (and have it easy!) if I wish to replace the EPD bundled matplotlib ?
Thanks and Regards,
Kaushik

On 05/08/2011 08:58 AM, Kaushik Kalyanaraman wrote:
> Dear List,
>
> I use Matplotlib bundled with the Enthought Python Distribution (EPD) (both 32-bit and 64-bit versions). After a recent update, I find that my Python code (run either in a iPython shell or in bash shell) crashes while attempting to save figures to pdf files using savefig(). However, saving to other formats (png, ps, eps or svg) works fine. The error message echoed to the terminal are "Bus error" with 32-bit EPD and "Abort trap" with 64-bit EPD. Also, converting to pdf from one of the other four formats using *nix utilities like convert or ps2pdf go through fine (prompting to suspect that savefig has a bug). Unfortunately, in a short time, by looking at pyplot.py, I couldn't determine what could be causing this. Therefore, it would be really helpful if list members can provide any hints to fix this. I need to save a bunch of figures from existing code, and it would be great if I could do so without having to modify all savefig statements; additionally, I would prefer not to 
wr
> ite a shell script to perform the conversions to pdf considering the different directories that my figures are saved to.
>
> Also, a few searches using google did not throw up anything useful (although one relevant list archive suggested that if EPD alone is installed on a Mac, this error shouldn't be seen. Since this is the case for me, it didn't help.). The following are my specifications:
>
> Platform: Mac OS X 10.6.7
> Python version: 2.7.1
> Matplotlib version: 1.0.1
> EPD versions: 7.0-2 (both 32-bit and 64-bit)
>
> (Should I also post this to matplotlib-devel ?)
Probably not necessary; I think most of us on -devel read -users, and 
other people on -users may have useful insight and testing to contribute.
The pdf backend is not that different from the ps and svg backends, at 
least superficially--all of them are just python code that write 
files--so it is not obvious why it would cause the sort of problem that 
is usually associated with broken extension code.
Do you see the problem with any plot at all? E.g.,
import matplotlib
matplotlib.use("pdf")
import matplotlib.pyplot as plt
plt.plot([1,2])
plt.savefig("test.pdf")
My guess is that somehow something is getting confused between the two 
EPD versions, or something got confused during the update.
Can you eliminate all traces of EPD, and then just cleanly install one 
version, and see if the problem still appears?
Eric
>
> Thanks and Regards,
> Kaushik Kalyanaraman
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today. Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Dear List,
I use Matplotlib bundled with the Enthought Python Distribution (EPD) (both 32-bit and 64-bit versions). After a recent update, I find that my Python code (run either in a iPython shell or in bash shell) crashes while attempting to save figures to pdf files using savefig(). However, saving to other formats (png, ps, eps or svg) works fine. The error message echoed to the terminal are "Bus error" with 32-bit EPD and "Abort trap" with 64-bit EPD. Also, converting to pdf from one of the other four formats using *nix utilities like convert or ps2pdf go through fine (prompting to suspect that savefig has a bug). Unfortunately, in a short time, by looking at pyplot.py, I couldn't determine what could be causing this. Therefore, it would be really helpful if list members can provide any hints to fix this. I need to save a bunch of figures from existing code, and it would be great if I could do so without having to modify all savefig statements; additionally, I would prefer not to write a shell script to perform the conversions to pdf considering the different directories that my figures are saved to.
Also, a few searches using google did not throw up anything useful (although one relevant list archive suggested that if EPD alone is installed on a Mac, this error shouldn't be seen. Since this is the case for me, it didn't help.). The following are my specifications:
Platform: Mac OS X 10.6.7
Python version: 2.7.1
Matplotlib version: 1.0.1
EPD versions: 7.0-2 (both 32-bit and 64-bit)
(Should I also post this to matplotlib-devel ?)
Thanks and Regards,
Kaushik Kalyanaraman

On Sat, May 7, 2011 at 3:34 PM, Ondrej Certik <on...@ce...> wrote:
> Hi,
>
> I am using Matplotlib 1.0 precisely from this branch:
>
> https://github.com/matplotlib/matplotlib/tree/v1.0.x
>
> everything works on Linux, and on Mac, I am getting a segfault when I
> do "import pylab". Stacktrace is here:
>
> https://gist.github.com/960896
>
> I produced it by:
>
> gdb python
> (gdb) run
>>>> import pylab
>
> So it looks like TTF related. Here are some relevant links:
>
> https://github.com/qsnake/qsnake/issues/9
> http://trac.sagemath.org/sage_trac/ticket/7022
>
> I have tried to copy ontList.cache (from the Sage ticket 7022) in to
> ~/.qsnake/matplotlib/, but it still segfaults.
>
> Would anyone know what exactly the problem is, and how to fix it? I
> have numpy 1.6.0. Let me know which other debugging information is
> needed.
Min has solved it --- the problem was in using incorrect options to
build the package. Now we use the make.osx to set the environment
flags correctly and everything works now.
I have no idea what the problem was, but it's gone.
Ondrej

Hi,
I am using Matplotlib 1.0 precisely from this branch:
https://github.com/matplotlib/matplotlib/tree/v1.0.x
everything works on Linux, and on Mac, I am getting a segfault when I
do "import pylab". Stacktrace is here:
https://gist.github.com/960896
I produced it by:
gdb python
(gdb) run
>>> import pylab
So it looks like TTF related. Here are some relevant links:
https://github.com/qsnake/qsnake/issues/9
http://trac.sagemath.org/sage_trac/ticket/7022
I have tried to copy ontList.cache (from the Sage ticket 7022) in to
~/.qsnake/matplotlib/, but it still segfaults.
Would anyone know what exactly the problem is, and how to fix it? I
have numpy 1.6.0. Let me know which other debugging information is
needed.
Thanks,
Ondrej

> On 5/6/2011 7:57 AM, Vikram K wrote:
>> I wish to draw a Venn diagram depicting five events and
>> their intersections.
On 5/6/2011 8:07 AM, Alan G Isaac wrote:
> Can't be done:
> http://www.brynmawr.edu/math/people/anmyers/PAPERS/Venn.pdf
More precisely: it cannot be done with circles.
Cheers,
Alan Isaac

Hello,
Anyone on the list works with radar and/or lidar data for atmospheric
phenomenon visualisation? I am wondering if there is any 2D specific
analysis and visualisation package out in the web.
Thanks.
-- 
Gökhan

Dear List,
I use Matplotlib bundled with the Enthought Python Distribution (EPD) (both 32-bit and 64-bit versions). After a recent update, I find that my Python code (run either in a iPython shell or in bash shell) crashes while attempting to save figures to pdf files using savefig(). However, saving to other formats (png, ps, eps or svg) works fine. The error message echoed to the terminal are "Bus error" with 32-bit EPD and "Abort trap" with 64-bit EPD. Also, converting to pdf from one of the other four formats using *nix utilities like convert or ps2pdf go through fine (prompting to suspect that savefig has a bug). Unfortunately, in a short time, by looking at pyplot.py, I couldn't determine what could be causing this. Therefore, it would be really helpful if list members can provide any hints to fix this. I need to save a bunch of figures from existing code, and it would be great if I could do so without having to modify all savefig statements; additionally, I would prefer not to write a shell script to perform the conversions to pdf considering the different directories that my figures are saved to.
Also, a few searches using google did not throw up anything useful (although one relevant list archive suggested that if EPD alone is installed on a Mac, this error shouldn't be seen. Since this is the case for me, it didn't help.). The following are my specifications:
Platform: Mac OS X 10.6.7
Python version: 2.7.1
Matplotlib version: 1.0.1
EPD versions: 7.0-2 (both 32-bit and 64-bit)
(Should I also post this to matplotlib-devel ?)
Thanks and Regards,
Kaushik Kalyanaraman

Hello,
I am trying to embed a dynamic figure within a GUI generated WX 
interface but it only displays the last evaluation. I have tried 
embedding the animated examples as provided by the animated link, 
www.scipy.org/Cookbook/Matplotlib/Animations but it only shows the last 
result in the frame. When calling these example outside the GUI, they 
produce the dynamic visualizations and expected.
Can anyone provide me with guidance in generalizing the animated 
examples within embedded GUIs.
Thanks
Steve

On Fri, May 6, 2011 at 10:33 AM, Benjamin Root <ben...@ou...> wrote:
> On Thu, May 5, 2011 at 10:01 PM, C M <cmp...@gm...> wrote:
>>
>> > Because you have a py2exe'ed program, I suspect that whoever packaged
>> > the
>> > program should be the one to modify that program to choose its axes
>> > limits
>> > more robustly in order to avoid the warning message.
>>
>> Maybe I have been unclear. I am the sole developer of this
>> application, and I occasionally test it as a py2exe'd app in
>> anticipation of delivering it in that form at some point. I would be
>> happy to modify the program to choose its axes limits more
>> robustly--if I only knew how to do that. That is what I am asking.
>> How should I do that?
>>
>> The data to be plotted is a very simple date plot with dates on the x
>> axis and values (formatted as time) on the y axis.
>>
>> Che
>
> Most likely, somewhere in your code, you have a call to set_ylim(), and are
> likely setting it to the minimum and maximum values of the data you are
> plotting. This is where the problem comes in. There are several options to
> go about avoiding the problem here. One is to not call set_ylim() at all if
> you have only one data point, and just let matplotlib figure out the
> y-limits automatically. Another approach is to call set_ylim() with
> parameters that have an explicit amount of padding, like the following:
>
> ax.set_ylim(y.min() - 0.5, y.max() + 0.5)
>
> This way, you are guaranteed that the top and bottom limits will never be
> the same. The best approach is up to you.
>
> I hope that helps!
> Ben Root
Thank you, Ben! That helps a lot. Adding some padding myself seems
to fix it. And it's good to understand what was occurring.
-Che

(Sorry for sending this twice, Pythonified, but I forgot to copy the list)
On Wed, May 4, 2011 at 9:51 PM, Pythonified <net...@gm...>wrote:
> I have been trying to assign different colors for each line I plot, where
> the colors are incrementally darkened (or lightened), or selected from a
> colorbar (e.g. rainbow). Any ideas?
>
I posted some code awhile back to do what you're looking for (see:
http://old.nabble.com/Where-to-post-examples-%28specifically,-one-that-may-be-useful-for-time-evolution-plots%29-td23901837.html
).
I'm copying the code below again because it's evolved a bit (I really need
to start posting code to github). Anyway, if you copy the attached code to a
module, you should be able to call the "cycle_cmap" function to change the
cmap globally, or the "cycle_cmap_axes" function to create an axes with the
specified cmap.
Best,
-Tony
#---- start of code
import matplotlib.pyplot as plt
import numpy as np
# reverse these colormaps so that it goes from light to dark
REVERSE_CMAP = ['summer', 'autumn', 'winter', 'spring', 'copper']
# clip some colormaps so the colors aren't too light
CMAP_RANGE = dict(gray={'start':200, 'stop':0},
 Blues={'start':60, 'stop':255},
 Oranges={'start':100, 'stop':255},
 OrRd={'start':60, 'stop':255},
 BuGn={'start':60, 'stop':255},
 PuRd={'start':60, 'stop':255},
 YlGn={'start':60, 'stop':255},
 YlGnBu={'start':60, 'stop':255},
 YlOrBr={'start':60, 'stop':255},
 YlOrRd={'start':60, 'stop':255},
 hot={'start':230, 'stop':0},
 bone={'start':200, 'stop':0},
 pink={'start':160, 'stop':0})
def cmap_intervals(length=50, cmap='YlOrBr', start=None, stop=None):
 """Return evenly spaced intervals of a given colormap `cmap`.
 Colormaps listed in REVERSE_CMAP will be cycled in reverse order.
Certain
 colormaps have pre-specified color ranges in CMAP_RANGE. These module
 variables ensure that colors cycle from light to dark and light colors
are
 not too close to white.
 Parameters
 ----------
 length : int
 the number of colors used before cycling back to first color. When
 `length` is large (> ~10), it is difficult to distinguish between
 successive lines because successive colors are very similar.
 cmap : str
 name of a matplotlib colormap (see matplotlib.pyplot.cm)
 """
 cm = getattr(plt.cm, cmap)
 crange = CMAP_RANGE.get(cmap, dict(start=0, stop=255))
 if cmap in REVERSE_CMAP:
 crange = dict(start=crange['stop'], stop=crange['start'])
 if start is not None:
 crange['start'] = start
 if stop is not None:
 crange['stop'] = stop
 if length > abs(crange['start'] - crange['stop']):
 print ('Warning: the input length is greater than the number of ' +
 'colors in the colormap; some colors will be repeated')
 idx = np.linspace(crange['start'], crange['stop'], length).astype(np.int
)
 return cm(idx)
def cycle_cmap(length=50, cmap='YlOrBr', start=None, stop=None):
 """Set default color cycle of matplotlib to a given colormap `cmap`.
 The default color cycle of matplotlib is set to evenly distribute colors
in
 color cycle over specified colormap.
 Note: this function must be called before *any* plot commands because it
 changes the default color cycle.
 See ``cmap_intervals`` for input details.
 """
 color_cycle = cmap_intervals(length, cmap, start, stop)
 # set_default_color_cycle doesn't play nice with numpy arrays
 plt.rc('axes', color_cycle=color_cycle.tolist())
def cycle_cmap_axes(length=50, cmap='YlOrBr', start=None, stop=None):
 """Return axes with color cycle set to a given colormap `cmap`.
 The color cycle of the axes is set to evenly distribute colors in color
 cycle over specified colormap.
 See ``cmap_intervals`` for input details.
 """
 color_cycle = cmap_intervals(length, cmap, start, stop)
 # set_default_color_cycle doesn't play nice with numpy arrays
 ax = plt.gca()
 ax.set_color_cycle(color_cycle)
 return ax
if __name__ == '__main__':
 n_lines = 10
 x = np.linspace(0, n_lines)
 # change the global cmap
 cycle_cmap(n_lines, 'Oranges')
 for shift in np.linspace(0, np.pi, n_lines):
 plt.plot(x, np.sin(x - shift))
 plt.figure()
 # create an axes that is set to desired cmap
 ax = cycle_cmap_axes(n_lines, 'Blues')
 for shift in np.linspace(0, np.pi, n_lines):
 ax.plot(x, np.sin(x - shift))
 plt.show()