matplotlib-users Mailing List for matplotlib (Page 12)

On Tue, 6 Sep 2005, Christian Meesters wrote:
> Hi
>
> It's certainly no important problem and there are ways to work around
> it, but I was wondering whether there is a way to do it directly using
> matplotlib.
> My 'problem' is as follows: My detector does not detect at all times;
> in case nothing is detected a 0 is written in the data-file. So what I
> end up with are data like [0,0,1000,1001,999,0,1000 ...], which - of
> course - looks a bit odd, when plotted. (The 0s are meaningless.) Is it
> possible to plot only values unequal to zero?
What about using compress before plotting:
In [1]: from Numeric import *
In [2]: x=arange(10)
In [3]: x
Out[3]: array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
In [4]: xred=compress(x>0,x)
In [5]: xred
Out[5]: array([1, 2, 3, 4, 5, 6, 7, 8, 9])
> Or is there any other way
> to 'mask' data which should be skipped for the plot?
There are also masked arrays in matplotlib, maybe
some else has a simple example.
Best,
Arnd

On Tuesday 06 September 2005 9:42 am, Rob Hetland wrote:
> When I try to pcolor a large array, say a few hundred elements in
> each dimension with text.usetex:True set in the rc file, pcolor gives
> an error. [Mac OS X 10.4, python 2.4.1, matplotlib 0.83.2, TkAgg
> backend]
>
> Plotting smaller arrays, or not using TeX gives no error.
Please post an example and the error message.
Darren

Hi
It's certainly no important problem and there are ways to work around 
it, but I was wondering whether there is a way to do it directly using 
matplotlib.
My 'problem' is as follows: My detector does not detect at all times; 
in case nothing is detected a 0 is written in the data-file. So what I 
end up with are data like [0,0,1000,1001,999,0,1000 ...], which - of 
course - looks a bit odd, when plotted. (The 0s are meaningless.) Is it 
possible to plot only values unequal to zero? Or is there any other way 
to 'mask' data which should be skipped for the plot?
Thanks a lot in advance,
Christian

When I try to pcolor a large array, say a few hundred elements in 
each dimension with text.usetex:True set in the rc file, pcolor gives 
an error. [Mac OS X 10.4, python 2.4.1, matplotlib 0.83.2, TkAgg 
backend]
Plotting smaller arrays, or not using TeX gives no error.
-Rob.
-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

Hello everyone,
when using errorbar() it is possible to change the attributes (linethickness
etc.) with setp(). This works really well.
But on the otherhand when you try to set the attributes within the
errorbar()-command it will not work - see the exapmle below.
Finding this a bit disturbing I took a look at "axes.py" where errorbar() is
placed. I found out that the drawing of those bars and caps (also
just beeing lines) are added to the plot without the "**kwargs".
Credulously and optimistic I just added it there and - of course - got an
errormessage. So I made a copy of kwargs in the method errorbar() and poped
out all the keywords which could be problematic (I only found out 'marker',
'ls' and 'linestyle') by
kwargs_bars = kwargs.copy() # make copy of kwargs (not only a
 # pointer)
if kwargs.has_key('marker'): # Is the 'marker' keyword given in
 # kwargs?
 marker=kwargs_bars.pop('marker')# filter this entry out (would raise
 # error "duplicate keyword argument")
if kwargs.has_key('ls'): # Is the 'ls' keyword given in kwargs?
 marker=kwargs_bars.pop('ls') # filter this entry out (vlines, hlines
 # would not be drawn)
if kwargs.has_key('linestyle'): # Is the 'linestyle' keyword given
 marker=kwargs_bars.pop('linestyle') # in kwargs?
and then added **kwargs_bars to the following vlines, hlines and plots:
barlines.extend( self.hlines(y, x, left,**kwargs_bars) )
barlines.extend( self.hlines(y, x, right,**kwargs_bars) )
caplines.extend( self.plot(left, y, '|', ms=2*capsize,**kwargs_bars) )
caplines.extend( self.plot(right, y, '|', ms=2*capsize,**kwargs_bars) )
and also for yerr.
Now the example below worked fine.
I'm now thinking of two things - the second one of them beeing a
possible drawback.
 i) I'm not sure if other keywords should also be poped out. I can't imagine
