matplotlib-users Mailing List for matplotlib

I've been able to reproduce the problem on MacOSX (after the 
correction), although I don't have
an answer to what's causing it now.
Nadia Dencheva
On Jan 18, 2005, at 2:38 PM, Dominique Orban wrote:
> (Sorry, sending this again to correct a typo -- i inverted small and 
> large below)
>
> I have made several experiments; I have installed the latest matplotlib
> (with the 'contour' update) in both Win XP and SuSE Linux Pro 9.1. I
> made sure to uninstall everything pertaining to matplotlib before
> installing the latest version. In Windows, I use the pre-built
> distribution, and in Linux I compile it myself. The situation is this:
>
> - In Linux, some zigzagging lines appear when there are few points to
> interpolate. Eg, if i generate my grid from
> 	x = y = arange( -1, 1, delta ),
> zigzags would appear for LARGE values of delta (eg, delta = 0.2; ie 
> too few values of x and/or y). However, it seems that those zigzags 
> are a normal consequence of a large value of delta. For SMALLER 
> deltas, the contours are beautiful.
>
> - In XP, the same as above happens. But I see additional lines that
> don't seem to represent anything meaningful. I made sure I was
> performing a clean install. Are there updates to other packages I 
> should
> consider? Pygtk? This happened with both the TkAgg and GTKAgg backends.
> Perhaps I should try compiling matplotlib myself?
>
> If anyone is able to reproduce the problem, then it might indeed be a
> problem. If not, perhaps something is funny with my box.
>
> Thanks,
> Dominique
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>>>>> "Matt" == Matt Newville <new...@ca...> writes:
 Matt> Sorry for the confusion, that's not what I meant. I think
 Matt> that the acute sign would have to be added to the list of
 Matt> symbols that mathtext can handle. That would probably mean
 Matt> both special code in mathtext.py and an entry in
 Matt> _mathtext_data.py. I'm not sure what the right entry in the
 Matt> font table would be, as I don't understand the entries in
 Matt> the latex_to_bakoma dictionary in _mathtext_data.py at all.
I just added support for accents in general to mathtext. The
following accents are provided: \hat, \breve, \grave, \bar, \acute,
\tilde, \vec, \dot, \ddot. All of them have the same syntax, eg to
make an overbar you do \bar{o} or to make an o umlaut you do \ddot{o}.
The changes are in CVS - make sure you get mathtext.py revision 1.9 or
later, and _mathtext_data.py revision 1.5 or later.
Here is the test script I used:
 from pylab import *
 plot(range(10))
 title(r'$\ddot{o}\acute{e}\grave{e}\hat{O}\breve{i}\bar{A}\tilde{n}\vec{q}\dot{x}$', fontsize=20)
 show()
Hope this helps!
JDH
PS:
Matt, the _mathtext_data dictionary latex_to_bakoma maps the TeX
symbol to a fontfilename, glyph index tuple. To get the character
code in the font file corresponding to the glyph index, you can use
the FT2Font charmap dict
Here's a little demo script which shows you how to use the dict to
load a freetype2 glyph struct for a latex symbol "delta" from the
appropriate cm*.ttf file
 import os
 from matplotlib import get_data_path
 from matplotlib.ft2font import FT2Font
 from matplotlib._mathtext_data import latex_to_bakoma
 name, glyphind = latex_to_bakoma[r'\delta']
 fname = os.path.join(get_data_path(), name + '.ttf')
 font = FT2Font(fname)
 charmap = font.get_charmap()
 ccode = charmap[glyphind]
 glyph = font.load_char(ccode)
 print glyph.width/64.

>>>>> "Dominique" == Dominique Orban <Dom...@po...> writes:
 Dominique> If anyone is able to reproduce the problem, then it
 Dominique> might indeed be a problem. If not, perhaps something is
 Dominique> funny with my box.
A complete script which replicates the problem, w/ an attached saved
figure which shows it, would help immensely.
JDH

(Sorry, sending this again to correct a typo -- i inverted small and 
large below)
I have made several experiments; I have installed the latest matplotlib
(with the 'contour' update) in both Win XP and SuSE Linux Pro 9.1. I
made sure to uninstall everything pertaining to matplotlib before
installing the latest version. In Windows, I use the pre-built
distribution, and in Linux I compile it myself. The situation is this:
- In Linux, some zigzagging lines appear when there are few points to
interpolate. Eg, if i generate my grid from
	x = y = arange( -1, 1, delta ),
zigzags would appear for LARGE values of delta (eg, delta = 0.2; ie too 
few values of x and/or y). However, it seems that those zigzags are a 
normal consequence of a large value of delta. For SMALLER deltas, the 
contours are beautiful.
- In XP, the same as above happens. But I see additional lines that
don't seem to represent anything meaningful. I made sure I was
performing a clean install. Are there updates to other packages I should
consider? Pygtk? This happened with both the TkAgg and GTKAgg backends.
Perhaps I should try compiling matplotlib myself?
If anyone is able to reproduce the problem, then it might indeed be a
problem. If not, perhaps something is funny with my box.
Thanks,
Dominique

