matplotlib-users Mailing List for matplotlib

> So does the colorbar bug persist?
>

It appears to have been fixed!  The colorbar labeling automatically
determines the appropriate number of digits (or if scientific notation is
necessary) for the text labels on the colorbar.  You might want to
activate the tickfmt optional parameter that is still present in the
source code, as this gives the user direct control over the number of
digits displayed, but at least the labels can be distinguished in the
current version of the library.

Thanks!
Curtis

Fernando Perez pointed out that there was a problem with the src
distribution of matplotlib-0.63 and python2.2.

I fixed these, and uploaded matplotlib-0.63.4.tar.gz to the
sourceforge site.

Should work for python2.2, but w/o date or mathtext support.

JDH

>>>>> "Curtis" == Curtis Cooper <cu...@hi...> writes:

    Curtis> This worked.  I didn't realize I had to delete the
    Curtis> site-packages/matplotlib before installing over an old
    Curtis> version.

You don't normally, but this is usually my first line of defense when
something fails in one place that isn't failing in another.

So does the colorbar bug persist?

JDH

> Try rm -rf site-packages/matplotlib and the 'build' dir of your
> matplotlib install tree, and reinstall.

This worked.  I didn't realize I had to delete the
site-packages/matplotlib before installing over an old version.

John

Thank you for pointing me to the examples.

It works for me too.
Sorry to raise false alarm.

Regards David


-----Original Message-----
From: John Hunter [mailto:jdh...@ac...] 
Sent: 30 September 2004 14:44
To: david Powell
Cc: mat...@li...
Subject: Re: [Matplotlib-users] mathtext

>>>>> "david" == david Powell <dav...@kc...> writes:

    david> Thanks for previous help.  Using 0.63.2 I now cannot render
    david> TEX symbols.

    david> Has anyone else done this under Windows?

    david> I appear to have the right Bakoma fonts in
    david> D:\Python23\share\matplotlib.

    david> I tried creating the environment variable TTFPATH at the
    david> python prompt to point to this directory but no luck.

Works fine for me on windows XP.  Can you run the mathtext_demo.py at
http://matplotlib.sf.net/examples/mathtext_demo.py ?

What backend are you using - tkagg is the default and should be set in
D:\Python23\share\.matplotlibrc according to the info you provided
above.

JDH

 

 

             Hi John,

you're solution is working for the first problem but not for the second, 
the little tick are not changing (cf figure and script). The size of the 
tick lines are not change so they are not very visible if you change the 
size of the lines.


    Nicolas

script with the problem (but all errobar script will have the same I think):

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import sys
import numarray

from matplotlib.matlab import *
from math import *

sigma_final = 
numarray.array([74.8,172.27,206.,133.4,309.3,196.6,259.8,137.1,183.4 ])
sigma_error = numarray.array([49.6,69.54,11.4,91.2,45.7,15.9,37.3,50.,10.2])
sigma_emi   = numarray.array([80.,65.,130.,55.,108.,250.,60.,50.,50.])

ligne = numarray.array([0,400])

fonts = {
      'color'               : 'k',
      'fontname'         : 'Courier',
      'fontweight'       : 'bold',
      'fontsize'           : 'xx-large'
      }

figure(num = 1, figsize=(8, 8), dpi=100, facecolor='w', edgecolor='k')

xlabel('$\sigma 1$',fonts)
ylabel('$\sigma 2$',fonts)

errlines = errorbar(sigma_emi,sigma_final,sigma_error, fmt='o',capsize=5)
set(errlines, linewidth=3)

plot(sigma_emi,sigma_final,'s', linewidth=2)
plot(ligne,ligne, linewidth=2)

xticklabels = get(gca(), 'xticklabels')
set(xticklabels, 'fontsize', 'medium')
yticklabels = get(gca(), 'yticklabels')
set(yticklabels, 'fontsize', 'medium')

axis([0,360,0,360])

show()

John Hunter wrote:

>>>>>>"Humufr" == Humufr  <hu...@ya...> writes:
>>>>>>            
>>>>>>
>
>    Humufr>                       Hello, I found a problem with the
>    Humufr> function errorbar. I'm trying to change the width of the
>    Humufr> errorbar. The only way to do this seems to pass by the
>    Humufr> file .matplotlibrc and the default line width (it's not
>    Humufr> very useful I think and an option linewidth will be
>    Humufr> welcome in the errorbar function). The second problem is
>    Humufr> for the caps who are not change even with the global
>    Humufr> change (see figure in attachement).
>
>
>You can set the linewidth of the errorbar lines and caps by using the
>return value from errorbar
>
>  lines, errlines = errorbar(x,y,err)
>  set(errlines, linewidth=4)
>
>Let me know if this helps.  If not, please post a script that exposes
>the problem.
>
>JDH
>
>
>  
>

        Hi John,

this was the solution thanks. I was deleting the older .fonts.cache. I 
didn't notice the change, I'm apoligizing for the disturbance.

Thanks again,

       Nicolas


>Are you sure that you have Courier and Arial on your system and are
>they in your TTFPATH?
>
>If you are sure on both counts, it may help to remove your font cache
>(typically  ~/.ttffont.cache on linux like systems) and let matplotlib
>regenerate it's cache.  
>
>Those are my only ideas so far, let me know.
>
>JDH
>
>  
>

>>>>> "Jean-Michel" == Jean-Michel Philippe <jea...@ir...> writes:


    Jean-Michel> It seems that show() hangs if no figure has been
    Jean-Michel> created before calling (under matplotlib 0.62.4). Am
    Jean-Michel> I wrong or is it an unexpected use of show() ?

show should be the last line of your script.  It is expected to hang.
It starts the GUI mainloop after which all processing is done in the
GUI event handling (unless you are using threading).

See http://matplotlib.sf.net/faq.html#SHOW

JDH

>>>>> "david" == david Powell <dav...@kc...> writes:

    david> Thanks for previous help.  Using 0.63.2 I now cannot render
    david> TEX symbols.

    david> Has anyone else done this under Windows?

    david> I appear to have the right Bakoma fonts in
    david> D:\Python23\share\matplotlib.

    david> I tried creating the environment variable TTFPATH at the
    david> python prompt to point to this directory but no luck.

Works fine for me on windows XP.  Can you run the mathtext_demo.py at
http://matplotlib.sf.net/examples/mathtext_demo.py ?

What backend are you using - tkagg is the default and should be set in
D:\Python23\share\.matplotlibrc according to the info you provided
above.

JDH

 

 

>>>>> "Curtis" == Curtis Cooper <cu...@hi...> writes:

    >> Could you test this with 0.63 and if the problem persists post
    >> a minimal script that exposes the bug?

    Curtis> In matplotlib-0.63.0, I can't even get the examples
    Curtis> pcolor_demo.py and pcolor_demo2.py to work properly.  My
    Curtis> code mimics these examples closely.  Once they are working
    Curtis> again, I will send you an example of the colorbar tick
    Curtis> format issue.

Strange.  pcolor_demo.py and pcolor_demo2.py work fine for me on linux
and win32.

Try rm -rf site-packages/matplotlib and the 'build' dir of your
matplotlib install tree, and reinstall.

What, by the way, does it mean to "not work properly".  Is this a
crash?  Note an image interpolation bug was fixed in 0.63.0 which will
cause the axes limits to be a little different for imshow calls than
they were before.  Earlier versions of matplotlib set the viewlim to
hide the edge artifacts, which no longer exist.

JDH

On Tue, 2004-09-28 at 18:52, John Hunter wrote:
> Once you have
>    your n, bins from your custom function, you can call bar, just as
>    hist does.  Ie it's so easy to plot a histogram using bar that you
>    may not need to bother with altering the matplotlib.matlab hist.

I personally vote for this option.  I had a similar need just a couple
of days ago, namely creating a summed histogram from a number of
repeated simulations, and I just did the sums myself and called bar.  It
is probably best to keep matplotlib.matlab hist clean and simple.

Steve Walton

Thanks for previous help.

 