any further problems - but we all know that this means completely
nothing in the wide field of possible errormessages ;-)
ii) Like before you have the ability to set the color of the cap- and
barlines seperatly from the color of the line connecting the points.
The problem mentioned above (you can't change the thickness of the caps and
bars from the errorbar()-command) still persists for 'linestyle'. Therefor
I'm not sure if the confusion existing before is cleared away. Propably not.
Just imagine a user: "I would like to change the style of the bars and caps
to '-.'. Why do I have to use setp() instead of giving it to errorbar()?"
But I hope that the changes in axes.py are helpful.
Bye,
Martin
PS: Would it be more agreeable if I try to create a patch ruther
then sending the codesnippets? If yes: could anyone give me a hint on how
to find information about patches (how t omake them, how to apply
them)?
Thanks!
#-------------------------------------------------------------------------------
"""This little program shows that it makes an enormous difference
 where the properties of the errorbar()-command are set.
 a) within the command errorbar(...)
 b) seperately with an setp() command
"""
from pylab import *
N=20
x = 1.0*arange(N)/(N-1)
yerrors = .02*rand(N) # errors in y
xerrors = .02*rand(N) # errors in x
y = exp(-x) # plain curve
figure(1)
subplot(121)
print ("Left : If the features are set with setp() everything works out
fine.")
error_plot_1 = errorbar(x,y, yerr=yerrors,xerr=xerrors,
 ls='none',ecolor='r')
setp(error_plot_1,linewidth=3,markeredgewidth=2)
subplot(122)
print ("Right : But if one uses the command errorbars() itself not.")
error_plot = errorbar(x,y, yerr=yerrors,xerr=xerrors,
 ls='none',ecolor='r',
 linewidth=3,markeredgewidth=2)
show()
-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Christian Kristukat wrote:
> Hi,
> is it possible to have an image map (imshow) with real axes like those 
> created
> by 'contour' when supplying a xy meshgrid? The pcolor command unfortunately
> doesn't do interpolation.
> Regards, Christian
> 
> 
This would be useful for me too, as I need to display an imshow with 
nonuniform axes.
João Silva

Hi,
is it possible to have an image map (imshow) with real axes like those created
by 'contour' when supplying a xy meshgrid? The pcolor command unfortunately
doesn't do interpolation.
Regards, Christian

Hello everyone, 
Hello Mark,
what I meant with
>> 1) Unfortunetly this history seems not to work properly in some cases. I
>> was able to track down this error on the call of the subplot-command
[...].
is that neither the positioning nor the limits are restored. To be precise:
They are not restored incorrectly; nothing happens if the buttons are
pressed. (To be correct: The zoomhistory works only back to the last click
which had an connected event. This state seems to be set as new 'home' - see
the example which I sent the last time.)
Thanks for your Mail,
Martin
-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

> We special cased numerical superscripting (10^3) to make log plots
> faster and to keep the fonts consistent. But we haven't done this for
> general superscripting. Note that there is a bug in the current
> text.py which prevents event this from working, as Arnd Baeker noted
> in a recent post. Fortunately, it is a one line fix so if you do need
> this feature make the corrections suggested there. Also, you could
> hack rgxsuper in text.py to match a larger class of strings, which
> would give you at least superscripting w/o mathtext or TeX.
Aaah... sounds like this is not the end of the road. I'll take a look at 
rgxsuper then. There is no example around, is there?
> May I ask, why you want to avoid mathtext? My guess is that you don't
> like the fonts, and this is perfectly understandable. I would like to
> rewrite mathtext to work with arbitrary fonts rather than the cm*
> ones, but it is a question of time and priorities.
You are exactly right - the fonts are not to my liking. Also, I have some 
trouble getting TeX to work with MPL (I am developing on Win32, but 
deploying on a Linux box) so that I was hoping to get around it.
Thanks a lot!
Sascha 

