matplotlib-users Mailing List for matplotlib (Page 1411)

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:


    Alan> So this is almost a feature request.  The only problem is
    Alan> that gnuplot's size command does not seem obviously suited
    Alan> to the matplotlib.matlab model, and I'm not sure what a good
    Alan> version would be.  I think it would be something like "get
    Alan> the current axis, keep the "long" axis (as implied by the
    Alan> ratio) full length, and "shrink" the shorter axis as
    Alan> necessary to achieve the right ratio.  This would respect
    Alan> the existing margins to everywhere except by the shrinking
    Alan> axis.  However it would probably be better to adjust the
    Alan> figure size as well, to keep the margins unchanged.

I'm not fully understanding you, in part because I find the
terminology ambiguous. Could you give an example of what you want to
achieve (eg a scatterplot with a square viewing window).  For
concreteness, we have

    ylim / xlim   : the data view limits
    axh  / axw    : the axes height / width, relative coords 0-1
    figh / figw   : the figure width and height in inches
    dpiy / dpix   : the display devices resolution in pixels in the
                    vertical and horizontal directions

In order to get true physical sizes and ratios, we need to know dpiy
and dpix.  matplotlib currently only supports a single dpi, though it
is still possible to hack true sizes by adjusting for example, figh
and figw to compensate for variation in dpiy and dpix.

It is certainly possible to provide some helper functions to create a
properly sized and scaled figure and axes with a desired aspect ratio
or physical size.  

JDH

Setting the compression ratio to unity is important
for some graphs.  (Definition: compression ratio =
aspect ratio of viewing window/aspect ratio of viewport).
In gnuplot you do this by simply setting
set size ratio vwar
where vwar is the aspect ratio of the viewing window,
as determined by previous xrange and yrange commands.

I believe the following is the procedure in
matplotlib.matlab:
i. set the figsize
ii. use the axes command to set the propert viewport aspect
ratio, which requires careful attention to figsize (and of
course knowledge of the limits to be set with the axis
command)
iii. plot your graph
iv. use the axis command to set the aspect ratio of the
viewing window

My description is a bit verbose, but it may nevertheless
highlight some nice things about gnuplot's size command.
(Or I may have missed the obvious way to do this.)
This doesn't matter much in scripts, but for interactive
use (e.g., classroom demonstration) it is nice to keep
things as simple and straightforward as possible.

So this is almost a feature request.
The only problem is that gnuplot's size command does
not seem obviously suited to the matplotlib.matlab model,
and I'm not sure what a good version would be.
I think it would be something like "get the current axis,
keep the "long" axis (as implied by the ratio) full length,
and "shrink" the shorter axis as necessary to achieve the
right ratio.  This would respect the existing margins to
everywhere except by the shrinking axis.  However it would
probably be better to adjust the figure size as well, to
keep the margins unchanged.

fwiw,
Alan

jm...@st... wrote:
> I took a quick look at this and my impression is that clipboard support
> must be explicitly added to the TkAgg backend and AFIK has not been.  My
> guess is that this is a wider reaching problem than TkAgg and it should
> go into the list of future enhancements for matplotlib.
> 
> Regards,
> Todd

It sounds more complicated than I thought. Indeed I was searching for 
existing solutions that would copy the window contents into clipboard. I 
know it is quite easy to do with Tcl/Tk and the BLT extension or 
something similar. You just call a function with the window path as arg 
and your clipboard is filled. This is why I focused on TkAgg.

Thanks.

JM.

Darren,

Sorry that I forgot the code suppose that would have helped =). 
Actually I just figured out the problem, it didnt like me h aving the 
show command before the savefig command, i took it out and it worked. 
But thanks for offering to help.

Thanks ,

Jeremy

----- Original Message -----
From: Darren Dale <dd...@co...>
Date: Saturday, September 11, 2004 1:53 pm
Subject: Re: [Matplotlib-users] problem using savefig

> Hi Jeremy,
> 
> Will you post some code so I can try to reproduce your problem?
> 
> Darren
> 
> Jeremy Martin wrote:
> 
> >List,
> >
> >Im not sure if this is just me not fully understanding matplotlib 
> 100 
> >percent yet, but when I try to use savefig to save one of my 
> graphs to 
> >a png or jpeg file, all i get is an all white image with none of 
> the 
> >data on it. Im using wxpython 2.4, python 2.3, im on windows XP 
> and am 
> >using the latest matplotlib form sourceforge.net.
> >
> >Thanks for any help,
> >
> >Jeremy
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> >Project Admins to receive an Apple iPod Mini FREE for your 
> judgement on
> >who ports your project to Linux PPC the best. Sponsored by IBM. 
> >Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> >_______________________________________________
> >Matplotlib-users mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >  
> >
> 
> 