Using 0.63.2 I now cannot render TEX symbols.

Has anyone else done this under Windows?

I appear to have the right Bakoma fonts in D:\Python23\share\matplotlib.

I tried creating the environment variable TTFPATH at the python prompt to
point to this directory but no luck.

 

David

 

 

> Could you test this with 0.63 and if the problem persists post a
> minimal script that exposes the bug?

In matplotlib-0.63.0, I can't even get the examples pcolor_demo.py and
pcolor_demo2.py to work properly.  My code mimics these examples closely.
Once they are working again, I will send you an example of the colorbar
tick format issue.

Cheers,
Curtis

jdh...@ac... wrote:
> In truth, the latest release of matplotlib sets a flag on show to
> prevent repeated calls from doing any real damage.
> 
> But for classroom use, I suggest you just put "interactive : True" in
> your rc file and then you have no need for show.  Is there a downside
> to this approach?
> 
> JDH

It seems that show() hangs if no figure has been created before calling 
(under matplotlib 0.62.4). Am I wrong or is it an unexpected use of show() ?

JM. Philippe

John Hunter wrote:

>>>>>>"Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>>
>    Peter> doing this would be to incorporate it into the plot()
>    Peter> command. Perhaps adding an option 'steps' (following
>    Peter> gnuplot's convention could have steps equal 'histeps',
>    Peter> 'fsteps' or just 'steps' - see link above.. None could mean
>    Peter> regular plot() behavior).  I would say this would be the
>    Peter> most elegant option, but probably would call for John (or
>    Peter> someone else from the core developers) to make the
>    Peter> changes. Alternatively we could use above and wrap it in a
>    Peter> plot_step() function.
>
>    Peter> Any interest in this? If so which way do we want to go?
>
>It might be easiest to make this a line style.  Then you could use the
>builtin kwarg linestyle
>
>  plot(x, y, linestyle='steps')
>
>It shouldn't be too hard to modify lines.py to support this.  If you
>want to take a stab at it, I'd be happy to include it. 
>
Alrgith.. .this is my version of it.. just modifies lines.py (i'm using 
0.60.2 by the way).. :

    def _draw_steps(self, renderer, gc, xt, yt):
        siz=len(xt)
        if siz<2: return
        xt2=ones((2*siz,), xt.typecode())
        xt2[0:-1:2], xt2[1:-1:2], xt2[-1]=xt, xt[1:], xt[-1]
        yt2=ones((2*siz,), yt.typecode())
        yt2[0:-1:2], yt2[1::2]=yt, yt
        gc.set_linestyle('solid')
        gc.set_capstyle('projecting')
        renderer.draw_lines(gc, xt2, yt2)

also changed:

class Line2D(Artist):
    _lineStyles =  {
        '-'    : '_draw_solid',
        '--'   : '_draw_dashed',
        '-.'   : '_draw_dash_dot',
        ':'    : '_draw_dotted',
        'steps': '_draw_steps',
        'None' : '_draw_nothing'}
   
and:

lineStyles  = {'-':1, '--':1, '-.':1, ':':1, 'steps':1, 'None':1}

maybe a more memory friendly way to do this would be to loop through the 
arrays xt,yt and create extra points on the fly; then draw lines 
separately, but from my testing this current way seems (by far) the 
fastest.. im got lots of RAM and am in 'need for speed', so this works 
for me..


> The nice thing
>about making it a line style is that the changes required would all be
>contained to the lines.py file which is simple and clear.  If you
>change how plot processes its arguments, it's easy to foul things up.
>
>
yeah.. now that i know how things work a little better - i agree..

>The only potential problem I see is this would prevent you from, for
>example, having a dashed stepped line, since dash is itself a line
>style.  But who needs a dashed stepped line, for heaven's sake?
>
>
could always add.. 'steps--' if needed.. althought that's a little ugly!..

John Hunter wrote:

[...]

>    John> Sorry for the troubles
>
>Ditto
>
>JDH
>  
>
You can't be serious.   Think about it:  where else can we talk to the 
developer of the software, get our questions answered almost instantly, 
and our requests for features satisfied in a matter of weeks if not days 
or hours?   You have nothing to be sorry about.