Darren Dale wrote:
> On Monday 05 September 2005 10:21 am, Howey, David A wrote:
>>In theory this should work, but although most of the properties seem to
>>have an effect (eg if I change from sans-serif to serif it clearly looks
>>different), the size property stubbornly refuses to change the size of
>>the text. Eg. 'large', 'small' and 'xx-small' all look the same. If you
>>don't believe me I can post some pictures.
> 
> 
> You need to change tick.labelsize and axes.labelsize.
Mmh, as an outsider to the discussion, may I suggest that this sounds like a 
minor API consistency or ease of use buglet? I know that mpl has a million 
knobs that can be tweaked, but in the interest of making it as 
self-discoverable as possible, I'd suggest that collecting all text properties 
under a unified header would make things easier. I just had a look at the mpl 
rc file, and it seems like the font size settings are done in (at least) 4 
separate places:
font.size : medium
axes.titlesize : 14 # fontsize of the axes title
axes.labelsize : 12 # fontsize of the x any y labels
tick.labelsize : 12 # fontsize of the tick labels
Furthermore, one of them uses Latex-style relative settings (small, medium, 
etc) and the others use fixed point sizes, while it's not clear if those three 
can also take relative expressions.
This is likely to confuse a newcomer (as David's hunt revealed), and it seems 
an unnecessarily complex default. Here's an idea for a different set of settings:
font.size.default : medium
font.size.axes_title : auto
font.size.axes_label : auto
font.size.tick_label : auto
The behavior would be (suitably commented in the file):
 - font.size.default controls the default choice of font size, and all the 
others are chosen as default values (hopefully good ones) relative to that.
 - If you are happy with the relative choices made by MPL, just changing 
font.size.default up or down will scale all your font sizes in that direction. 
 This makes it easy, for example, to quickly rebuild a plot for a talk with 
larger fonts everywhere.
 - If you really want to tweak each font size setting by hand, you can do so 
by specifying its value directly. The 'auto' value will make it revert to the 
mpl relative-to-font.size.default autosizing decision.
I think something like this has the dual advantages of being easier to find by 
anyone on their own (all font size attributes are under font.size) and 
simultaneously providing easy global tuning with full freedom for fine tweaking.
I realize that this brings the reverse problem: what if a user is tweaking 
with axes properties and doesn't find the font sizes for axes there? In the 
interest of auto-discovery, shouldn't all axes (or ticks) properties live 
under axes/ticks? This is a valid concern, an inescapable problem of 
hierarchical organizations whenever something can reasonably appear in more 
than one place.
*nix filesystems solve this nicely with symlinks. I don't know if that kind 
of effort is really needed here, and perhaps a simple comment in the rc file 
would suffice. But if dynamic auto-discovery is desirable (via setp or 
tab-completion, for example), comments in a text file won't suffice. In that 
case, perhaps the rc machinery could support something akin to symlinks, where 
one could say:
axes.labelsize = link(font.size.axes_label)
and this would actually report as such at runtime. This would allow keeping 
the defaults in one place, while still letting some things appear more than 
once if that makes conceptual sense.
I know this may sound to some like overkill, but if John went ahead and 
implemented matplotlib GUI widgets, I dont' see why we can't also have a mpl 
filesystem with symlinks! It would certainly help as we ramp up for the alpha 
release of the famed MDE (Matplotlib Desktop Environment) ;)
Just an idea...
Cheers,
f
ps - in case it wasn't clear, only the last paragraph was a joke. The actual 
linking proposal is perfectly serious, and not hard to implement.

>>>>> "Sascha" == Sascha GL <Sas...@gm...> writes:
 Sascha> Is there any chance to get subscript / superscript
 Sascha> formatting for text in Matplotblib without using TeX or
 Sascha> Mathtext?