Hi Jeremy,

Will you post some code so I can try to reproduce your problem?

Darren

Jeremy Martin wrote:

>List,
>
>Im not sure if this is just me not fully understanding matplotlib 100 
>percent yet, but when I try to use savefig to save one of my graphs to 
>a png or jpeg file, all i get is an all white image with none of the 
>data on it. Im using wxpython 2.4, python 2.3, im on windows XP and am 
>using the latest matplotlib form sourceforge.net.
>
>Thanks for any help,
>
>Jeremy
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM. 
>Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>  
>

List,

Im not sure if this is just me not fully understanding matplotlib 100 
percent yet, but when I try to use savefig to save one of my graphs to 
a png or jpeg file, all i get is an all white image with none of the 
data on it. Im using wxpython 2.4, python 2.3, im on windows XP and am 
using the latest matplotlib form sourceforge.net.

Thanks for any help,

Jeremy

I took a quick look at this and my impression is that clipboard support
must be explicitly added to the TkAgg backend and AFIK has not been.  My
guess is that this is a wider reaching problem than TkAgg and it should
go into the list of future enhancements for matplotlib.

Regards,
Todd

On Fri, 2004-09-10 at 07:41, Jean-Michel Philippe wrote:
> Hello,
> 
> Does anyone know if there is a way to copy a figure to the clipboard? I 
> didn't find any suitable method for the figure window using TkAgg. As 
> figures can be recorded into image files, it should be possible to copy 
> them to clipboard too.
> 
> Regards.
> 
> JM. Philippe
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM. 
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 

Hello,

Does anyone know if there is a way to copy a figure to the clipboard? I 
didn't find any suitable method for the figure window using TkAgg. As 
figures can be recorded into image files, it should be possible to copy 
them to clipboard too.

Regards.

JM. Philippe

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> Gee, some people are never satisfied!

You should know me by now :)

> In IPython/Shell.py on or around line 424, replace the mainloop
> function with 
[...]

Great, I just put it in CVS.  Many thanks!

> Incidentally, this or some other change appears to fix the GTK OSX
> confirm on exit bug (the only other change here is that I call 'start'
> after the threads_init call).
> 
> Thus I can happily report that with this change and the one you
> included in CVS yesterday for output redirection in wx, all the
> backends seem to be working across all the major platforms in ipython.
> 
> And there was much rejoicing.

Indeed!  So it seems like the little matrix you sent yesterday now reads:

            linux        win32     OSX
     GTK* : good         good	  good
     WX*  : good         good      good
     TK*  : good         good      good

:)

I think I'm actually going to make a 0.6.4 release with these fixes, since 
making this functionality useful across the board is worth it IMO.  After the 
warm reception the ipython+matplotlib combo got at scipy, it would be nice to 
give users something that really works across all platforms.

Again, many thanks for this: you know if it were up to me the win32 bug would 
have lingered forever.

Best,

f

On Thu, 09 Sep 2004, John Hunter apparently wrote:
> I made a number of simple but useful additions to the matlab interface

Very useful!!
And very cool as well.
Thanks,
Alan

On Thu, 09 Sep 2004, John Hunter apparently wrote:
> And there was much rejoicing.

Actually, yes!
Alan Isaac

The show() function works fine. But newbies ...

  Clovis> 1. There are two different toolbars that can be selected by
  Clovis> '.matplotlibrc': "classic" and "toolbar2" I tried both and
  Clovis> there is no "close figure" button. The only way I found to
  Clovis> close the figure was to press the mouse in the window upper
  Clovis> right corner.  Is it possible to "customize" the toolbar
  Clovis> icon menu?

