matplotlib-users Mailing List for matplotlib

Jim,
 >Using matplotlib 0.74.
 >The default linestyle for contour lines representing values less than
 >zero should be dashed.
 >I have used this in the past ( I guess prior to 0.74) but now the
 >behavior is different.
 >The default appears to be a greyscale color map - all solid lines.
 >Looking at the code - line 768 of contour.py, the negative lines are
 >dashed if Ncolors == 1.
 >As far as I can tell, there is no way for this to be true. The code
 >change to rectify this is trivial,
 >but I may be missing something.
I made the change to which you refer, that is, adding the condition 
"Ncolors == 1" to the test for changing to dashed lines. My rationale 
is that the default is to color the lines with the default colormap, in 
which case the level information is in the colors, and making the 
negative values dashed just adds clutter. If the intent is to use 
simple black (or any other single color) lines, then one uses the kwarg 
"colors=('k',)" (for example), in which case Ncolors == 1, and the 
negative lines are dashed. This is illustrated in the attached script.
If you don't specify a colormap, the default is taken from your 
.matplotlibrc file if it exists, otherwise from the system default 
.matplotlibrc: specifically, the line
image.cmap : jet # gray | jet
The present system default is jet, not gray, so I presume it is your own 
.matplotlibrc file that is changing the default to gray.
Note that contour returns two arguments: a list of contour levels, and a 
corresponding list of LineCollections, which make it quite easy to 
change the line properties. If you want multicolored lines dashed for 
negative levels, you can do something like this:
levs, colls = contour(Z, cmap=hot())
for lev, coll in zip(levs, colls):
 if lev < 0:
 coll.set_linestyle((0, (6.,6.)),)
My inclination is to keep the default behavior rather simple, and let 
people customize as above. It is debatable whether the default even for 
single-color lines at negative levels should be dashed; I think a better 
design, more consistent with matlab and with the spirit of matplotlib, 
would be to leave this out.
We could also add support for a linestyles kwarg, similar to the 
linewidths kwarg that contour already accepts.
Eric

On 4/22/05, Pujo Aji <aj...@gm...> wrote:
> Error message:
> Microsoft Visual C++ Runtime Library
> Assertion failed!
> Program:c\python24\python.exe
> File:CXX/cxx_extentions.cxx
> Line:1031
>=20
> Expression: ob_refcnt =3D=3D 0
> For information on how your program can cause an assertion
> failure, see the Visual C++ documentation on asserts
>=20
> First I install in new computer python 2.4.1
> then the error comes out.
>=20
> So I tried to reinstall with python 2.4
> The problem still comes.
Hmm, that's a strange one. We've seen this once before
http://sourceforge.net/mailarchive/message.php?msg_id=3D8789882
and I can't remember what the solution was (the thread doesn't mention
it) but it was resolved. I've CCd Gregory on this email to see if he
can remember, since he once saw the same problem .
Are you using the python from python.org? Does it help if you remove
site-packages/matplotlib and then reinstall? Please create this
simple test script
 import pylab
 pylab.plot([1,2,3])
 pylab.show()
and run it with
> c:\python24\python myscript.py --verbose-helpful
and paste in all the output and errors in your response after doing a
clean reinstall, as well as your OS information ....
JDH

On 4/22/05, ch...@ll... <ch...@ol...> wrote:
 > There is beginning interest in this quality library=20
 > on AIX 5.x. Is a port planned, and when might it be
 > available?
I've never worked on AIX, but the steps there should be the same as
elsewhere -- mpl has been compiled on a number of UNIX boxes. Make
sure you have the dependencies on your system (zlib, libpng and
freetype with development headers). Add an entry in setupext.py in
the basedirs dictionary, where the key is your sys.platform and the
value is a list of paths in which matplotlib should search for
dependencies (eg /opt, /usr/local, whatever). You will probably have
the best luck trying to compile with gcc but this may not be an
option. If your compiler is C++ standards compliant, and the
matplotlib compile fails because of some noncompliant code, I'll treat
this as a bug and try and fix it. Unfortunately, I don't have access
to an AIX system which makes it a little slower to find and fix these
problems. Perhaps there is an AIX system on the sourceforge compile
farm -- anyone want to volunteer into looking into the compile farm
options :-) ?
Basically, I suggest you try following the instructions at
http://matplotlib.sf.net/installing.html and see how far you get, and
report the errors you get when tyring to compile as well as the
compiler you are using and other relevant information.
Good luck!
JDH