We special cased numerical superscripting (10^3) to make log plots
faster and to keep the fonts consistent. But we haven't done this for
general superscripting. Note that there is a bug in the current
text.py which prevents event this from working, as Arnd Baeker noted
in a recent post. Fortunately, it is a one line fix so if you do need
this feature make the corrections suggested there. Also, you could
hack rgxsuper in text.py to match a larger class of strings, which
would give you at least superscripting w/o mathtext or TeX.
May I ask, why you want to avoid mathtext? My guess is that you don't
like the fonts, and this is perfectly understandable. I would like to
rewrite mathtext to work with arbitrary fonts rather than the cm*
ones, but it is a question of time and priorities.
If you tell us why you don't want to use TeX or mathtext, we might be
better positioned to suggest alternatives or workarounds.
JDH

>>>>> "Howey," == Howey, David A <d....@im...> writes:
 David> Brilliant! It works! Hurrah. I have to say that that is
 David> not immediately obvious to a newbie. I would have expected
 David> the rc file setting to work. Oh well... Thanks
Well, the rc setting does work, just not the one you expected. I
updated the rc file to read
 # note that font.size controls default text sizes. To configure
 # special text sizes tick labels, axes, labels, title, etc, see the rc
 # settings for axes and ticks
 font.size : medium 
Glad you got it working.
JDH

Brilliant! It works! Hurrah. I have to say that that is not immediately
obvious to a newbie. I would have expected the rc file setting to work.
Oh well... Thanks
Dave
-----Original Message-----
You need to change tick.labelsize and axes.labelsize.
Darren

On Monday 05 September 2005 10:21 am, Howey, David A wrote:
> >> Can anyone help with this?
> >> Thanks
> >> Dave
> >
> >Try changing the text size in your matplotlibrc file.
>
> In theory this should work, but although most of the properties seem to
> have an effect (eg if I change from sans-serif to serif it clearly looks
> different), the size property stubbornly refuses to change the size of
> the text. Eg. 'large', 'small' and 'xx-small' all look the same. If you
> don't believe me I can post some pictures.
You need to change tick.labelsize and axes.labelsize.
Darren

>> Can anyone help with this?
>> Thanks
>> Dave
>Try changing the text size in your matplotlibrc file.
In theory this should work, but although most of the properties seem to
have an effect (eg if I change from sans-serif to serif it clearly looks
different), the size property stubbornly refuses to change the size of
the text. Eg. 'large', 'small' and 'xx-small' all look the same. If you
don't believe me I can post some pictures.
Anyone else experience this? I'm using Ipython and Matplotlib on
WindowsXP.
Dave

Hi,
I have another question:
Is there a way to change the linewidth of the ticks?
For the borders I use
 rcParams["axes.linewidth"]=4
but there seems to be no
 rcParams["tick.linewidth"]=2
Best,
Arnd

On Fri, 2 Sep 2005, John Hunter wrote:
> >>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
[...]
> Arnd> different behaviour when changing the order of
> Arnd> `axis("equal")` and `axis([-0.35,2.1,-0.2,1.25])` persists.)
>
> It is not surprising that the order makes a difference.
To be honest, from a user perspective such effects
are very problematic and I would usually considered as a bug.
Together with Martin Richter I had a closer look at this:
 a) pylab.py, axis(...):
 I think, that the command
 ` axis([0.5,1.0,-2.0,5.0])` should,
 whenever `ax.get_aspect() == 'equal'`,
 recompute the aspect.
 This could be achieved by calling
 ax.set_aspect(recompute=True)
 before the corresponding `draw_if_interactive()`
 and the set_aspect routine in axes.py would read at the beginning:
 def set_aspect(self,aspect='normal',fixLimits=False,alignment='center',
 recompute=False):
 [...]
 if recompute:
 try:
 aspect=self._aspect
 fixLimits=self._fixLimits
 alignment=self._alignment
 except AttributeError:
 return
 self._aspect=self.aspect
 self._fixLimits=fixLimits
 self._alignment=alignment
 b) For axes.py, set_aspect, it seems better to us
 to restore the originalPosition:
 else: # Change limits on axes
 #l,b,w,h = self.get_position() # Keep size of subplot
 # ---> # restore changes which could have come from
 # ---> # a previous call axes("scaled"), i.e. fixLimits=True:
 l,b,w,h = self._originalPosition
 self.set_position( (l,b,w,h) )
 # --->
 axW = w * figW; axH = h * figH