Currently, there is no way to do this without hacking into the src
code of your backend of choice.  There used to be a close button, but
Steve Chaplin pointed me to some user interface docs from GNOME which
argued that it is a bad idea to put close buttons on toolbars, and so
I removed them.  There has been a discussion and partial
implementation of customizable toolbars on the devel list.  This will
happen eventually.

  Clovis> 2. How can I pre-assign a window size/position?  When I
  Clovis> issue the show() function the window position and size
  Clovis> assume default values.  How can I change these values?

  Clovis> 3. When I issue the show() function, the window opens with
  Clovis> the names "Figure 1", "Figure 2", etc How can I custumize
  Clovis> the window name?


  Clovis> 4. Is it possible to change the window attributes (eg.,
  Clovis> modal or not, enable/disable minimize)?

The only way currently to control the window size from the matlab
interface is to set the figure size with the figsize option, eg
figure(figsize=(10,12)).  However, you can set window properties in a
backend dependent manner with the figure manager instance.

  manager = get_current_fig_manager()

  backend_gtk*    : manager.window is a gtk.Window instance
  backend_wx*     : manager.frame is a wxFrame instance
  backend_tkagg   : manager.window is a Tk.Tk() instance
  backend_fltkagg : manager.window is a Fltk.Fl_Double_Window

Thus to set the title in a gtk* backend, you could do

manager = get_current_fig_manager()
manager.window.set_title('hi mom')

Of course, now your scripts won't work with other matplotlib
backends.  


In theory, we could abstract the essential window calls and expose
them in a GUI neutral manner.  We are trying to resist the urge to
become a GUI wrapping library so we can focus on being a plotting
library.

If you need a lot of control over GUI properties, you may want to skip
the matlab interface and use the matplotlib API directly, eg build a
GTK app which embeds matplotlib.  See examples/embedding_in*.py in the
matplotlib src distribution or at http://matplotlib.sf.net/examples
explaining how to embed matplotlib in your GUI of choice.

Cheers,
JDH

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> Do you think we'll be able to get the GTK/win32 setup
    Fernando> working?  You probably know that platform better than
    Fernando> anybody else here, so I'm pretty useless on this one.
    Fernando> But it would be great to be able to make a final ipython
    Fernando> release before I get into the 'big cleanup', so that
    Fernando> matplotlib users on all platforms/backends can use pylab
    Fernando> happily while I work on the cleanup.

Gee, some people are never satisfied!

I was able to replicate the gtk win32 problem in the matplotlib
interactive.py, which as you know is based on Brian McErlean and John
Finlay's ASPN cookbook recipe.  However, the original recipe does not
have this bug.  By diffing them, I traced the problem to the call to
gtk.threads_init().  This call is required on linux and OSX, but
breaks win32.  Typical.  So it's a hack but at least it works in my
tests thus far.

In IPython/Shell.py on or around line 424, replace the mainloop
function with 

    def mainloop(self):
        
        self.gtk.timeout_add(self.TIMEOUT, self.IP.runcode)
        if sys.platform != 'win32':
            try:
                if self.gtk.gtk_version[0] >= 2:
                    self.gtk.threads_init()
            except AttributeError:
                pass
        self.start()
        self.gtk.mainloop()
        self.join()

Incidentally, this or some other change appears to fix the GTK OSX
confirm on exit bug (the only other change here is that I call 'start'
after the threads_init call).

Thus I can happily report that with this change and the one you
included in CVS yesterday for output redirection in wx, all the
backends seem to be working across all the major platforms in ipython.

And there was much rejoicing.

JDH

John Hunter wrote:
> I got an answer from Robin Dunn on the wxpython list about the
> stderr/stdout bug that was breaking ipython -pylab with the wx*
> matplotlib backends.  It turns out that the defaults for output
> redirection are different on the different platforms, which explains
> why it worked on linux but not win32 or OSX.
> 
> All you need to do is pass redirect=False to the wxapp constructor.
> Eg, on or around line in 498 IPython/Shell.py v0.6.3
> 
>         self.app = App(redirect=False)
> 
> Confirmed to fix both OSX and win32 for wx*.

Great! Many thanks.  I've just committed the fix into CVS.

> Now I think the summary is
> 
>            linux        win32     OSX
>     GTK* : good         ugly      works except for shell close bug
>     WX*  : good         good      good
>     TK*  : good         good      good

Do you think we'll be able to get the GTK/win32 setup working?  You probably 
know that platform better than anybody else here, so I'm pretty useless on 
this one.  But it would be great to be able to make a final ipython release 
before I get into the 'big cleanup', so that matplotlib users on all 
platforms/backends can use pylab happily while I work on the cleanup.

Best,

f


