matplotlib-users Mailing List for matplotlib (Page 9)

I'm trying to use mplot3d in a Wx based application, and most things seem to
be working fine.  The one issue that keeps tripping me up is that the axes
labels are drawn at a weird angle.  If I do the same type of plot without
using wx, then this problem goes away.  I am completely stumped as to where
to even begin looking to fix this problem, so I would appreciate any
pointers you can give me.

I've attached a screenshot showing what I am talking about - a simple plot
where the axes labels look strange.


http://old.nabble.com/file/p30184616/mplot3d.jpg 
-- 
View this message in context: http://old.nabble.com/Axes-labels-crooked-using-mplot3d-in-WX-tp30184616p30184616.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks! Alas, this raises a NotImplementedError and although I'm still
running version 0.99 of mpl, it seems like this is not yet implemented
in the 'errorbar'-function to handle this - or am I mistaken?

I won't find the time to implement this.

Anyway, thanks again for your help. It would have been nice, but I can
live without it.

Christian

I won't find the time to implement this. 

On Wed, 2010-11-10 at 09:18 -0600, Benjamin Root wrote:
> On Wed, Nov 10, 2010 at 7:44 AM, Christian Meesters
> <mee...@im...> wrote:
>         Hi,
>         
>         Honestly, I neglected my mpl skills lately, so I don't know
>         whether docs
>         on this topic are available, but I couldn't find them either.
>         
>         I would like to create a forest plot using horizontal
>         errorbars.
>         Currently my marker is simply 'kd' in pylab.errorbar, where
>         'd' is
>         similar to LaTeX's \blacklozenge.
>         
>         Is there a way to rotate the marker such that long cross
>         section is
>         horizontal (rotation by 90 degree) and not vertical anymore?
>         
>         TIA
>         Christian
>         
>         
> 
> Christian,
> 
> Looking through the code for drawing the "thin diamond", I think you
> might be able to get what you want by specifying the fillstyle.  It
> appears that different rotations are applied when the fillstyle is set
> to one of "bottom", "top", or "left".  "full" is another available
> fillstyle, which appears to take a unit rectangle and rotates that 45
> degrees.
> 
> Probably your best bet would be the 'top' fillstyle, which looks like
> it does a 90 degree rotation.
> 
> I hope this helps,
> Ben Root
> 
> 

