matplotlib-users Mailing List for matplotlib (Page 5)

On Thu, Jan 21, 2010 at 9:24 PM, Eric Firing <ef...@ha...> wrote:
> I changed my mind and decided you are correct in thinking the change should
> be made in contour.py. I now make the bottom boundary adjustment at the
> last possible time, and in such a way that it does not change the levels
> array at all. Therefore the colorbar never sees it, and the result of
> explicitly supplying a set of levels is identical to the case where those
> levels result from autoscaling.
>
Great! Thanks~
-JJ

The rotation of the ticklabels are now measured relative to the
direction of the ticks. While I understand this can be confusing at
first, this is kind of necessary to support axis along an arbitrary
path.
For example, the default rotation for the ticklabels in the top axis
is 180, not 0 (but it looks like 0). So, in your case, the angle
should be 190, instead of 10 (at line 117). Let me know if there is
any other issue.
-JJ
On Thu, Jan 21, 2010 at 8:34 PM, Gökhan Sever <gok...@gm...> wrote:
> JJ,
>
> One thing is still little mysterious. My top xticks are reversed.
>
> See in the saved image: http://img46.imageshack.us/img46/3849/imagevp.png
>
> The code that produces that script:
> http://code.google.com/p/ccnworks/source/browse/trunk/dccn_plot.py
>
> Any ideas?
>
>
> On Thu, Jan 21, 2010 at 5:45 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> On Thu, Jan 21, 2010 at 6:16 PM, Gökhan Sever <gok...@gm...>
>> wrote:
>> > Yes, it is running from the latest trunk check-out.
>>
>> The internals of how ticks, ticklables work in the svn version have
>> significantly changed, which I hope is an improvement. Unfortunately,
>> "_label_angles" is deprecated and should not be used. Instead, try,
>>
>> ax.axis["right"].label.set_axis_direction("left")
>>
>> The documentation is yet to be written, but there are some examples
>> you may take a look.
>>
>> doc/mpl_toolkits/axes_grid/figures/demo_axis_direction.py
>> doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
>> doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
>>
>> Regards,
>>
>> -JJ
>
>
>
> --
> Gökhan
>

Hi there,
I am trying to plot a surface using plot_surface.
As this surface is generated using griddata, the corresponding z-values
is a masked array.
When I plot this masked array using plot_surface, 
the colormap is completely upset, the whole surface appears in blue.
One can do something like
plot_surface(x,y,z.filled(z.mean()),cmap=cmap.jet)
but this is not really what one would like to have, because the missing
values are being
displayed, and in this case, the missing values are certainly not equal to
the mean of the surface.
Alternatively, it would be nice if griddata allowed to extrapolate a bit out
of the convex hull 
of the given data. It seems that natgrid is able to do this (I found options
that specifies this), I installed natgrid, but in the matplotlib interface
to natgrid, one cannot specify any options proper to natgrid,
and extrapolation seems to be switched off, leading to masked arrays being
returned.
One more alternative would be that the color calculation for the surface
would only be done
for the non-masked fields in the masked array, but I do not know how to tell
matplotlib to do this
or how to do this by hand.
Any help appreciated!
-- 
View this message in context: http://old.nabble.com/plot_surface-masked-array-tp27266471p27266471.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Jae-Joon Lee wrote:
> On Wed, Jan 20, 2010 at 2:04 PM, Eric Firing <ef...@ha...> wrote:
>> The reason for this fudge in contour is that contourf fills
>> lower < z <= upper
>> for each consecutive pair of contour levels.
>> When the minimum value of z coincides with the lowest level, then regions
>> with that minimum are left blank; so the lowest level is adjusted downward
>> slightly, making the lowest contour interval include the minimum value.
>>
> 
> I understand levels can be adjusted for a better contouring, but I'm
> not sure whether this change needs to be visible to users.
> 
> The autoleveler, initially creates following levels
> 
> [0, 1.5, 3, 4.5, 6, 7.5, 9.]
> 
> But due to the reason you described above, they become
> 
> array([ -9.00000000e-06, 1.50000000e+00, 3.00000000e+00,
> 4.50000000e+00, 6.00000000e+00, 7.50000000e+00,
> 9.00000900e+00])
> 
> And the colorbar uses the adjusted levels for labeling. But I think it
> may make more sense to use the initial levels (at least for the
> colorbar ticks).
JJ,
I changed my mind and decided you are correct in thinking the change 
should be made in contour.py. I now make the bottom boundary adjustment 
at the last possible time, and in such a way that it does not change the 
 levels array at all. Therefore the colorbar never sees it, and the 