-gary

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr>                       Hello, I found a problem with the
    Humufr> function errorbar. I'm trying to change the width of the
    Humufr> errorbar. The only way to do this seems to pass by the
    Humufr> file .matplotlibrc and the default line width (it's not
    Humufr> very useful I think and an option linewidth will be
    Humufr> welcome in the errorbar function). The second problem is
    Humufr> for the caps who are not change even with the global
    Humufr> change (see figure in attachement).


You can set the linewidth of the errorbar lines and caps by using the
return value from errorbar

  lines, errlines = errorbar(x,y,err)
  set(errlines, linewidth=4)

Let me know if this helps.  If not, please post a script that exposes
the problem.

JDH

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr> the different fonts available. I obtain:

    Humufr> ['Lucida Grande', 'Verdana', 'Geneva', 'Lucida',
    Humufr> 'Bitstream Vera Sans', 'Arial', 'Helvetica', 'sans-serif']

    Humufr> but if I'm trying to use the font Arial and italic in the
    Humufr> script that give me this message: Could not match
    Humufr> sans-serif, italic, normal.  Returning
    Humufr> /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf

    Humufr> It's seems that the change introduce in the script is not
    Humufr> use and that matplotlib are using only Vera fonts with no
    Humufr> style.


Note that this list does not mean that these fonts are available on
your system.  They are simply the fonts that matplotlib will look for
if you specify sans-serif.


    Humufr> fonts = { 'color' : 'k', 'fontname' : 'Courier',
    Humufr> 'fontweight' : 'bold', 'fontstyle' : 'italic', 'fontsize'
    Humufr> : 'xx-large'
    Humufr>       }


    Humufr> ylabel('toto',fonts)

    Humufr> give me exactly the same things than:

    Humufr> fonts = { 'color' : 'k', 'fontname' : 'Arial, 'fontweight'
    Humufr> : 'bold', 'fontstyle' : 'italic', 'fontsize' : 'xx-large'
    Humufr>       }


Are you sure that you have Courier and Arial on your system and are
they in your TTFPATH?

If you are sure on both counts, it may help to remove your font cache
(typically  ~/.ttffont.cache on linux like systems) and let matplotlib
regenerate it's cache.  

Those are my only ideas so far, let me know.

JDH

> Arrgg.  The matplotlib-0.63.1.win32-py2.3.exe file must have gotten
> clipped in transfer; it's broken.  I just uploaded
> matplotlib-0.63.2.win32-py2.3.exe; this *will work*.  These bug fix
> numbers are ticking like mad.

Yep, this works for me... Thanks!

--Matt

    John> This was a bug in the creation of the windows installer,
    John> which should have included these packages.  Grab
    John> matplotlib-0.63.1.win32-py2.3.exe from sf, which was just
    John> updated minutes ago after someone alerted me to this problem
    John> off-list.

Arrgg.  The matplotlib-0.63.1.win32-py2.3.exe file must have gotten
clipped in transfer; it's broken.  I just uploaded
matplotlib-0.63.2.win32-py2.3.exe; this *will work*.  These bug fix
numbers are ticking like mad.

    John> Sorry for the troubles

Ditto

JDH

On Tuesday 28 September 2004 16:48, John Hunter wrote:
> >>>>> "Dirk" ==   <rep...@we...> writes:
>
>     Dirk> John Hunter: Normally I wouldn't waste bandwith in a
>     Dirk> mailing-list by sending neither a question nor an answer,
>     Dirk> but in this case I feel the urge to thank you for your
>     Dirk> support. Your function does exactly what I need and you even
>     Dirk> gave a hint on how to implement such functional
>     Dirk> extensions. On top of that, the answer came an hour after I
>     Dirk> sent the question :-)
>
> Your welcome...

Hi John, 