a) should ensure that it does not matter when a range is set
b) should ensure that after an `axis("scaled")`
 an `axis("equal")` gives the same result
 as if the `axis("scaled")` was not given before.
I am not sure if the above has any unwanted side-effects.
At least it gets rid of a couple of the ordering
effects.
> When
> correcting for the aspect ratio, either the data limits, window
> limits, or both have to change. The default is to change the data
> limits, but you can control this by calling
>
> ax.set_aspect(aspect='equal', fixLimits=True)
>
> This is the function that axis('equal') calls, and by using it
> directly you can tweak some of the default behaviors. See the
> docstring for set_aspect (in CVS) for more information.
I don't like the name `fixLimits` to much, because
it sounds as if something has to be fixed (but nothing is broken, IMHO).
What about `fixedLimits`?
(Sorry if I am showing off my English deficiencies here ...)
While at this: I also don't like `autoscale_on` very much.
I think that `autoscale` (being True or False) would be enough.
And one more (just to complicate matters even more):
At the moment there is only autoscaling for x and y
at the same time. Gnuplot, for example, allows
to specify the xrange or yrange separately and the
other range is autoscaled.
I am mentionining this, because it might be a useful feature.
(However, it might make the coding of
the autoscaling even more involved...).
> This is fairly new functionality so let us know if this works for you.
> It might be a good idea for someone to start a wiki entry on the
> various issues of axes aspect ratio.
I hope that everything can be done easily just by using
`axis(...)`. A few examples would be very good for the
wiki (or the demo). I could provide these (after
I am back from a conference next week...).
Best,
Arnd

Hello John,
it was pretty easy to rewrite the (formally called) LineSelector so that the
callback-function now awaits two events (press and release). Now it is
possible to use the different mousebuttons. (By the way: It is checked if
press- and releasebutton are the same.)
If you want to include the RubberbandWidget - please feel free to do so.
I took the latest CVS, tried it again with GTKAgg, WXAgg and TkAgg and (as
you said) it worked fine!
Thanks,
Martin
-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

On Monday 05 September 2005 8:43 am, Howey, David A wrote:
> Can anyone help with this?
> Thanks
> Dave
Try changing the text size in your matplotlibrc file.
>
> -----Original Message-----
> From: mat...@li...
> [mailto:mat...@li...] On Behalf Of
> Howey, David A
> Sent: 02 September 2005 12:42
> To: mat...@li...
> Subject: [Matplotlib-users] Text size
>
> I'm trying to change the font size of the x and y tick numbers on some
> plots but finding it a bit tricky - would appreciate some input from a
> seasoned matplotlib user.
>
> Basically, I like the way matlab sizes the text on its plots. This is
> best illustrated by looking at pages 6 and 7 of the matplotlib user
> guide. On page 6 is a matlab plot, and page 7, the matplotlib
> equivalent. The matlab plot has nice small numbers on the axes, whereas
> the matplotlib plot has quite big, chunky numbers. Is there any easy way
> to permanently force matplotlib to render the axis numbering with
> smaller numbers, more like the matlab example?
>
> Thanks
>
> Dave Howey
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...
http://people.ccmr.cornell.edu/~dd55/