ps.  You have for me: Fernando Perez <fp...@pi...>.
You should switch to Fer...@co..., which should be a more 
stable address for the long term (pizero was a local Physics server, and that 
account may disappear in the future).

On Wed, 08 Sep 2004, Darren Dale apparently wrote:
> from matplotlib.matlab import *
> figure(3)
> [plot(a,i) for i in [b,c]]
> #equivalent to:
> figure(4)
> for i in [b,c]:
>     plot(a,i)


These two examples suggest that one
ought to be able to input 2D arrays
for plotting against a 1D array.
(As in, e.g., GAUSS's xy() command.)

fwiw,
Alan Isaac

Matt Newville wrote:

>Darren Dale wrote:
>
>  
>
>>I strongly support stripping all unnecessary zeros from the labels. It 
>>seems a clear choice to me, but I would be interested to know if others 
>>are against it.
>>    
>>
>
>I agree that stripping unnecessary zeros from labels is a good
>idea, but I also prefer preserving significant trailing zeros, and
>do not like axes reading (for example):
>   0.997 0.998 0.999  1   1.001 1.002
>
>In my opinion, that '1' should be '1.000': the precision here is
>significant.  I also prefer more uniform series of '0.0 0.5 1.0'
>to the jagged appearance of '0 0.5 1'.  Maybe that's just my 
>interpretation of 'necessary'.
>
>Currently, ScalarFormatter prefers '1' to '1.000'.  I also see
>that it uses the axis "span" to determine the formatting.  I'm not
>sure how easy it would be to change, but it might be better to use
>the difference between axis ticks so that the formatting
>guaranteed unique labels with "just enough precision".
>  
>
I have been mulling this over myself. Each label is formatted 
independently of the rest, so guessing the precision to display would be 
difficult. It would be easier if all labels were formatted together with 
one call to scalarFormatter, but I dont think that is a possibility. 
Alternatively, it would be possible to write custom formatter that 
accepted an integer to display the proper precision.

Matlab will truncate precision at 4 places past the decimal point. At 
that point the labels are already looking a bit long. Matlab also 
represents 1.0000 as 1, regardless of the other labels. I am planning a 
scalarFormatterMathtext, which will replace 1e6 with the more desirable 
$1*10^6$, and will consider precision.

Darren

Darren Dale wrote:

> I strongly support stripping all unnecessary zeros from the labels. It 
> seems a clear choice to me, but I would be interested to know if others 
> are against it.

I agree that stripping unnecessary zeros from labels is a good
idea, but I also prefer preserving significant trailing zeros, and
do not like axes reading (for example):
   0.997 0.998 0.999  1   1.001 1.002

In my opinion, that '1' should be '1.000': the precision here is
significant.  I also prefer more uniform series of '0.0 0.5 1.0'
to the jagged appearance of '0 0.5 1'.  Maybe that's just my 
interpretation of 'necessary'.

Currently, ScalarFormatter prefers '1' to '1.000'.  I also see
that it uses the axis "span" to determine the formatting.  I'm not
sure how easy it would be to change, but it might be better to use
the difference between axis ticks so that the formatting
guaranteed unique labels with "just enough precision".

Fortunately, matplotlib makes it easy enough to tweak the axis
formatting for those of us who obsess about such things. I've been
using FuncFormatter and the custom formatter below in a WX
plotting frame I'm working on (linear 2D plotting only so far).  
I send it the list of ticks returned from the axis "major locator"
to determine the precision.  The fallback is to use 0.1*span:  
this is usually OK, but can be overly precise sometimes. There may
be a more efficient way of doing this, but I got a little lost in
ticker.py and axis.py....

> The regexpr was more elegant, and I don't mind spending an
> evening learning it so I can continue to work with it. On the
> other hand, string methods are more accessible. Elegant or
> accessible? What would "upper management" pick?

I think the main issue would be if using regular expressions would  
be noticably faster.  In this case, I'd guess not.

--Matt Newville

    self.axes.xaxis.set_major_formatter(FuncFormatter(self.format_x))
    self.axes.yaxis.set_major_formatter(FuncFormatter(self.format_y))

    def format_x(self,x,pos):
        " x-axis formatter "
        xticks = self.axes.xaxis.get_major_locator()()
        span   = self.axes.xaxis.get_view_interval().span()        
        return tick_formatter(x,span,ticks=xticks,pos=pos)
    
    def format_y(self,y,pos):
        " y-axis formatter "        
        yticks = self.axes.yaxis.get_major_locator()()
        span   = self.axes.yaxis.get_view_interval().span()
        return tick_formatter(y,span,ticks=yticks,pos=pos)

def tick_formatter(x, span, ticks=None,pos=0):
    """ home built tick formatter to use with FuncFormatter():
    x     value to be formatted
    span  span of axis, as from viewLim.span() -- required!!!!
    ticks optional list of ticks to format
    """
    fmt = '%1.6e'
    d   = 0.1 * span  
    try:
        d =  abs(ticks[pos+1] - ticks[pos])
    except:
        pass
    if   d > 99999:     fmt = '%1.6e'
    elif d > 0.99:      fmt = '%1.0f'    
    elif d > 0.099:     fmt = '%1.1f'
    elif d > 0.0099:    fmt = '%1.2f'        
    elif d > 0.00099:   fmt = '%1.3f'        
    elif d > 0.000099:  fmt = '%1.4f'        
    elif d > 0.0000099: fmt = '%1.5f'

    s =  fmt % x
    s.strip()
    s = s.replace('+', '')
    while s.find('e0')>0: s = s.replace('e0','e')
    while s.find('-0')>0: s = s.replace('-0','-')
    return s

The show() function works fine. But newbies ...

1. There are two different toolbars that can be selected by 
'.matplotlibrc':  "classic" and "toolbar2"
    I tried both and there is no "close figure" button. The only way I 
found to close the figure was to
    press the mouse in the window upper right corner.
    Is it possible to "customize" the toolbar icon menu?
2. How can I pre-assign a window size/position?
    When I issue the show() function the window position and size assume 
default values.
     How can I change these values?
3. When I issue the show() function, the window opens with the names 
"Figure 1", "Figure 2", etc
    How can I custumize the window name?
4. Is it possible to change the window attributes (eg., modal or not, 
enable/disable minimize)?

Thanks for the support.

>>>>> "Darren" == Darren Dale <dd...@co...> writes:


    Darren> There are a lot of ways to do this, I dont know them
    Darren> all. Here are a few to get you started:

These are all good suggestions, and the right way 99% of the time.  I
just want to point out that if you need to plot hundreds or thousands
of separate lines, calling plot over and over again is not the most
efficient strategy, since a new matplotlib.lines.Line2D object must be
created each time.  For these cases it is best to use a line
collection (matplotlib.collections.LineCollection).  You can find an
example of their use in the plotmap demo -
http://matplotlib.sourceforge.net/screenshots.html#plotmap, where line
collections are used to draw the geographic borders over a colormap.

JDH

Ryugan Mizuta wrote:

> Hi all,
>  
> I'm trying to create multiple lines on one graph.  Anybody have an 
> idea of plotiing multiple lines without writing the plot statement a 
> number of times?  Is it possible to include the plot statement inside 
> a "for" statement to produce multiple lines in one graph???
>  
>  

Hi Ryugan,

There are a lot of ways to do this, I dont know them all. Here are a few 
to get you started:

from matplotlib.matlab import *

a=arange(10)
b=a*2
c=a*3
figure(1)
plot(a,b,a,c)
figure(2)
plot(a,b,'k',a,c,'r')

figure(3)
[plot(a,i) for i in [b,c]]
#equivalent to:
figure(4)
for i in [b,c]:
    plot(a,i)

Hi all,

I'm trying to create multiple lines on one graph.  Anybody have an idea =
of plotiing multiple lines without writing the plot statement a number =
of times?  Is it possible to include the plot statement inside a "for" =
statement to produce multiple lines in one graph???


Thanks.

Ryugan

>     Jean> Hello, I'm a new user of matplotlib and I have to admit that
>     Jean> I'm quite impressed and excited about it !  I'm currently
>     Jean> trying to convince the whole company to switch from matlab
>     Jean> to python (at least 200 users I think), and matplotlib is a
>     Jean> big asset.
> 
> Good luck - is yours a software company?  200 new developers would be
> a big help :-)