result of explicitly supplying a set of levels is identical to the case 
where those levels result from autoscaling.
Eric
> 
> Regards,
> 
> -JJ

JJ,
One thing is still little mysterious. My top xticks are reversed.
See in the saved image: http://img46.imageshack.us/img46/3849/imagevp.png
The code that produces that script:
http://code.google.com/p/ccnworks/source/browse/trunk/dccn_plot.py
Any ideas?
On Thu, Jan 21, 2010 at 5:45 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Jan 21, 2010 at 6:16 PM, Gökhan Sever <gok...@gm...>
> wrote:
> > Yes, it is running from the latest trunk check-out.
>
> The internals of how ticks, ticklables work in the svn version have
> significantly changed, which I hope is an improvement. Unfortunately,
> "_label_angles" is deprecated and should not be used. Instead, try,
>
> ax.axis["right"].label.set_axis_direction("left")
>
> The documentation is yet to be written, but there are some examples
> you may take a look.
>
> doc/mpl_toolkits/axes_grid/figures/demo_axis_direction.py
> doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
> doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
>
> Regards,
>
> -JJ
>
-- 
Gökhan

On Thu, Jan 21, 2010 at 6:16 PM, Gökhan Sever <gok...@gm...> wrote:
> Yes, it is running from the latest trunk check-out.
The internals of how ticks, ticklables work in the svn version have
significantly changed, which I hope is an improvement. Unfortunately,
"_label_angles" is deprecated and should not be used. Instead, try,
ax.axis["right"].label.set_axis_direction("left")
The documentation is yet to be written, but there are some examples
you may take a look.
doc/mpl_toolkits/axes_grid/figures/demo_axis_direction.py
doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
doc/mpl_toolkits/axes_grid/figures/demo_ticklabel_alignment.py
Regards,
-JJ

On Thu, Jan 21, 2010 at 4:16 PM, Michael Cohen <mc...@ca...> wrote:
> Hi all,
> I am trying to figure out how to increase the size of the numbers that
> label the tick marks on the axes.
> Increasing the size of the axis labels is easy, use xlabel and the
> option fontsize = #
> How do I make the numbers labelling the ticks bigger? I dont specify
> the ticks by hand, they are chosen automatically.
>
> Cheers
> Michael
>
Either from your matplotlibrc file or using (in an ipython --pylab):
xticklabels = getp(gca(), 'xticklabels')
yticklabels = getp(gca(), 'yticklabels')
setp(xticklabels, fontsize=14, weight='bold')
setp(yticklabels, fontsize=14, weight='bold')
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Gökhan

Yes, it is running from the latest trunk check-out.
On Thu, Jan 21, 2010 at 3:27 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Do you happen to use the svn version?
> Regards,
>
> -JJ
>
>
> On Thu, Jan 21, 2010 at 3:06 PM, Gökhan Sever <gok...@gm...>
> wrote:
> > Possibly a question for JJ:
> >
> > pary.axis["right"].get_helper()._label_angles["right"]=270
> >
> > This lines complain in my script when I try to run it:
> >
> > Traceback (most recent call last):
> > File "/usr/local/bin/aerosol_plot.py", line 276, in <module>
> > pary.axis["right"].get_helper()._label_angles["right"]=270
> > AttributeError: 'Fixed' object has no attribute '_label_angles'
> >
> > Could you tell me how to eliminate this issue?
> >
> > Thanks.
> >
> > --
> > Gökhan
> >
> >
> ------------------------------------------------------------------------------
> > Throughout its 18-year history, RSA Conference consistently attracts the
> > world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important issues
> > through
> > interactions with peers, luminaries and emerging and established
> companies.
> > http://p.sf.net/sfu/rsaconf-dev2dev
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
-- 
Gökhan

On Thu, Jan 21, 2010 at 2:31 PM, Andrew Kelly <ndr...@gm...> wrote:
> Turning label2On = true turned on the labels as directed. However, the
> function   label2.set_text("New Tick Label")   does not update the
> actual text. I can set_size(), etc and it works, but set_text() does not
> update. Any ideas why?
>
You should not call set_text directly, instead you need to call
Axis.set_ticklabels.
If you want the top (right) ticks have different ticklabels than the
bottom (left) ticks, that is not possible.
You need to make another axes by calling twin*.
-JJ

Hi all,
I am trying to figure out how to increase the size of the numbers that 
label the tick marks on the axes.
Increasing the size of the axis labels is easy, use xlabel and the 
option fontsize = #
How do I make the numbers labelling the ticks bigger? I dont specify 
the ticks by hand, they are chosen automatically.
Cheers
Michael

