matplotlib-users Mailing List for matplotlib

On Tue, Nov 9, 2010 at 4:33 PM, Garry Willgoose
<Gar...@ne...> wrote:
> I'm using the following code to plot some grided data
>
>    fig1=pylab.figure()
>    contents1=fig1.add_subplot(111)
>    stuff=contents1.imshow(mydata,origin='lower',aspect='equal')
>
> and I find that if I launch the code with 'ipython' the data looks as expected but if I use 'python' then the x-axis annotations are OK but the data is still plotted with the origin in the top left hand corner. I'm using the enthought 6.1 distribution and the version of matplotlib and pylab imported in both cases is the same. I guess one indicator of a major difference is that ipython has the icon bar for the plot at the bottom of the screen but python has the icon bar at the top of the screen. Any clues ... I'd happily just use ipython but I distribute the code to others so I'd like to get it sorted.
Sounds like a backend problem (see
http://matplotlib.sourceforge.net/faq/installing_faq.html#what-is-a-backend
and http://matplotlib.sourceforge.net/users/customizing.html)
First thing you'll want to do is put
import matplotlib
print matplotlib.rcParams['backend']
at the top of your script and run it in both environments and report
what you find. My guess is one of the environments has a backend that
does not support the image origin argument.
JDH

I'm using the following code to plot some grided data
 fig1=pylab.figure()
 contents1=fig1.add_subplot(111)
 stuff=contents1.imshow(mydata,origin='lower',aspect='equal')
and I find that if I launch the code with 'ipython' the data looks as expected but if I use 'python' then the x-axis annotations are OK but the data is still plotted with the origin in the top left hand corner. I'm using the enthought 6.1 distribution and the version of matplotlib and pylab imported in both cases is the same. I guess one indicator of a major difference is that ipython has the icon bar for the plot at the bottom of the screen but python has the icon bar at the top of the screen. Any clues ... I'd happily just use ipython but I distribute the code to others so I'd like to get it sorted.

Hello ExPyrts; 
I'm trying to do a fill-between part of a spectrum and its continuum
value. I would strongly prefer the drawstyle to be steps, since each
data point represents a bin (or pixel, to be precise).
Attached is a picture illustrating my problem.
Isn't it possible to fill between my step graph and the hline?
Cheers; 
Emil

On 11/9/10 9:21 AM, Benjamin Root wrote:
> I just tested out the patch, and while it did seem to fix the problem for me
> on the test script, I am not 100% certain that it is properly lined up
> (maybe an off-by-one-pixel error?). Anyway, I tried zooming in to see which
> kind of error it was and I got a very weird image. I am not certain exactly
> what triggers it, but I think if the rubber-banding does not incorporate the
> entire arrow-head, then the distortion appears. I was also able to
> reproduce the distortion without the patch (although I think it was easier
> to cause with the patch).
If it looks like an off-by-one pixel error, make sure you are doing:
import matplotlib
matplotlib.rcParams['path.snap'] = False
to turn off the pixel-snapping that happens with horizontal and vertical 
lines in png images, or make sure you are seeing the off-by-one in a 
vector graphic format like pdf. For me, saving a pdf with the slanted 
line a linewidth of .01 showed that the arrow is right on it now.
I did notice one thing that did seem a little off, though. I see that 
the tip of the arrow just barely projects over the corner of the box. 
The arrow is supposed to go to (1,1), and the linewidth is 30, so I'm 
thinking that the miter join should project a long ways over the box 
(because the centers of the lines are at (1,1), and the line width is 
very large). If I change the path_effects argument to:
path_effects=[Stroke(joinstyle='miter'),Stroke(linewidth=1,foreground='w',joinstyle='miter')]
so that I see more clearly where the actual line center is, it appears 
that the line center is far off of (1,1). I guess at this point, I'm 
confused about how the arrow is supposed to be representing the segment 
between (0,0) and (1,1). Is the tip of the arrow (after the miter join) 
supposed to hit (1,1), or is the center of the line supposed to hit 
(1,1)? Or maybe the tip of the joinstyle='round' arrow (the default) is 
supposed to hit (1,1)?
I noticed this bug when I was trying to figure out a way to have the 
actual drawn arrow end at a specific point (maybe using miter join, so 
that we had a sharp arrow) for Sage. It would be nice if there was some 
sort of option that would do the math to shorten the arrow by the 
necessary amount. Of course, if that's not an option, I could do that 
math myself in Sage's "arrow" wrapper command.
Thanks,
Jason

Finally figured it out after pulling some hear.
Using "axes.annotate" instead of "axes.text" worked for me, i.e. 
something like this:
axes.annotate(hstr, xy=(xCorr, yCorr), xytext=(0, 5), textcoords='offset 
points')
instead of what I did originally.
Werner
On 08/11/2010 16:21, Werner F. Bruhin wrote:
> I like to have 2 or 3 text elements "stacked" on top of each other on
> top of a bar.
>
> Currently it works for the first text element by doing:
>
> height = bar.get_height()
> xCorr = bar.get_x()
> yCorr = 0.20 + height
>
> txtax = axes.text(xCorr, yCorr, hstr)
>
> trying to add the second text just above the previous one I tried this:
>
> pCorr = yCorr + txtax.get_size() + 0.4
> txtax = axes.text(xCorr, pCorr, hstrPerc)
>
> It looks like my problem is that get_x() returns a value in ticks and
> txtax.get_size() is in pixels and I can't find a way to get at the
> height of the text element in ticks.
>
> Can anyone please push me in the right direction.
>
> Werner
>
>
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I've been trying to track down a problem in the arrows where the arrow 
seems to be off by a little bit. I've narrowed down the problem to a 
small example:
import matplotlib.patches as mpatches
import matplotlib.pyplot as plt
fig=plt.figure()
ax = fig.add_subplot(111, xlim=(.98,1.02), ylim=(.98,1.02),aspect='equal')
from matplotlib.patheffects import Stroke
ax.annotate('', (1,1),
 (0,0),
 arrowprops=dict(arrowstyle="-|>",
 fc="w", ec="k",lw=30,
 path_effects=[Stroke(joinstyle='miter')]),)
ax.plot([0,1],[1,1])
ax.plot([1,1],[0,1])
ax.plot([0,1.02],[0,1.02])
fig.savefig('test.png')
I've used a miter join above because it illustrates the problem better. 
 Notice that the arrowhead tip is just below the line, but should be 
right on the line. Any clue about what the problem is?
Thanks,
Jason
--
Jason Grout

On Sat, Oct 30, 2010 at 2:16 PM, Paul Ivanov <piv...@gm...> wrote:
>> Thanks Paul! Your suggestion got me part of the way, but I've run
>> into another problem...I'm using draggable legends, I'm also wanting
>> to fetch the current position of the legend after a drag. The
>> draggable legend always updates 'loc', and not 'bbox_to_anchor', so
>> I'm afraid that I'm stuck manipulating 'loc' for my purposes and not
>> the bbox_to_anchor property.
>
>From svn r8784, you can optionally make legend to update
bbox_to_anchor parameter (and leave *loc* untouched) when dragged.
d = my_legend.draggable(update="bbox")
The default is to update *loc*.
Regards,
-JJ

Honestly, I can't even remember why it is wrapped. I think this is just a
relic of some old example that I had lying around. Serves me right for just
copying and pasting without thinking :P . A straight call to
itertools.cycle is definitely much cleaner. Also, is there an example of
this in the docs? If not, it would be a useful addition. Seems like a
common feature to address.
Cheers,
Aman
On Mon, Nov 8, 2010 at 10:41 PM, Ryan May <rm...@gm...> wrote:
> On Fri, Nov 5, 2010 at 8:07 AM, Aman Thakral <ama...@gm...>
> wrote:
> > Hi,
> >
> > The best way to do this is to use a generator:
> >
> > import itertools
> > import matplotlib.pyplot as plt
> > import numpy as np
> >
> > def _ncycle(iterable,n):
> > """
> > Method to create a generator from an iterable. It keeps the
> > current position of the iterable in memory. Each time the
> > next() method for the iterable is called, it will return the
> > next item. If there are no more items, it will cycle to the
> > first item.
> > """
> >
> > for item in itertools.cycle(iterable):
> > yield item
> >
> > colors = _ncycle(('r','g','b','c','y','m','k'),1)
> > markers = _ncycle(('o','s','v'),1)
>
> I like the thought, but I'm not sure why you're making it so
> complicated by wrapping it. itertools.cycle by itself is perfect, and
> there's no reason to prime it by calling next() before the plot. The
> following is a bit more succint IMO:
>
> import itertools
> import matplotlib.pyplot as plt
> import numpy as np
>
> colors = itertools.cycle(['r','g','b','c','y','m','k'])
> markers = itertools.cycle(['o','s','v'])
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> for i in range(10):
> x = np.linspace(0, 2*np.pi)
> y = np.sin(x) + np.random.randn(*x.shape)
> ax.plot(x, y, c=colors.next(), marker=markers.next())
>
> plt.show()
>
> Also, you can avoid calling colors.next() and markers.next() if you
> put them in a zip command along with range().
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>

On Fri, Nov 5, 2010 at 8:07 AM, Aman Thakral <ama...@gm...> wrote:
> Hi,
>
> The best way to do this is to use a generator:
>
> import itertools
> import matplotlib.pyplot as plt
> import numpy as np
>
> def _ncycle(iterable,n):
>   """
>   Method to create a generator from an iterable. It keeps the
>   current position of the iterable in memory. Each time the
>   next() method for the iterable is called, it will return the
>   next item. If there are no more items, it will cycle to the
>   first item.
>   """
>
>   for item in itertools.cycle(iterable):
>     yield item
>
> colors = _ncycle(('r','g','b','c','y','m','k'),1)
> markers = _ncycle(('o','s','v'),1)
I like the thought, but I'm not sure why you're making it so
complicated by wrapping it. itertools.cycle by itself is perfect, and
there's no reason to prime it by calling next() before the plot. The
following is a bit more succint IMO:
import itertools
import matplotlib.pyplot as plt
import numpy as np
colors = itertools.cycle(['r','g','b','c','y','m','k'])
markers = itertools.cycle(['o','s','v'])
fig = plt.figure()
ax = fig.add_subplot(111)
for i in range(10):
 x = np.linspace(0, 2*np.pi)
 y = np.sin(x) + np.random.randn(*x.shape)
 ax.plot(x, y, c=colors.next(), marker=markers.next())
plt.show()
Also, you can avoid calling colors.next() and markers.next() if you
put them in a zip command along with range().
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

>
> How can I automatically cycle through distinctive line markers?
>>
>> I want a semilog plot, composed of a number of lines. Each line should
>> have
>> a different color and marker.
>
>
I simply use:
colors = ['b', 'r', 'c', 'm', 'k', 'g', 'y']
symbols = ['-', '--', '-.', ':']
nc = len(colors)
ns = len(symbols)
cs = 0
cc = 0
for i in numpy.arange(len(parameters_list)):
 plt.plot(x, y, colors[cc%nc] + symbols[cs%ns], label=r'$\Delta x_{min} =
' + str(dxmin[j]) + ', N = ' + str(Ns[i]) + r'$')
 cc += 1
 if (cc == nc):
 cc = 0
 cs += 1
This will cycle through symbols when colors run out. You can indent or not
"cs" to cycle through symbols too.

On Tue, Nov 9, 2010 at 12:21 AM, Werner F. Bruhin <wer...@fr...> wrote:
> I like to have 2 or 3 text elements "stacked" on top of each other on
> top of a bar.
>
> Currently it works for the first text element by doing:
>
> height = bar.get_height()
> xCorr = bar.get_x()
> yCorr = 0.20 + height
>
> txtax = axes.text(xCorr, yCorr, hstr)
>
> trying to add the second text just above the previous one I tried this:
>
> pCorr = yCorr + txtax.get_size() + 0.4
> txtax = axes.text(xCorr, pCorr, hstrPerc)
>
I recommend you to use "annotate".
http://matplotlib.sourceforge.net/api/pyplot_api.html?highlight=annotate#matplotlib.pyplot.annotate
you may begin with something like below.
txt=plt.text(0.5, 0.5, "Test1")
plt.annotate("My Test2",
 xy=(0.5, 1.), xycoords=txt,
 xytext=(0, 5), textcoords="offset points",
 ha="center", va="bottom")
See belows for more details.
http://matplotlib.sourceforge.net/users/annotations_guide.html#using-complex-coordinate-with-annotation
http://matplotlib.sourceforge.net/users/annotations_guide.html#using-complex-coordinate-with-annotation
-JJ
> It looks like my problem is that get_x() returns a value in ticks and
> txtax.get_size() is in pixels and I can't find a way to get at the
> height of the text element in ticks.
>
> Can anyone please push me in the right direction.
>
> Werner
>
>
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>