I agree with Dirk on the precision and promptness of your responses to all our 
questions. I am always learning new things about matplolib (MPL) through 
theses Q&A exchanges. But since topic of bandwidth usage came up in this 
thread, for the sake of saving not only Sourceforge's but also JDH's 
bandwidth, I believe a documentation project for MPL should be started. I 
understand that you might not want to commit effort to document MPL now, 
since it's still under pretty intense development. However, starting a Wiki 
documentation project might be a good idea, since the user community could 
help by adding short tutorials  and recipes derived from their own experience 
with MPL. Moreover, the wiki could slowly evolve into a full blown 
documentation project.

What do you think?

cheers,

 Flavio
---

>>>>> "david" == david Powell <dav...@kc...> writes:

    david> When importing this version I find a dependency on PyTz and
    david> DateUtil.  After inspecting you mail archive I found urls
    david> for these packages but as a Windows user I am unable
    david> uncompress the DateUtil archive files.

This was a bug in the creation of the windows installer, which should
have included these packages.  Grab matplotlib-0.63.1.win32-py2.3.exe
from sf, which was just updated minutes ago after someone alerted me
to this problem off-list.

Sorry for the troubles,
JDH

When importing this version I find a dependency on PyTz and DateUtil.

 

After inspecting you mail archive I found urls for these packages but as a
Windows user I am unable uncompress the DateUtil archive files.

 

Any thoughts?

 

David

 

 

 

>>>>> "John" == John Hunter <jdh...@ac...> writes:


    John> setup.py now automatically detects Numeric, numarray or
    John> both, and compiles in the appropriate extension code.  Thus
    John> you can use matplotlib with either or both packages and
    John> still get the optimal performance.  So it is no longer
    John> necessary to set NUMERIX in setup.py, but it is necessary to
    John> have the extensions you want compiled available at the time
    John> you compile matplotlib.  The win32 build is for numarray
    John> 1.1.

Todd pointed out to me that the last statement is ambiguous.  The
windows installer is for Numeric *and* numarray-1.1.  Numeric doesn't
have a version number because all recent versions of Numeric are
binary compatible with one another.  numarray gets a version number
because numarray 1.1 is not binary compatible with 1.0 which is not
compatible with 0.9.  The numarray guys are hopeful that they have
achieved binary compatibility for future releases with 1.1 , and the
goal is to have a single matplotlib win32 installer that works with
all current Numeric and numarray, rather than what we used to do which
was a different installer for Numeric and each version of numarray.

JDH

Hello! 

I have tried using matplotlib with pygtk 2.2 and everything worked fine.
But when I try to compile matplotlib (0.62.4) with the newest version of 
pygtk, pygtk-2.3.96, I get the error included below.  Since this pygtk 
version is still in development, this might as well be a bug in pygtk. 

Maybe you can help me solve my problem,

Niklas.

--------------------------------------------
building 'matplotlib.backends._gtkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O3 -march=i486 -mcpu=i686 -fPIC -I/u
sr/local/include -I/usr/include -Isrc -Iagg2/include -I. -I/usr/local/include -I
/usr/include -I/usr/local/include/freetype2 -I/usr/include/freetype2 -Isrc/freet
ype2 -Iagg2/include/freetype2 -I./freetype2 -I/usr/local/include/freetype2 -I/us
r/include/freetype2 -I/usr/local/include -I/usr/include -I/usr/include/pygtk-2.0
 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/u
sr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X1
1R6/include -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0
/include -I/usr/include/python2.3 -c src/_gtkagg.cpp -o build/temp.linux-i686-2.
3/src/_gtkagg.o -DNUMARRAY
In file included from /usr/include/python2.3/Python.h:8,
                 from /usr/include/pygtk-2.0/pygobject.h:5,
                 from src/_gtkagg.cpp:8:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/include/string.h:26,
                 from /usr/include/c++/3.3.4/cstring:51,
                 from src/_gtkagg.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the previous def
inition
In file included from src/_gtkagg.cpp:8:
/usr/include/pygtk-2.0/pygobject.h:124: error: parse error before `typename'
/usr/include/pygtk-2.0/pygobject.h:131: error: parse error before `typename'
error: command 'gcc' failed with exit status 1

________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193