On 11/10/2010 10:41 AM, Benjamin Root wrote:
>
>
> On Tue, Nov 9, 2010 at 8:44 PM, Jae-Joon Lee <lee...@gm... 
> <mailto:lee...@gm...>> wrote:
>
>     On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout
>     <jas...@cr... <mailto:jas...@cr...>>
>     wrote:
>     > 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)?
>     >
>
>     The tip of the arrow is meant to hit (1,1), which is done by the
>     underlying arrow class adjusting the end point of the path during the
>     drawing time. This only happens for arrowstyle "->" and etc.
>     However, there was an incorrect arithmetic which I think is fixed now.
>     The patch is attached (it also fixes dpi-related issues).
>     I'm not sure it would be better if this could be optionally turned
>     off. Any suggestion?
>     Let me know of any (persisting or other) issues.
>
>     FYI, path is shortened by small amount by default. This is controlled
>     by *shrink* parameter (shrinkA and shrinkB shortens the line begin and
>     the line end respectively.)
>
>
>     aa = ax.annotate('', (1,1), (0,0),
>                     arrowprops=dict(arrowstyle="-|>",
>                                     fc="k", ec="k",lw=50,
>                                     shrinkB=0,
>                                    
>     path_effects=[Stroke(joinstyle='miter')]
>                                     )
>
>     Also, I noticed that the arrow head is not correctly filled when
>     path_effects are in use. This is now fixed.
>
>     Regards,
>
>     -JJ
>
>
> I just seem to break things...
>
> I am not 100% sure if the tip is placed correctly, but it does appear 
> much better than before.  I now see a tiny bit of the red line 
> southwest of the vertex.  Before, the issue was that the arrow tip was 
> northeast of the vertex.  In addition, I found that I was still able 
> to produce the distortion after zooming in sufficiently (it took a few 
> extra zooms to make it happen).
>
> I then did one more zoom, and then tried resizing the window, and I 
> think I broke the Agg renderer.  Two exceptions were raised.  First, 
> an overflow error occurred while rendering the path (complexity 
> exceeded).  Then, an "SystemError: error return without exception set" 
> exception was raised from the same spot.  I am wondering if zooming 
> into the arrow distortion and/or resizing the figure window triggered 
> the complexity issue, and then the error handling routines weren't 
> properly handling the raised exception.  Here was my traceback:
The reason for the rendering complexity problem is that the arrow 
extends way, way, way off the edge of the image such that the values 
overflow (in pixel units) -- Agg uses 24.8 fixed-point arithmetic 
internally.  The exception throwing itself in this case was broken 
(since fixed).  Once the exception is thrown, it will always need to be 
thrown in subsequent calls into Agg, since there doesn't seem to be a 
clean way to recover from the exception.  (There might be, but it gets 
down into a much hairier patch to Agg than I've been able to work through).

matplotlib currently supports clipping paths to the bounds of the image 
which prevents these huge values from getting passed to the Agg layer 
and blowing it up.  Unfortunately, this algorithm only works on 
un-filled paths.  Arrows are implemented as filled shapes, so this 
clipping functionality is turned off for them.  The solution seems to be 
to implement a more sophisticated algorithm that would clip the path to 
the rectangle correctly.  Certainly such algorithms exist.

Mike

>
> Traceback (most recent call last):
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py", 
> line 394, in expose_event
>     self._render_figure(self._pixmap, w, h)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
>     FigureCanvasAgg.draw(self)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py", 
> line 394, in draw
>     self.figure.draw(self.renderer)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py", 
> line 55, in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/figure.py", 
> line 874, in draw
>     func(*args)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py", 
> line 55, in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/axes.py", 
> line 1954, in draw
>     a.draw(renderer)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py", 
> line 55, in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py", 
> line 1986, in draw
>     self.arrow_patch.draw(renderer)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patches.py", 
> line 3930, in draw
>     path_effect.draw_path(renderer, gc, p, affine, None)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patheffects.py", 
> line 121, in draw_path
>     renderer.draw_path(gc0, tpath, affine, None)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py", 
> line 117, in draw_path
>     self._renderer.draw_path(gc, path, transform, rgbFace)
> OverflowError: Agg rendering complexity exceeded. Consider 
> downsampling or decimating your data.
> Traceback (most recent call last):
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py", 
> line 394, in expose_event
>     self._render_figure(self._pixmap, w, h)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
>     FigureCanvasAgg.draw(self)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py", 
> line 394, in draw
>     self.figure.draw(self.renderer)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py", 
> line 55, in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/figure.py", 
> line 814, in draw
>     if self.frameon: self.patch.draw(renderer)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py", 
> line 55, in draw_wrapper
>     draw(artist, renderer, *args, **kwargs)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patches.py", 
> line 411, in draw
>     renderer.draw_path(gc, tpath, affine, rgbFace)
>   File 
> "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py", 
> line 117, in draw_path
>     self._renderer.draw_path(gc, path, transform, rgbFace)
> SystemError: error return without exception set
>
>
> ------------------------------------------------------------------------------
> 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

Dear mpl users,
I have the following problem to solve. Imagine to have the simple example reported on website plotting the errorbars of some x,y data:

#!/usr/bin/env python
import numpy as np
import matplotlib.pyplot as plt

# example data
x = np.arange(0.1, 4, 0.5)
y = np.exp(-x)

# example variable error bar values
yerr = 0.1 + 0.2*np.sqrt(x)
xerr = 0.1 + yerr

# First illustrate basic pyplot interface, using defaults where possible.
plt.figure()
plt.errorbar(x, y, xerr=0.2, yerr=0.4)
================================================
Now I change the last line into:

p = plt.errorbar(x, y, xerr=0.2, yerr=0.4)

and if I change, for instance, y:

y = y/2.

I can easily replace the x,y with:

p[0].set_data(x,y)

but I do not know how to do the same for the errorbars.

I need to do this as I am implementing a code with a GUI written in PyQt4, and I need to quickly replot some data.

Can anyone help me?

Many thanks in advance

Gianfranco Durin

On Wed, Nov 10, 2010 at 9:48 AM, Michiel de Hoon <mjl...@ya...> wrote:
> Garry, if the bug still exists in matplotlib 1.0 could you open a bug report for it?


I think Gary doesn't have easy access to 1.0.  Here is the relevant
example if anyone has 1.0 on macosx to test with

  http://matplotlib.sourceforge.net/examples/pylab_examples/image_origin.html

JDH

Garry, if the bug still exists in matplotlib 1.0 could you open a bug report for it?

Thanks,
--Michiel.

--- On Wed, 11/10/10, John Hunter <jd...@gm...> wrote:

> From: John Hunter <jd...@gm...>
> Subject: Re: [Matplotlib-users] python v ipython problem in imshow()
> To: "Garry Willgoose" <Gar...@ne...>, "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Wednesday, November 10, 2010, 8:28 AM
> On Wed, Nov 10, 2010 at 5:43 AM,
> Garry Willgoose
> <Gar...@ne...>
> wrote:
> > John,
> >
> > OK by looking at matplotlib.rcParams['backend'] I've
> been able to diagnose this a little more.
> >
> > When the backend is  'WXAgg' everything looks fine.
> The axes have (0,0) where you would expect and the data is
> plotted correctly.
> >
> > However, when the backend is 'MacOSX' the axes again
> have (0,0) where you would expect but the data is plotted so
> it is flipped vertically (i.e. what is at the top is at the
> bottom, and vice versa).
> >
> > It doesn't look like an issue between python and
> ipython, or at least I don't seem to have been able to
> reproduce it tonight
> >
> > I'm using matplotlib version 0.99.1.1. Is this likely
> to be fixed in V1.0? I haven't upgraded to the latest
> enthought distribution because I had some problems with the
> binary extension libraries I have written ... I ought to
> sort it out but I've got a bit of deadline approaching and
> I'd prefer to leave it til later
> 
> It looks like the macosx backend has not implemented
> support for the
> image origin parameter.  I'm CC-ing Michiel, the
> macosx author, to see
> if this is something he can add support for.
> 
> Thanks,
> JDH
> 


      

On Tue, Nov 9, 2010 at 8:44 PM, Jae-Joon Lee <lee...@gm...> wrote:

> On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout
> <jas...@cr...> wrote:
> > 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)?
> >
>
> The tip of the arrow is meant to hit (1,1), which is done by the
> underlying arrow class adjusting the end point of the path during the
> drawing time. This only happens for arrowstyle "->" and etc.
> However, there was an incorrect arithmetic which I think is fixed now.
> The patch is attached (it also fixes dpi-related issues).
> I'm not sure it would be better if this could be optionally turned
> off. Any suggestion?
> Let me know of any (persisting or other) issues.
>
> FYI, path is shortened by small amount by default. This is controlled
> by *shrink* parameter (shrinkA and shrinkB shortens the line begin and
> the line end respectively.)
>
>
> aa = ax.annotate('', (1,1), (0,0),
>                 arrowprops=dict(arrowstyle="-|>",
>                                 fc="k", ec="k",lw=50,
>                                 shrinkB=0,
>                                 path_effects=[Stroke(joinstyle='miter')]
>                                 )
>
> Also, I noticed that the arrow head is not correctly filled when
> path_effects are in use. This is now fixed.
>
> Regards,
>
> -JJ
>

I just seem to break things...

I am not 100% sure if the tip is placed correctly, but it does appear much
better than before.  I now see a tiny bit of the red line southwest of the
vertex.  Before, the issue was that the arrow tip was northeast of the
vertex.  In addition, I found that I was still able to produce the
distortion after zooming in sufficiently (it took a few extra zooms to make
it happen).

I then did one more zoom, and then tried resizing the window, and I think I
broke the Agg renderer.  Two exceptions were raised.  First, an overflow
error occurred while rendering the path (complexity exceeded).  Then, an
"SystemError: error return without exception set" exception was raised from
the same spot.  I am wondering if zooming into the arrow distortion and/or
resizing the figure window triggered the complexity issue, and then the
error handling routines weren't properly handling the raised exception.
Here was my traceback:

Traceback (most recent call last):
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py",
line 394, in expose_event
    self._render_figure(self._pixmap, w, h)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
    FigureCanvasAgg.draw(self)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py",
line 394, in draw
    self.figure.draw(self.renderer)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/figure.py",
line 874, in draw
    func(*args)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/axes.py",
line 1954, in draw
    a.draw(renderer)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/text.py",
line 1986, in draw
    self.arrow_patch.draw(renderer)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patches.py",
line 3930, in draw
    path_effect.draw_path(renderer, gc, p, affine, None)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patheffects.py",
line 121, in draw_path
    renderer.draw_path(gc0, tpath, affine, None)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py",
line 117, in draw_path
    self._renderer.draw_path(gc, path, transform, rgbFace)
OverflowError: Agg rendering complexity exceeded. Consider downsampling or
decimating your data.
Traceback (most recent call last):
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py",
line 394, in expose_event
    self._render_figure(self._pixmap, w, h)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtkagg.py",
line 75, in _render_figure
    FigureCanvasAgg.draw(self)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py",
line 394, in draw
    self.figure.draw(self.renderer)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/figure.py",
line 814, in draw
    if self.frameon: self.patch.draw(renderer)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/artist.py",
line 55, in draw_wrapper
    draw(artist, renderer, *args, **kwargs)
  File "/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/patches.py",
line 411, in draw
    renderer.draw_path(gc, tpath, affine, rgbFace)
  File
"/home/bvr/Programs/matplotlib/matplotlib/lib/matplotlib/backends/backend_agg.py",
line 117, in draw_path
    self._renderer.draw_path(gc, path, transform, rgbFace)
SystemError: error return without exception set

On Wed, Nov 10, 2010 at 7:44 AM, Christian Meesters <
mee...@im...> wrote:

> Hi,
>
> Honestly, I neglected my mpl skills lately, so I don't know whether docs
> on this topic are available, but I couldn't find them either.
>
> I would like to create a forest plot using horizontal errorbars.
> Currently my marker is simply 'kd' in pylab.errorbar, where 'd' is
> similar to LaTeX's \blacklozenge.
>
> Is there a way to rotate the marker such that long cross section is
> horizontal (rotation by 90 degree) and not vertical anymore?
>
> TIA
> Christian
>
>
>
Christian,

Looking through the code for drawing the "thin diamond", I think you might
be able to get what you want by specifying the fillstyle.  It appears that
different rotations are applied when the fillstyle is set to one of
"bottom", "top", or "left".  "full" is another available fillstyle, which
appears to take a unit rectangle and rotates that 45 degrees.

Probably your best bet would be the 'top' fillstyle, which looks like it
does a 90 degree rotation.

I hope this helps,
Ben Root

Hi,

Honestly, I neglected my mpl skills lately, so I don't know whether docs
on this topic are available, but I couldn't find them either.

I would like to create a forest plot using horizontal errorbars.
Currently my marker is simply 'kd' in pylab.errorbar, where 'd' is
similar to LaTeX's \blacklozenge. 

Is there a way to rotate the marker such that long cross section is
horizontal (rotation by 90 degree) and not vertical anymore?

TIA
Christian

That works great.
Never would have looked there.
Thanks!
Mark

On Wed, Nov 10, 2010 at 2:27 PM, John Hunter <jd...@gm...> wrote:

>  axes.unicode_minus : False

On Wed, Nov 10, 2010 at 5:43 AM, Garry Willgoose
<Gar...@ne...> wrote:
> John,
>
> OK by looking at matplotlib.rcParams['backend'] I've been able to diagnose this a little more.
>
> When the backend is  'WXAgg' everything looks fine. The axes have (0,0) where you would expect and the data is plotted correctly.
>
> However, when the backend is 'MacOSX' the axes again have (0,0) where you would expect but the data is plotted so it is flipped vertically (i.e. what is at the top is at the bottom, and vice versa).
>
> It doesn't look like an issue between python and ipython, or at least I don't seem to have been able to reproduce it tonight
>
> I'm using matplotlib version 0.99.1.1. Is this likely to be fixed in V1.0? I haven't upgraded to the latest enthought distribution because I had some problems with the binary extension libraries I have written ... I ought to sort it out but I've got a bit of deadline approaching and I'd prefer to leave it til later

It looks like the macosx backend has not implemented support for the
image origin parameter.  I'm CC-ing Michiel, the macosx author, to see
if this is something he can add support for.

Thanks,
JDH

On Wed, Nov 10, 2010 at 6:38 AM, Mark Bakker <ma...@gm...> wrote:

> I have a pretty wacky problem.
> I create a figure which includes negative values along the y-axis:
> plot([-1,1]) for example.
> I save the figure as EPS.
> When I look at the figure with preview on my Mac it looks fine.
> When I import the figure in my Latex document the negative values disappear.
> My solution has been to use eps2eps on the eps file created by mpl, and this
> solves the problem. So apparently there is something not quite standard on
> the EPS file created by MPL.
> Is this a bug?
> I am running version 0.99.3 (Enthought dis) on a Mac running Leopard.

mpl by default uses the unicode minus symbol rather than the hyphen to
indicate negative numbers.  It looks like your system may not be
recognizing it.  The easiest solution is to set

 axes.unicode_minus : False

in your matplotlib rc.

JDH

Hello everyone, 

I have a question regarding the formatting of ticks in a curved
coordinate system. To create my plots I am useing the
mpl_toolkits.axisartist.floating_axes.GridHelperCurveLinear() function.
This works quite well but I have difficulties with formatting the axis.
I am working in a polar coordinate system. To format the longitudinal
axis I found the function
mpl_toolkits.axisartist.angle_helper.FormatterDMS() and it works good.
But I want to chance the formatting of the radius too. For this I need
to pass something to the kwargs tick_formatter2 of the function
GridHelperCurveLinear but I do not know what. 

Could you give me some advice?

Regards

Stefan

Here is the code I use:

import matplotlib.pyplot as plt
import mpl_toolkits.axisartist.floating_axes as floating_axes
from   matplotlib.projections import PolarAxes

fig = plt.figure()

tr = PolarAxes.PolarTransform()

grid_helper = floating_axes.GridHelperCurveLinear( tr, extremes=( 1, 2,
1000, 2000 ), tick_formatter1 = None, tick_formatter2 = None )

ax1 = floating_axes.FloatingSubplot( fig, 111, grid_helper=grid_helper )

fig.add_subplot( ax1 )

ax1.grid( True )

plt.show()

Hello List,

I have a pretty wacky problem.
I create a figure which includes negative values along the y-axis:
plot([-1,1]) for example.
I save the figure as EPS.
When I look at the figure with preview on my Mac it looks fine.
When I import the figure in my Latex document the negative values disappear.
My solution has been to use eps2eps on the eps file created by mpl, and this
solves the problem. So apparently there is something not quite standard on
the EPS file created by MPL.
Is this a bug?
I am running version 0.99.3 (Enthought dis) on a Mac running Leopard.

Thanks for any suggestions,

Mark

John,

OK by looking at matplotlib.rcParams['backend'] I've been able to diagnose this a little more.

When the backend is  'WXAgg' everything looks fine. The axes have (0,0) where you would expect and the data is plotted correctly. 

However, when the backend is 'MacOSX' the axes again have (0,0) where you would expect but the data is plotted so it is flipped vertically (i.e. what is at the top is at the bottom, and vice versa). 

It doesn't look like an issue between python and ipython, or at least I don't seem to have been able to reproduce it tonight

I'm using matplotlib version 0.99.1.1. Is this likely to be fixed in V1.0? I haven't upgraded to the latest enthought distribution because I had some problems with the binary extension libraries I have written ... I ought to sort it out but I've got a bit of deadline approaching and I'd prefer to leave it til later


> 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

On 11/9/10 8:44 PM, Jae-Joon Lee wrote:
> On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout
> <jas...@cr...>  wrote:
>> 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)?
>>
>
> The tip of the arrow is meant to hit (1,1), which is done by the
> underlying arrow class adjusting the end point of the path during the
> drawing time. This only happens for arrowstyle "->" and etc.
> However, there was an incorrect arithmetic which I think is fixed now.
> The patch is attached (it also fixes dpi-related issues).
> I'm not sure it would be better if this could be optionally turned
> off. Any suggestion?
> Let me know of any (persisting or other) issues.

Wow.  You're amazing.  Thanks for all the work you put into this right 
away!  When I set shrinkB to zero, that arrow is right on the money.

>
> FYI, path is shortened by small amount by default. This is controlled
> by *shrink* parameter (shrinkA and shrinkB shortens the line begin and
> the line end respectively.)
>

Right.  In Sage, we're using the shrinkA and shrinkB options quite a 
bit.  For example, we use it in drawing vertex-and-edge graphs (so the 
arrows go to the edges of the vertex circles), and right now we use it 
by default to shrink by the linewidth (though I think I'm going to turn 
off Sage's default shrinking and just leave that up to the user).

This latest patch seems to take care of the problems I was seeing.

Thanks again!

Jason

--
Jason Grout

On Wed, Nov 10, 2010 at 1:01 AM, Jason Grout
<jas...@cr...> wrote:
> 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)?
>

The tip of the arrow is meant to hit (1,1), which is done by the
underlying arrow class adjusting the end point of the path during the
drawing time. This only happens for arrowstyle "->" and etc.
However, there was an incorrect arithmetic which I think is fixed now.
The patch is attached (it also fixes dpi-related issues).
I'm not sure it would be better if this could be optionally turned
off. Any suggestion?
Let me know of any (persisting or other) issues.

FYI, path is shortened by small amount by default. This is controlled
by *shrink* parameter (shrinkA and shrinkB shortens the line begin and
the line end respectively.)


aa = ax.annotate('', (1,1), (0,0),
                 arrowprops=dict(arrowstyle="-|>",
                                 fc="k", ec="k",lw=50,
                                 shrinkB=0,
                                 path_effects=[Stroke(joinstyle='miter')]
                                 )

Also, I noticed that the arrow head is not correctly filled when
path_effects are in use. This is now fixed.

Regards,

-JJ

On 11/5/10 5:08 AM, Basedow Sünnje Linnéa wrote:
>
> Hi!
> I try to plot some interpolated data on a map and get an error saying 
> there are too many indices. When I use contour in matplotlib without 
> basemap I don't get the error. Also the map without a contour plot on 
> it works. Maybe some of you know what I do wrong?
>
> Here is my code:
> -------------
> import numpy as np
> import matplotlib.pyplot as plt
> from matplotlib.mlab import griddata
> from mpl_toolkits.basemap import Basemap
>
> yi = np.linspace(min(Lat),max(Lat),100)
> xi = np.linspace(min(Lon),max(Lon),50)
> lon,lat,var = np.array(Lon), np.array(Lat), np.array(Var)
> zi = griddata(lon,lat,var,xi,yi)
>
> map = Basemap(projection='cyl', llcrnrlat=67, urcrnrlat=73,\
>            llcrnrlon=4, urcrnrlon=20, resolution='h')
>
> map.drawcoastlines()
>
> map.drawmeridians(np.arange(0,360,1))
> map.drawparallels(np.arange(-90,90,1))
>
> xlon, ylat = map(xi,yi)
> cs = map.contour(xlon,ylat,zi)
>
> plt.show()
> ---------------
>
> and this is the error message:
>
> cs = map.contour(xlon,ylat,zi)
> File 
> "/usr/local/lib/python2.6/dist-packages/mpl_toolkits/basemap/__init__.py", 
> line 2820, in contour
>   xx = x[x.shape[0]/2,:]
> IndexError: too many indices
>
> Any help appreciated!
> Sünnje
>

Sunnje:  xlon, xlat must be 2d arrays (with the same shape as zi) when 
used with the contourf basemap method.  You can make them into 2d arrays 
with meshgrid.

-Jeff

On Wed, Nov 10, 2010 at 12:21 AM, Benjamin Root <ben...@ou...> wrote:
> On Tue, Nov 9, 2010 at 7:24 AM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> Thanks for tracking down this.
>> It turned out to be a silly error while adjusting the line end-point.
>> I'm attaching the patch. Please test the patch if you can.
>> I'll commit the change sometime tomorrow.
>>

Thanks. I can reproduce the problem.

aa = ax.annotate('', (1,1),
                 (-10,-10),
                 arrowprops=dict(arrowstyle="-|>",
                                 fc="w", ec="k",lw=30,
                                 path_effects=[Stroke(joinstyle='miter')])
                 )

The erroneous behavior happens when one tries to draw a path that
connects points far outside of the canvas (point 10,10 in above
example). And this is a AGG-specific issue.  The erroneous behavior
goes away if we clip the path.

aa.arrow_patch.set_clip_box(ax.figure.bbox)

I try to reproduce the problem with simple plot command, but couldn't.
Maybe this happens only for rendering bezier splines?
Michael, any idea?

One thing I may do to prevent it is to set the clip_path of the arrow
to the figure.bbox by default.
I'll think about it.

Regards,

-JJ


>> Regards,
>>
>> -JJ
>>
>>
>> On Tue, Nov 9, 2010 at 9:15 PM, Jason Grout <jas...@cr...>
>> wrote:
>>>
>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>
> Jae-Joon,
>
> 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).
>
> Ben Root
>
>

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