is there any more information you'd like to help me =20
with constructing a legend for this scatter?
i think i am misusing the scatter graph here... =20
letting scatter assign colours from a continous =20
selection rather than specifying a color.
please help,
jack
On 03/09/05 14:22:33, Jack Andrews wrote:
> I could guess at what you are trying to do, but =20
> it would help a lot if you posted an example =20
> that we could run, with comments about what you =20
> want to happen versus what is happening.
thanks... attached is an image of roughly what i =20
want. a program is below.
#!/usr/bin/python
from pylab import *
N=3D20
def xycs():
 x,y=3Dresize(rand(2*N),(2,N))
 x[:N/2]*=3D2;y[:N/2]/=3D2;
 c=3Darray([0]*(N/2)+[1]*(N/2))
 s=3Darray(([400]+[30]*(N/2-1))*2)
 print zip(c,s)
 p=3Dscatter(x,y,c=3Dc,s=3Ds,faceted=3D0)
 grid(True)
 setp(p, 'alpha', 0.75)
 savefig('scat_lgnd.png')
 show()
 return 0
if __name__=3D=3D'__main__':
 xycs()
---- _I v o r y__K i t e____
jack andrews
university of mordialloc
vic australia ef...@iv...

Can anyone help with this?
Thanks
Dave=20
-----Original Message-----
From: mat...@li...
[mailto:mat...@li...] On Behalf Of
Howey, David A
Sent: 02 September 2005 12:42
To: mat...@li...
Subject: [Matplotlib-users] Text size
I'm trying to change the font size of the x and y tick numbers on some
plots but finding it a bit tricky - would appreciate some input from a
seasoned matplotlib user.
Basically, I like the way matlab sizes the text on its plots. This is
best illustrated by looking at pages 6 and 7 of the matplotlib user
guide. On page 6 is a matlab plot, and page 7, the matplotlib
equivalent. The matlab plot has nice small numbers on the axes, whereas
the matplotlib plot has quite big, chunky numbers. Is there any easy way
to permanently force matplotlib to render the axis numbering with
smaller numbers, more like the matlab example?
Thanks
Dave Howey
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Is there any chance to get subscript / superscript formatting for text in
Matplotblib without using TeX or Mathtext? 
TIA,
Sascha
-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

Arnd> P.S.: BTW: splattering the prints around seems like 
Arnd> poor-mans debugging ;-) Are there better solutions 
Arnd> available? 
The logging module allows you to use essentially the same 
strategy with a finer level of control.
fwiw,
Alan Isaac

>>>>> "Arnd" == Arnd Baecker <arn...@we...> writes:
 Arnd> I think the expression is alright: I looked at
 Arnd> matplotlib/text.py - class Text. It seems that for this
 Arnd> example the routine does not pass by the first use of
 Arnd> self._rgxsuper:
It looks like you're right -- good catch. It should read
 if ismath=='TeX': m = None
 else: m = self._rgxsuper.match(self._text)
 if m is not None:
 bbox, info = self._get_layout_super(self._renderer, m)
 Arnd> P.S.: BTW: splattering the prints around seems like
 Arnd> poor-mans debugging ;-) Are there better solutions
 Arnd> available?
It is certainly poor-man's debugging, but it is a time honored
tradition that has served me well. Of course, you could use the
python debugger, and it sometimes helps to embed an ipython shell in
the code
 from IPython.Shell import IPShellEmbed
 ipshell = IPShellEmbed()
 ipshell() # this call anywhere in your program will start IPython 
If you place this inside a function, a shell will pop up with the
local namespace which you can then inspect.
JDH

On Sat, 3 Sep 2005, Darren Dale apparently wrote: 
> I have wondered why the origin of the bbox was shifted in 
> eps files, but it shouldn't matter.
I agree is should not matter. But it does for GhostScript's 
pdfwrite.
> Seeing as how dvips, ps2pdf, and epstopdf all work as 
> expected, it sounds like a dvipdfm bug to me. 
If it is a bug (and I also believe it is), it's a pdfwrite 
bug, assuming that pdfwrite should know how to produce 
encapsulated PDF, which has been treated as the case by many 
people for many years.
> I don't think its a good idea to limit the size of eps 
> figures. At some point, I will make eps files that are 
> larger than A4 for use in posters. 
As you said, it should not matter.
And it will make pdfwrite work as expected.
Cheers,
Alan Isaac