No, we mainly use matlab for our own studies. But you can be sure that I
will report any bugs that we found.

> 
>     Jean> Extra content at the end of the document Could not load
>     Jean> filename for text
>     Jean> /users/m024234/local/share/matplotlib/Vera.ttf Traceback
> 
> Here is your problem.  The font is not being loaded.  First, in

Ah ! *slap forehead*

I found a ".ttffont.cache." in my home directory which was the remnants
of a previous installation. Inside was the old path to the font
directory. I deleted this file, and a new one with the good path was
created and everything run smoothly now.


> I notice from your path above that you have installed matplotlib in a
> nonstandard location.  Have you set the MATPLOTLIB environment
> variable, as described in the installing documentation on the web page
> http://matplotlib.sf.net/installing.html?

??? I never set the matplotlib environment and so far everything works
fine (even if I always use non standard location !)...

> Do you get the same traceback on win32?

No the problem was entirely different.
I was using the enthought python 2.3.3 with the IDE SPE 0.5.1d, and when
under SPE I tried to run a program as simple as :
from matplotlib.matlab import *
subplot(2,3,5)
show()

A screen with weird color appeared, and everything froze.

Now If I tried to run the same program directly from command-line (say
from a DOS window), everything works fine.

Is there some problem with SPE ?
It's strange because it was ok with the 0.60.2 version of matplotlib