Hey all,
wow, this seems like it should be an easy thing but I am not finding 
answers in the gallery or searching the documentation.
How does one set the font size on ticklabels and labels for a figure?
I would expect something like plot(arange(11), xfontsize=14) to work 
but I am not finding any keywords here for that. what am I missing?
this works for the labels
plot(arange(11))
ax=gca()
ax.set_xlabel('i am x', size=18)
I am trying all sorts of weird things for the ticklabels like
plot(arange(11))
ax=gca()
for val in ax.get_xticklabels():
 ax.set_xticklabels(val._text, size=18)
but this must be wrong.
Thanks much,
Brian
-- 
-----------------------------------------------------------
Brian A Larsen, PhD
RBSP-ECT Instrument Suite Scientist
Boston University
Center for Space Physics
725 Commonwealth Ave, Rm 506
Boston, MA 02215-1401
T: 617-358-4945
F: 617-353-6463
bal...@bu...

On Thu, Jan 21, 2010 at 4:13 PM, Kurt Forrester
<kur...@ho...> wrote:
> Just to add one more query to the thread, do you consider a point on a
> vertex of the axes to be a candidate for annotation without clipping? That
> is to say if there is a point (0,0) I wish to annotate, and the origin of
> the axes contains that point (0,0), would you (by design) want to be able to
> annotate that point? My initial uncertainty as to why I need to have the
> clipping turned to False in the first instance is because I thought that if
> a point may fall on a any of the vertices they still should be considered
> in the visible field.
>
I would agree with you. However, the current behavior inherits from
how "inside test" is done for paths in general (point_in_path_impl in
src/_path.cpp). So there is not much thing I can help. We may check
if the point is "on" the path addiitionally, but I'm not sure if there
is a relevant routine (while there is point_on_path, but I'm not sure
if this is it). I'll try to take a further look later.
Regards,
-JJ

Do you happen to use the svn version?
Regards,
-JJ
On Thu, Jan 21, 2010 at 3:06 PM, Gökhan Sever <gok...@gm...> wrote:
> Possibly a question for JJ:
>
>   pary.axis["right"].get_helper()._label_angles["right"]=270
>
> This lines complain in my script when I try to run it:
>
> Traceback (most recent call last):
>  File "/usr/local/bin/aerosol_plot.py", line 276, in <module>
>   pary.axis["right"].get_helper()._label_angles["right"]=270
> AttributeError: 'Fixed' object has no attribute '_label_angles'
>
> Could you tell me how to eliminate this issue?
>
> Thanks.
>
> --
> Gökhan
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

> From: lee...@gm...
> Date: 2010年1月21日 13:21:41 -0500
> Subject: Re: [Matplotlib-users] Annotate Behaviour - Arrows Missing
> To: kur...@ho...
> CC: mat...@li...
> 
> On Thu, Jan 21, 2010 at 12:53 PM, Kurt Forrester
> <kur...@ho...> wrote:
> > Sorry the text IS drawn in the second example. So the setting of the
> > attribute after it is drawn (before it is shown) seems to do the trick.
> >
> > Kurt
> 
> It seems that somehow the annotation_clip parameter is ignored when it
> is given during the object creation. While I'm not 100% sure, this
> seems to be fixed in the current svn where it does work.
> 
> And I presume your original script will also work if you call
> set_annotation_clip explicitly.
> Let me know if there is any other problem.
> 
> Regards,
> 
> -JJ
JJ,
I can confirm that by calling .set_annotation_clip(False) after the creation of the object makes all the annotations appear as expected. I will amend my code until I get the latest version installed.
Just to add one more query to the thread, do you consider a point on a vertex of the axes to be a candidate for annotation without clipping? That is to say if there is a point (0,0) I wish to annotate, and the origin of the axes contains that point (0,0), would you (by design) want to be able to annotate that point? My initial uncertainty as to why I need to have the clipping turned to False in the first instance is because I thought that if a point may fall on a any of the vertices they still should be considered in the visible field. 
This is just a thought.
Thank you for your effort on this.
Kind Regards.,
Kurt
 		 	 		 
_________________________________________________________________
Time for a new car? Sell your old one fast!
http://clk.atdmt.com/NMN/go/157637060/direct/01/ 

Hello List,
I know I may be hoping for too much, but is there a way to get the 3D
figures into a file that may be converted to an animated pdf?
Pdf now allows for inclusion of a 3D figure, and as far as I can see it
needs to be in U3D or PRC format.
Has anybody been successful converting any of the matplotlib output file
types to U3D or PRC?
Eventually I would like to add the figure in a Latex document and use
movie15 to get a rotatable 3D images in my document.
Thanks,
Mark