I have made several experiments; I have installed the latest matplotlib 
(with the 'contour' update) in both Win XP and SuSE Linux Pro 9.1. I 
made sure to uninstall everything pertaining to matplotlib before 
installing the latest version. In Windows, I use the pre-built 
distribution, and in Linux I compile it myself. The situation is this:
- In Linux, some zigzagging lines appear when there are few points to 
interpolate. Eg, if i generate my grid from
	x = y = arange( -1, 1, delta ),
zigzags would appear for small values of delta. However, it seems that 
those zigzags are a normal consequence of a small value of delta. For 
larger deltas, the contours are beautiful.
- In XP, the same as above happens. But I see additional lines that 
don't seem to represent anything meaningful. I made sure I was 
performing a clean install. Are there updates to other packages I should 
consider? Pygtk? This happened with both the TkAgg and GTKAgg backends. 
Perhaps I should try compiling matplotlib myself?
If anyone is able to reproduce the problem, then it might indeed be a 
problem. If not, perhaps something is funny with my box.
Thanks,
Dominique

Hello,
I am a big consumer of contour plots and it is great that matplotlib now 
features them. I didn't find the 'colors' argument to contour() 
intuitive to use though, and I wonder whether contour() should accept a 
colormap instance, much as imshow, so we can also display a colorbar.
Browsing through colors.py and cm.py it didn't appear clearly to me how 
all of that works. There is some info in the mailing list archives but I 
still didn't feel comfortable enough with such aspects of matplotlib to 
go ahead and modify contour().
Instead I wrote this simple class which returns a range of colors around 
the spectrum. There are as many colors as specified, and i use the same 
number as the number of levels in my contour plot. Perhaps this could be 
the default colors in contour()?
I don't mean to be reinventing the wheel; if there is a simpler way to 
do this with colormap instances, i'd love to know how.
===============
class mycolors:
 def __init__( self, nlevels ):
 jet6 = ( (0,0,1), (0,1,1), (0,1,0), (1,1,0), (1,0,0), (1,0,1) )
 self._jet6 = jet6
 if nlevels <= 6:
 jet = jet6[:nlevels]
 else:
 spectrum = linspace( 0, nlevels-1, 6 )
 for i in range( 6 ):
 spectrum[i] = round( spectrum[i] )
 # Initialize colors to black
 jet = []
 for i in range( nlevels ):
 jet.append( (0,0,0) )
 # Insert basic colors
 for i in range( 6 ):
 jet[ int( spectrum[i] ) ] = jet6[i]
 # Insert spectrum in each bin
 for i in range( 5 ):
 inthisbin = int( spectrum[i+1] - spectrum[i] - 1 )
 eps = 1.0/(inthisbin + 1)
 tones = linspace( eps, 1 - eps, inthisbin )
 thistone = [ jet6[i+1][0] - jet6[i][0],
 jet6[i+1][1] - jet6[i][1],
 jet6[i+1][2] - jet6[i][2] ]
 for j in range( inthisbin ):
 thiscolor = [ jet6[i][0] + thistone[0] * tones[j],
 jet6[i][1] + thistone[1] * tones[j],
 jet6[i][2] + thistone[2] * tones[j] ]
 jet[ int( spectrum[i] ) + j + 1 ] = tuple( thiscolor )
 self.jet = jet
 self.nlevels = nlevels
 def get_colors( self ):
 return self.jet
 def get_levels( self ):
 return self.nlevels
=================
Here is an example script where i use the same number of colors as levels:
from pylab import *
def rosenbrock(x,y): return 10*(y-x**2)**2 + (x-1)**2
x = y = arange( -2, 2, 0.1 )
X, Y = meshgrid( x, y )
Z = rosenbrock( X, Y )
nlevels = 30
cols = mycolors( nlevels )
contour( Z,
 x = X,
 y = Y,
 levels = nlevels,
 colors = cols.get_colors(),
 origin = 'lower' )
show()
If this is useful to anyone, feel free to use it.
Dominique

Hi,
I am trying to use mathtex expression for Molecule descriptions(in the legend)
[in matplotlib-0.70.1 tkagg backend]
The following mathtext expression throws an exception in the parser.
plot(range(10))
title(r'$^{12}\rm{CO}$') # a CO molecule
The following doesn't plot the superscript part of the mathtext in the legend:
r'$\rm{CO}^{2}$
whereas this one does:
r'$CO^{2}$' 
Can anyone reproduce this.
PS: Excellent plotting package! No greater pleasure than giving pgplot the 
boot and replace it with something "modern".
PPS: I think this ahs come up on the mailing list earlier, but I can't quite 
remember. Is it possible to tune "subplot" to do ganged plotting as in the 
example script without the overhead?
Cheers,
Malte.