Let me know if I can do anything to further investigate the problem...

> Gladly-accepting-donationsly-yours,
> JDH

I really really hope to convince them to give you something (not yet
thought, I still have to convince them to switch to python/matplotlib).
At least to show you that someone outside appreciate the software and
that it's worth continuing the project...

Thanks for your help !

Regards,

John Hunter wrote:

>>>>>>"Darren" == Darren Dale <dd...@co...> writes:
>>>>>>            
>>>>>>
>
>    Darren> With MPL 0.62.4, the following script is yielding a few
>    Darren> badly formatted y-axis labels:
>
>    Darren> import matplotlib from matplotlib.matlab import *
>
>    Darren> a=array([2,4,6,8,10,12,14,16,18,20])*1e5 plot(a) show()
>
>    Darren> I tried adding a "print s,m" statement after line 272: m =
>    Darren> self._zerorgx.match(s), where s is the original text. Here
>    Darren> is the output:
>
>    Darren> 2.0e+005 <_sre.SRE_Match object at 0x01249608> 4.0e+005
>    Darren> <_sre.SRE_Match object at 0x01249608> 6.0e+005
>    Darren> <_sre.SRE_Match object at 0x01249608> 8.0e+005
>    Darren> <_sre.SRE_Match object at 0x01249608> 1.0e+006
>    Darren> <_sre.SRE_Match object at 0x01249608> 1.2e+006 None
>    Darren> 1.4e+006 None 1.6e+006 None 1.8e+006 None 2.0e+006
>    Darren> <_sre.SRE_Match object at 0x01249608>
>
>    Darren> _zerorgx = re.compile('^(.*?)\.?0+(e[+-]\d+)?$'), which is
>    Darren> greek to me (and I dont have a good reference on
>    Darren> regexp's).
>
>There's a reason Jamie Zawinski said
>
>  Some people, when confronted with a problem, think "I know, I'll use
>  regular expressions."  Now they have two problems.
>
>
>Here's a re-implementation using string methods.  See if it passes all
>your tests.  More importantly, do you agree that removing the zeros
>etc which aren't necessary to visually parse the number is a good
>idea?
>
>class ScalarFormatter(Formatter):
>    """
>    Tick location is a plain old number.  If viewInterval is set, the
>    formatter will use %d, %1.#f or %1.ef as appropriate.  If it is
>    not set, the formatter will do str conversion
>    """
>
>    def __call__(self, x, pos):
>        'Return the format for tick val x at position pos'        
>        self.verify_intervals()
>        d = abs(self.viewInterval.span())
>
>        return self.pprint_val(x,d)
>
>    def pprint_val(self, x, d):
>        #if the number is not too big and it's an int, format it as an
>        #int
>        if abs(x)<1e4 and x==int(x): return '%d' % x
> 
>        if d < 1e-2: fmt = '%1.3e'
>        elif d < 1e-1: fmt = '%1.3f'
>        elif d > 1e5: fmt = '%1.1e'
>        elif d > 10 : fmt = '%1.1f'
>        elif d > 1 : fmt = '%1.2f'
>        else: fmt = '%1.3f'
>        s =  fmt % x
>
>        tup = s.split('e')
>        if len(tup)==2:
>            mantissa = tup[0].rstrip('0').rstrip('.')
>            exponent = tup[1].replace('+', '').lstrip('0')
>            s = '%se%s' %(mantissa, exponent)
>        return s
>
>JDH
>
>  
>

I strongly support stripping all unnecessary zeros from the labels. It 
seems a clear choice to me, but I would be interested to know if others 
are against it.

The third to last line needs changing, prepare for hackishness:
temp = tup[1][0] + tup[1][1:].lstrip('0') # strip zeros if there is a + 
or - sign
temp.replace('+', '')

The regexpr was more elegant, and I don't mind spending an evening 
learning it so I can continue to work with it. On the other hand, string 
methods are more accessible. Elegant or accessible? What would "upper 
management" pick?

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> With MPL 0.62.4, the following script is yielding a few
    Darren> badly formatted y-axis labels:

    Darren> import matplotlib from matplotlib.matlab import *

    Darren> a=array([2,4,6,8,10,12,14,16,18,20])*1e5 plot(a) show()

    Darren> I tried adding a "print s,m" statement after line 272: m =
    Darren> self._zerorgx.match(s), where s is the original text. Here
    Darren> is the output:

    Darren> 2.0e+005 <_sre.SRE_Match object at 0x01249608> 4.0e+005
    Darren> <_sre.SRE_Match object at 0x01249608> 6.0e+005
    Darren> <_sre.SRE_Match object at 0x01249608> 8.0e+005
    Darren> <_sre.SRE_Match object at 0x01249608> 1.0e+006
    Darren> <_sre.SRE_Match object at 0x01249608> 1.2e+006 None
    Darren> 1.4e+006 None 1.6e+006 None 1.8e+006 None 2.0e+006
    Darren> <_sre.SRE_Match object at 0x01249608>

    Darren> _zerorgx = re.compile('^(.*?)\.?0+(e[+-]\d+)?$'), which is
    Darren> greek to me (and I dont have a good reference on
    Darren> regexp's).

There's a reason Jamie Zawinski said

  Some people, when confronted with a problem, think "I know, I'll use
  regular expressions."  Now they have two problems.


Here's a re-implementation using string methods.  See if it passes all
your tests.  More importantly, do you agree that removing the zeros
etc which aren't necessary to visually parse the number is a good
idea?

class ScalarFormatter(Formatter):
    """
    Tick location is a plain old number.  If viewInterval is set, the
    formatter will use %d, %1.#f or %1.ef as appropriate.  If it is
    not set, the formatter will do str conversion
    """

    def __call__(self, x, pos):
        'Return the format for tick val x at position pos'        
        self.verify_intervals()
        d = abs(self.viewInterval.span())

        return self.pprint_val(x,d)

    def pprint_val(self, x, d):
        #if the number is not too big and it's an int, format it as an
        #int
        if abs(x)<1e4 and x==int(x): return '%d' % x
 
        if d < 1e-2: fmt = '%1.3e'
        elif d < 1e-1: fmt = '%1.3f'
        elif d > 1e5: fmt = '%1.1e'
        elif d > 10 : fmt = '%1.1f'
        elif d > 1 : fmt = '%1.2f'
        else: fmt = '%1.3f'
        s =  fmt % x

        tup = s.split('e')
        if len(tup)==2:
            mantissa = tup[0].rstrip('0').rstrip('.')
            exponent = tup[1].replace('+', '').lstrip('0')
            s = '%se%s' %(mantissa, exponent)
        return s

JDH

With MPL 0.62.4, the following script is yielding a few badly formatted 
y-axis labels:

import matplotlib
from matplotlib.matlab import *

a=array([2,4,6,8,10,12,14,16,18,20])*1e5
plot(a)
show()

I tried adding a "print s,m" statement after line 272:  m = 
self._zerorgx.match(s), where s is the original text. Here is the output:

2.0e+005 <_sre.SRE_Match object at 0x01249608>
4.0e+005 <_sre.SRE_Match object at 0x01249608>
6.0e+005 <_sre.SRE_Match object at 0x01249608>
8.0e+005 <_sre.SRE_Match object at 0x01249608>
1.0e+006 <_sre.SRE_Match object at 0x01249608>
1.2e+006 None
1.4e+006 None
1.6e+006 None
1.8e+006 None
2.0e+006 <_sre.SRE_Match object at 0x01249608>

_zerorgx = re.compile('^(.*?)\.?0+(e[+-]\d+)?$'), which is greek to me 
(and I dont have a good reference on regexp's).

Any ideas as to why 1.2e+006 is not resulting in an re match?

Darren