Possibly a question for JJ:
 pary.axis["right"].get_helper()._label_angles["right"]=270
This lines complain in my script when I try to run it:
Traceback (most recent call last):
 File "/usr/local/bin/aerosol_plot.py", line 276, in <module>
 pary.axis["right"].get_helper()._label_angles["right"]=270
AttributeError: 'Fixed' object has no attribute '_label_angles'
Could you tell me how to eliminate this issue?
Thanks.
-- 
Gökhan

Turning label2On = true turned on the labels as directed. However, the
function label2.set_text("New Tick Label") does not update the
actual text. I can set_size(), etc and it works, but set_text() does not
update. Any ideas why?
-Andrew
On Thu, Jan 21, 2010 at 10:32 AM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Jan 21, 2010 at 1:16 PM, Andrew Kelly <ndr...@gm...> wrote:
> > (Part of my confusion stems from the fact that I can access the Tick
> > instances on the Axis but when I call Tick.set_label2("New Label") the
> label
> > does not get drawn. Perhaps I am being daft.)
> >
>
> http://matplotlib.sourceforge.net/api/axis_api.html#matplotlib.axis.Tick
>
> You need to set label2On attribute as True.
>
> I think there is no convenient function that do this, other than
> manually iterate over the ticks.
>
> Regards,
>
> -JJ
>

On Thu, Jan 21, 2010 at 1:16 PM, Andrew Kelly <ndr...@gm...> wrote:
> (Part of my confusion stems from the fact that I can access the Tick
> instances on the Axis but when I call Tick.set_label2("New Label") the label
> does not get drawn. Perhaps I am being daft.)
>
http://matplotlib.sourceforge.net/api/axis_api.html#matplotlib.axis.Tick
You need to set label2On attribute as True.
I think there is no convenient function that do this, other than
manually iterate over the ticks.
Regards,
-JJ

On Thu, Jan 21, 2010 at 12:53 PM, Kurt Forrester
<kur...@ho...> wrote:
> Sorry the text IS drawn in the second example. So the setting of the
> attribute after it is drawn (before it is shown) seems to do the trick.
>
> Kurt
It seems that somehow the annotation_clip parameter is ignored when it
is given during the object creation. While I'm not 100% sure, this
seems to be fixed in the current svn where it does work.
And I presume your original script will also work if you call
set_annotation_clip explicitly.
Let me know if there is any other problem.
Regards,
-JJ

Can someone point out how to simply label the ticks on the top and right of
a plot? twinx() and twiny() are not necessary because I don't need
independent scales and the mpl_toolkits.axes_grid.parasite_axes module is a
bit too limiting for my purposes.
(Part of my confusion stems from the fact that I can access the Tick
instances on the Axis but when I call Tick.set_label2("New Label") the label
does not get drawn. Perhaps I am being daft.)
Thanks in advance.
-Andrew

> From: lee...@gm...
> Date: 2010年1月21日 10:46:00 -0500
> Subject: Re: [Matplotlib-users] Annotate Behaviour - Arrows Missing
> To: kur...@ho...
> CC: mat...@li...
> 
> On Thu, Jan 21, 2010 at 9:37 AM, Kurt Forrester
> <kur...@ho...> wrote:
> > The first one reported None.
> > The second one reported False.
> 
> And the text is still not drawn with the second example?
> 
> -JJ
Sorry the text IS drawn in the second example. So the setting of the attribute after it is drawn (before it is shown) seems to do the trick.
Kurt
 		 	 		 
_________________________________________________________________
Search for properties that match your lifestyle! Start searching NOW!
http://clk.atdmt.com/NMN/go/157631292/direct/01/ 

On Thu, Jan 21, 2010 at 9:37 AM, Kurt Forrester
<kur...@ho...> wrote:
> The first one reported None.
> The second one reported False.
And the text is still not drawn with the second example?
-JJ

http://matplotlib.sourceforge.net/users/usetex.html
"Postscript options
In order to produce encapsulated postscript files that can be embedded 
in a new LaTeX document, the default behavior of matplotlib is to 
distill the output, which removes some postscript operators used by 
LaTeX that are illegal in an eps file. This step produces results which 
may be unacceptable to some users, because the text is coarsely 
rasterized and converted to bitmaps, which are not scalable like 
standard postscript, and the text is not searchable. One workaround is 
to to set ps.distiller.res to a higher value (perhaps 6000) in your rc 
settings, which will produce larger files but may look better and scale 
reasonably. A better workaround, which requires Poppler 
<http://poppler.freedesktop.org/> or Xpdf <http://www.foolabs.com/xpdf>, 
can be activated by changing the ps.usedistiller rc setting to xpdf. 
This alternative produces postscript without rasterizing text, so it 
scales properly, can be edited in Adobe Illustrator, and searched text 
in pdf documents."
fwiw,
Alan Isaac

> From: lee...@gm...
> Date: 2010年1月20日 17:35:21 -0500
> Subject: Re: [Matplotlib-users] Annotate Behaviour - Arrows Missing
> To: kur...@ho...
> CC: mat...@li...
> 
> On Wed, Jan 20, 2010 at 3:07 PM, Kurt Forrester
> <kur...@ho...> wrote:
> > the output from the script is:
> >
> > annotation_clip = None
> > checking is point is inside the axes : [ 30.875 233. ]
> > contains_point = 0
> > _check_xy returning False
> > exit without drawing due to annotation_clip
> >
> >
> 
> Weird.
> How about this one?
> 
> fig = figure()
> ax=subplot(111)
> txt = ax.annotate("Test", (-0.1, 0.5), annotation_clip=False)
> print txt.get_annotation_clip()
> 
> If it still print out None, see if the next code make any difference.
> 
> fig = figure()
> ax=subplot(111)
> txt = ax.annotate("Test", (-0.1, 0.5))
> txt.set_annotation_clip(False)
> print txt.get_annotation_clip()
> 
> 
> -JJ
The first one reported None.
The second one reported False.
Kurt
 		 	 		 
_________________________________________________________________
Time for a new car? Sell your old one fast!
http://clk.atdmt.com/NMN/go/157637060/direct/01/ 

The `transform` method requires that its argument is a numpy array. You "got lucky" with duck typing in the non-log case, but there is an assumption in the transformation code that it can use Numpy array functionality on whatever is passed in. Unfortunately, the transforms code is so low-level and core to matplotlib that any checking or coercing of the types passed in makes a significant impact on interactive performance, so I'm reluctant to add that. The docstring does say this:
 """
 Performs the transformation on the given array of values.
 Accepts a numpy array of shape (N x :attr:`input_dims`) and
 returns a numpy array of shape (N x :attr:`output_dims`).
 """
I've attached a fixed version of your script that uses Numpy arrays 
rather than tuples for the points.
Mike
Cédrick FAURY wrote:
> Hello,
>
> When I try to use transData.transform on a log plot, an error occurs :
> ...
> File "E:\Python26\lib\site-packages\matplotlib\transforms.py", line 
> 1895, in transform
> self._a.transform(points))
> File "E:\Python26\lib\site-packages\matplotlib\transforms.py", line 
> 1723, in transform
> x_points = x.transform(points[:, 0])
> TypeError: tuple indices must be integers, not tuple
>
> Here is an example :
> #!/usr/bin/env python
>
> import matplotlib
> matplotlib.use('WXAgg')
> from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as 
> FigureCanvas
> from matplotlib.figure import Figure
>
> import wx
>
> class CanvasFrame(wx.Frame):
>
> def __init__(self):
> wx.Frame.__init__(self,None,-1,
> 'CanvasFrame',size=(550,350))
>
> self.SetBackgroundColour(wx.NamedColor("WHITE"))
>
> self.figure = Figure()
>
> self.axes = self.figure.add_subplot(111)
> self.axes.set_xscale('log')
>
> p1 = (1,1)
> p2 = (2,2)
> _x1, _y1 = self.axes.transData.transform(p1)
> _x2, _y2 = self.axes.transData.transform(p2)
> _xy = [[_x1, _y1], [_x2, _y2]]
>
> xy = self.axes.transData.inverted().transform(_xy)
>
> self.axes.plot(xy)
> self.canvas = FigureCanvas(self, -1, self.figure)
>
> self.sizer = wx.BoxSizer(wx.VERTICAL)
> self.sizer.Add(self.canvas, 1, wx.LEFT | wx.TOP | wx.GROW)
> self.SetSizer(self.sizer)
> self.Fit()
>
>
> class App(wx.App):
>
> def OnInit(self):
> frame = CanvasFrame()
> frame.Show(True)
>
> return True
>
> app = App(0)
> app.MainLoop()
>
> If I comment the line : self.axes.set_xscale('log'), it works fine.
>
> python 2.6.4
> wxpython 2.8.10
> mpl 0.99
>
> Thanks by advance for your help.
> Cédrick
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA