matplotlib-users Mailing List for matplotlib (Page 1368)

John Hunter wrote:
>>>>>>"Robert" == Robert Leftwich <ro...@le...> writes:
> 
> 
>     Robert> The good news is that it is a huge improvement, but the
>     Robert> bad news is that I'm still getting a GPF, just a lot less
>     Robert> often :-( Try bumping the minimal test loop up to 5k, it
>     Robert> failed at 3057 for me.
> 
> Bet you had to wait a while for that one. 

Not on the new laptop!

 > Maybe you should use
> the full test script.  At lease you'll fail faster  :-)

Yep, using the real data, it fails pretty quickly.

> 
> 
> What happens if you comment out this line in text.py
> 
>     self.cached[key] = ret
> 
> and this line in backend_agg.py
> 
>   _fontd[key] = font

It's worse, the minimal test fails at 4!, but the real data takes 180 or so.

> 
> We have a linux/unix specific script for testing for memory leaks in
> the mpl src distro unit/memleak_hawaii3.py.  You may want to adapt
> something like this for windows xp so we can get firm numbers on how
> much is leaking per figure.  

I'll attempt this when time permits, possibly late today, but sometime later 
this week is more likely.

Robert

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    Robert> John Hunter wrote:
    >> gc.collect() Should cure what ails you!
    >> 

    Robert> The good news is that it is a huge improvement, but the
    Robert> bad news is that I'm still getting a GPF, just a lot less
    Robert> often :-( Try bumping the minimal test loop up to 5k, it
    Robert> failed at 3057 for me.

Bet you had to wait a while for that one.  Maybe you should use
the full test script.  At lease you'll fail faster  :-)

matplotlib does some caching in various places for efficiency which
will slowly eat memory.  We need to add some automated means to clear
this cache but we don't have it yet.

What happens if you comment out this line in text.py

    self.cached[key] = ret

and this line in backend_agg.py

  _fontd[key] = font

We have a linux/unix specific script for testing for memory leaks in
the mpl src distro unit/memleak_hawaii3.py.  You may want to adapt
something like this for windows xp so we can get firm numbers on how
much is leaking per figure.  See also
http://matplotlib.sourceforge.net/faq.html#LEAKS.  Todd Miller knows a
clever way of getting python to report how may object references it
has a hold of, but I can't remember the magic command right now.

With matplotlib CVS on linux, that script is reporting no detectable
leak.  But your script may be exposing a leak not covered by that
one.

JDH

John Hunter wrote:
> 
>             gc.collect()
> 
> Should cure what ails you!
> 

The good news is that it is a huge improvement, but the bad news is that I'm 
still getting a GPF, just a lot less often :-( Try bumping the minimal test loop 
up to 5k, it failed at 3057 for me.

Robert

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    John> But if you can get a standalone script, that would be most
    John> efficient.

    Robert> I sent it direct to you, rather than everyone on the list.

OK, the good news is that my first hunch was correct.  The fact that
the minimal script (off-list) needed more iterations than the full,
and that the number of iterations on my system before the crash was
different than yours indicated to me that it was a memory problem.
matplotlib uses a fair number of cyclic references (figure refers to
canvas and canvas refers to figure -- this one was actually added in
0.72 which is where I suspect the culprit is).

In the pylab interface, I call gc.collect in the destroy method of
each figure manager to force the garbage collector to clean up.  In
your script, which doesn't use the pylab interface, you need to
manually add this call yourself.  I'll make it a FAQ because it is
fairly important, and add a link or the faq in the agg_oo example.

import gc


    def graphAll(self):
        for i in range(100):
            print i
            self.graphRSIDailyBenchmark()
            gc.collect()

Should cure what ails you!

python gurus -- would it be advisable for me to insert a gc.collect()
somewhere in the matplotlib OO hierarchy since I know cyclic
references are a problem?  Eg in the call to the FigureCanvas init
function?

JDH

>>>>> "kristen" == kristen kaasbjerg <co...@ya...> writes:

    kristen> Hi everyone Does anyone know how to asign different
    kristen> patches in legend when plotting 2 or more histograms in
    kristen> the same figure.  I've tried:
    kristen> legend((patches1,patches2),(hist1,hist2)) ,

    kristen> but this gives the same patches in the legend inset.

I'm assuming patches1 and patches2 are the return values from hist, in
which case they are each a *list* of patches.  What you want to do is
pass a *single* item from each of those lists as representative
patches.

  legend( (patches1[0],patches2[0]), ('label1', 'label2') ) 

Next time if you post a more complete code snippet, I won't have to
guess what patches1 and patches2 are!

Hope this helps,


JDH

I took up John's suggestion to 'new users starting on the path to matplotlib OO 
API enlightenment to make notes and write a tutorial as you go'.

I'm posting it to the list to generate some feedback and hopefully help out any 
fellow newbies (although I would prefer it to be on a Wiki somewhere).

Feel free to comment....


Robert


==================================================
Getting Started With Matplotlib's OO Class Library
==================================================

Introduction
------------

    For those people coming to Matplotlib without any prior experience
    of MatLab and who are familiar with the basic concepts of
    programming API's and classes, learning to use Matplotlib via the
    class library is an excellent choice. The library is well put
    together and works very intuitively once a few fundamentals are
    grasped.

    The advice from John Hunter, the original developer of the library
    is 'don't be afraid to open up matplotlib/pylab.py to see how the
    pylab interface forwards its calls to the OO layer.' That in
    combination with the user's guide, the examples/embedding demos,
    and the mailing lists, which are regularly read by many developers
    are an excellent way to learn the class library.

    Following is a brief introduction to using the class library,
    developed as I came to grips with how to produce my first graphs.

Classes/Terms
-------------

    FigureCanvas - is primarily a container class to hold the Figure
    instance, an approach which enforces a rigid segregation between
    the plot elements, and the drawing of those elements. It can be
    loosely thought of as 'the place where the ink goes'.

    Figure - a container for one or more Axes. It is possible to
    create and manage an arbitrary number of figures using the Figure
    class. Note also that a figure can have its own line, text and
    patch elements, independent of any axes.

    Axes - the rectangular area which holds the basic elements (Line2D,
    Rectangle, Text, etc) that are generated by the Axes plotting
    commands (e.g. the Axes plot, scatter, bar, hist methods). The Figure
    methods add_axes and add_subplot are used to create and add an Axes
    instance to the Figure. You should not instantiate an Axes instance
    yourself, but rather use one of these helper methods.

    Line - implemented in the Line2D class, can draw lines(!) with a
    variety of styles (solid, dashed, dotted, etc), markers (location
    indicators on the line - point, circle, triangle, diamond, etc) and
    colours (k or #000000 - black, w or #FFFFFF - white, b or #000099 -
    blue, etc)

    Text - a class that handles storing and drawing of text in window
    or data coordinates. The text can be coloured, rotated, aligned in
    various ways relative to the origin point, and have font properties
    (weight, style, etc) assigned to it.

    Patch - a patch is a two dimensional shape with a separately
    specifiable face and edge colour. Specialised patch classes include
    circle, rectangle, regular polygon and more.

    Ticks - the indicators of where on an axis a particular value
    lies. Separate classes exist for the x and y axis ticks, (XTick,
    YTick) and each are comprised of the primitive Line2D and Text
    instances that make up the tick.

    Artist - Everything that draws into a canvas derives from Artist
    (Figure, Axes, Axis, Line2D, Rectangle, Text, and more).  Some of
    these are primitives (Line2D, Rectangle, Text, Circle, etc) in that
    they do not contain any other Artists, some are simple composites,
    e.g. XTick which is mad up of a couple of Line2D and Text instances
    (upper and lower tick lines and labels), and some are complex, e.g.
    and Axes or a Figure, which contain both composite and primitive
    artists.


Techniques
----------

1. Setting up an agg backend canvas:

    from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
    from matplotlib.figure import Figure

    fig = Figure()
    canvas = FigureCanvas(fig)

2. To set the size of the Figure, use the figsize keyword, which uses
    inches as the units:

    # this results in a 204x192 pixel png - if output at 100 dpi, using
    # canvas.print_figure(.., dpi=100)
    fig = Figure(figsize=(2.04,1.92))
    canvas = FigureCanvas(fig)

3. To add a single subplot:

    # The 111 specifies 1 row, 1 column on subplot #1
    ax = fig.add_subplot(111)

4. To change the axes size and location on construction, e.g to fit
    the labels in on a small graph:

    ax = fig.add_axes([0.2,0.2,0.5,0.7])

    An existing Axes position/location can be changed by calling
    the set_position() method.

5. Adding a graph of some sort is as simple as calling the required
    function on the axes instance:

    p1 = ax.bar(...) or p1 = ax.plot(...)

6. Setting a label with extra small text:

    ax.set_xlabel('Yrs', size='x-small')

7. Setting the graph title:

    ax.set_title(A graph title', size='x-small')

8. To enable only the horizontal grid on the major ticks:

    ax.grid(False)
    ax.yaxis.grid(True, which='major')

9. To only have a left y-axis and a bottom x-axis:

    # set the edgecolor and facecolor of the axes rectangle to be the same
    frame = ax.axesPatch
    frame.set_edgecolor(frame.get_facecolor())
    # Specify a line in axes coords to represent the left and bottom axes.
    bottom = Line2D([0, 1], [0, 0], transform=ax.transAxes)
    left   = Line2D([0, 0], [0, 1], transform=ax.transAxes)
    ax.add_line(bottom)
    ax.add_line(left)

10. To change the size of the tick labels :

     labels = ax.get_xticklabels() + ax.get_yticklabels()
     for label in labels:
         label.set_size('x-small')

11. Removing the black rectangle around an individual bar graph
     rectangle (by changing it to the bar colour) :

     c = '#7FBFFF'
     p1 = ax.bar(ind, values, width, color=c)
     for r in p1:
         r.set_edgecolor(c)


Putting it together
-------------------

     Following is a simple example of how to use the class library
     This is examples/agg_oo.py in the matplotlib src distribution, also
     found (like all examples) at http://matplotlib.sf.net/examples

     #!/usr/bin/env python
     """
     A pure OO (look Ma, no pylab!) example using the agg backend
     """
     from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
     from matplotlib.figure import Figure

     fig = Figure()
     canvas = FigureCanvas(fig)
     ax = fig.add_subplot(111)
     ax.plot([1,2,3])
     ax.set_title('hi mom')
     ax.grid(True)
     ax.set_xlabel('time')
     ax.set_ylabel('volts')
     canvas.print_figure('test')

Hi everyone
Does anyone know how to asign different patches in
legend when plotting 2 or more histograms in the same
figure.
I've tried:
legend((patches1,patches2),(hist1,hist2)) ,

but this gives the same patches in the legend inset.

Kristen


		
__________________________________ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

>>>>> "Axel" == Axel Kowald <A.K...@gm...> writes:

    Axel> Hi, I'm using matplotlib 0.71 and I think I found a bug in
    Axel> polyfit.

    Axel> This simple linear regression on two data points gives the
    Axel> correct answer:
    >>>> polyfit([731.924,731.988],[915,742],1)
                       ^^^^
                     floats
    Axel> However, if I multiply my x values by 1000 the result is
    Axel> wrong:
    >>>> polyfit([731924,731988],[915,742],1)
                       ^^^^
                     integers
 
Both of these should work

print polyfit([731.924,731.988],[915.,742.],1)
print polyfit([731924.,731988.],[915.,742.],1)

I fixed the polyfit code to explicitly convert the input arrays to
floats arrays, which fixes this bug.

Thanks for the report.

JDH

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

    Darren> I need to plot some arrays that may begin or end with
    Darren> nan's. Currently, mpl does a good job handling something
    Darren> like plot([1,2,nan,4]), but the has trouble with
    Darren> plot([nan,2,3,4]) and plot([1,2,3,nan]).

    Darren> Could somebody point me in the right direction: where can
    Darren> I look in the sourcecode to learn how mpl deals with
    Darren> plotting nans?

mpl doesn't explicitly do anything with nan .  I think what you are
observing has something to do with how agg is handling these values,
because they are passed straight through to the backend.

So, for now, there is no place in the mpl code to go, though I would
like to add some support for nan, or masked arrays, or masks, in the
future.

JDH

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

    Humufr>        Hi, I see a problem when I'm using autoscale. I
    Humufr> have a spectra with huge difference in y. I used xlim to
    Humufr> look only a part of my spectra and the ylim is not
    Humufr> autoscale to this peculiar part of the spectra but on all
    Humufr> the spectra.

    Humufr> I'm using the last CVS version.

This was done intentionally for performance reasons.  Every plot
command calls autoscale, and each time this happens the autoscaler
would have to iterate over all the data in the axes (text, polygons,
lines, etc) and determine the vertices in the view limits.  Certainly
doable, but I try to make mpl reasonably efficient for large data sets
and this could get expensive.  Instead, when a piece of data is added
to the axes initially, I update the datalim with it and use that in
the autoscaler.

I'm aware of the problem you describe -- autoscaling can be suboptimal
when you initially set an axis view to only a part of the axes.  This
is a problem I can live with -- autoscaling doesn't have to be
perfect, it just needs to get it right most of the time.  And when it
doesn't do the most sensible thing, eg in this case, it at least
includes your data in the plot, and it is fairly easy for you to use
the navigation controls -- eg constrained y zoom by pressing y and
dragging the right mouse -- or otherwise set the limits manually.

So this is an area where I'd rather trade convenience for performance.
It wouldn't be to much work though, to add an option to the the
autoscaler to fix one of the axes limits (eg the xlim) and autoscale
the other axis only considering data within that range....

JDH

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

    Humufr> Hi, I found something strange inside the eps file create
    Humufr> with matplotlib. I used matplotlib to trace a port of a
    Humufr> spectra (I used the function plot and axis). I have been
    Humufr> very surprise to see that all the spectra was inside the
    Humufr> eps file. To see it, I must admit that I did something
    Humufr> weird. I create an eps file with matplotlib and I
    Humufr> transform the file in svg format with pstoedit and I edit
    Humufr> this file with inkscape.

    Humufr> I don't know where is the problem but I don't think that
    Humufr> it's necessary to have all the point inside the output
    Humufr> file, perhaps it's not possible to do anything to change
    Humufr> it but that can create some huge file. So if nothing can
    Humufr> be done, that will be a good idea to put it in the FAQ to
    Humufr> let the users cut their data if needed.

This is intentional, but I can see the problems it could create for a
large PS file, so it may be worth mentioning this in the
documentation.  Basically, we leave it or the backend to do the
clipping to the view limits, and in postscript the total line path is
drawn and the clip rectangle is set.  It would be difficult and
inefficient for us to do the clipping in the front end.  Think about
pathological cases, for example, where the x,y center of a marker is
far outside the view limits, but the marker is very large so that some
of its vertices are inside the view limits.

Earlier versions of matplotlib had a data clipping feature where line
points outside the view box were removed before adding them to the
backend.  But noone ever used it and it added complexity to the code
so I eventually deprecated it.

JDH

John Hunter wrote:
 >>>>>>"Robert" == Robert Leftwich <ro...@le...> writes:
 >
 >     Robert> Correct, no gui, verbose output:
 >
 > You say no gui, but the verbose report says tkagg:
 >
 >     backend TkAgg version 8.4

My bad, forgot to change the rc when re-installing 0.72.

 >
 > Do you see the problem when using agg alone?

Yes, in fact it seems to be worse.

 >
 >     >> But if you can get a standalone script, that would be most
 >     >> efficient.
 >
 >     Robert> Working on it now.
 >
 > Looking forward to it :-)

I sent it direct to you, rather than everyone on the list.

Robert

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    Robert> John Hunter wrote:
    >> Repeatable is good.  Standalone much better.  So you are
    >> running the pure Agg backend (no GUI?).  It would help to post
    >> the output of c:> python myscript.py --verbose-helpful

    Robert> Correct, no gui, verbose output:

You say no gui, but the verbose report says tkagg:

    backend TkAgg version 8.4

Do you see the problem when using agg alone?

    >> But if you can get a standalone script, that would be most
    >> efficient.

    Robert> Working on it now.

Looking forward to it :-)

JDH

John Hunter wrote:
> 
> Repeatable is good.  Standalone much better.  So you are running the
> pure Agg backend (no GUI?).  It would help to post the output of 
> 
>   c:> python myscript.py --verbose-helpful

Correct, no gui, verbose output:

matplotlib data path C:\Python24\share\matplotlib
loaded rc file C:\Python24\share\matplotlib\.matplotlibrc
matplotlib version 0.72.1
verbose.level helpful
interactive is False
platform is win32
numerix numarray 1.2.2
font search path ['C:\\Python24\\share\\matplotlib']
loaded ttfcache file c:\home\robert\.ttffont.cache
backend TkAgg version 8.4

> It probably won't happen with 0.71 and this would be worth testing.

Everything works without error on 0.71, using either numarray or Numeric.

> But if you can
> get a standalone script, that would be most efficient.

Working on it now.

Robert

John Hunter wrote:

>rm -rf your build subdir and reinstall matplotlib 0.72.1 or CVS.
>
Ouch.  Sorry for the noise.  I slipped up when I ran Fernando's 
pybrpm-noarch script on matplotlib 0.72 and wound up with a reinstall of 
an old 0.70 RPM.

>>>>> "Stephen" == Stephen Walton <ste...@cs...> writes:

    Stephen> Hi, all, Well, I've hit a new problem with the log
    Stephen> plotting issue.  Try the following commands after
    Stephen> 'ipython -pylab':

    Stephen> x=arange(25)+1 semilogx(x,x**2) hold(False)
    Stephen> semilogx(x,x**2)

    Stephen> I get an apparently unbreakable chain of "Cannot take log
    Stephen> of nonnegative value" messages for every following
    Stephen> plot(), semilog(), or loglog() command until ipython is
    Stephen> exited.  None of close(1), clf(), or cla() helps clear
    Stephen> the problem.  Only creating a new figure with figure(2)
    Stephen> and plotting to it seems to help.

rm -rf your build subdir and reinstall matplotlib 0.72.1 or CVS.  The
error string you report doesn't exist in the current code base, and I
can't reproduce your error.

JDH

Hi, all,

Well, I've hit a new problem with the log plotting issue.  Try the 
following commands after 'ipython -pylab':

x=arange(25)+1
semilogx(x,x**2)
hold(False)
semilogx(x,x**2)

I get an apparently unbreakable chain of "Cannot take log of nonnegative 
value" messages for every following plot(), semilog(), or loglog() 
command until ipython is exited.  None of close(1), clf(), or cla() 
helps clear the problem.  Only creating a new figure with figure(2) and 
plotting to it seems to help.

>>>>> "Robert" == Robert Leftwich <ro...@le...> writes:

    Robert> When attempting to generate a larger number of graph sets
    Robert> (i.e. 3 graphs of similar style over different data
    Robert> ranges), I'm intermittently getting a GPF on XP in
    Robert> na_backend_agg.pyd according to the report that M$ offers
    Robert> to send to itself.

Ouch.

    Robert> It is repeatable in one sense, in that if I restart the
    Robert> graph generation from the beginning it will fail at the
    Robert> same set, but if skip the first set of graphs it doesn't
    Robert> produce one additional set and then die, it dies at 15 (5
    Robert> sets) earlier. I can restart from any of the sets where it
    Robert> failed and it will continue on for some random number
    Robert> before GPF'ing again - anything from 9 thru to 150 graphs
    Robert> or so.

Repeatable is good.  Standalone much better.  So you are running the
pure Agg backend (no GUI?).  It would help to post the output of 

  c:> python myscript.py --verbose-helpful

    Robert> If I use Numeric (23.7, the latest) it is a lot worse -
    Robert> meaning fewer sets before failure. Also matplotlib 0.72
    Robert> was a lot worse with either Numeric and numarray.

It probably won't happen with 0.71 and this would be worth testing.  I
did a bunch of changes in backend agg in 0.72, including using the
numeric API rather than the sequence protocol.  If you want to verify
that the problem was introduced in 0.72 (which will help me narrow
down the possible culprits) remove site-packages/matplotlib and then
install 0.71 and see if the crash disappears.

    Robert> I'm not sure of the best way to proceed from here - is
    Robert> this a known issue or related to one or should I attempt
    Robert> to produce a standalone test that causes the problem?

That would help immensely.

One thing I can do is send you a debug build of mpl for windows that
has a bunch of extra diagnostic information turned on.  This might
help isolate which function is causing the problem.  But if you can
get a standalone script, that would be most efficient.

Thanks,

When attempting to generate a larger number of graph sets (i.e. 3 graphs of 
similar style over different data ranges), I'm intermittently getting a GPF on 
XP in na_backend_agg.pyd according to the report that M$ offers to send to itself.

It is repeatable in one sense, in that if I restart the graph generation from 
the beginning it will fail at the same set, but if skip the first set of graphs 
it doesn't produce one additional set and then die, it dies at 15 (5 sets) 
earlier. I can restart from any of the sets where it failed and it will continue 
on for some random number before GPF'ing again - anything from 9 thru to 150 
graphs or so.

If I use Numeric (23.7, the latest) it is a lot worse - meaning fewer sets 
before failure. Also matplotlib 0.72 was a lot worse with either Numeric and 
numarray.

The environment is Python 2.4, XP (sp2), matplotlib 0.72.1, numarray 1.2.2, 
Numeric 23.7 with the data coming from Postgres 8.0 via SQLObject and psycopg.

I'm not sure of the best way to proceed from here - is this a known issue or 
related to one or should I attempt to produce a standalone test that causes the 
problem?

Robert

Hi,

I'm using matplotlib 0.71 and I think I found a bug in polyfit.

This simple linear regression on two data points gives the correct answer:
 >>> polyfit([731.924,731.988],[915,742],1)
array([   -2703.12505517,  1979397.10294428])

However, if I multiply my x values by 1000 the result is wrong:
 >>> polyfit([731924,731988],[915,742],1)
array([ 5.17650790e-009,  8.28496211e+002])

Could that be some kind of overflow problem ???

    Alex

John Hunter wrote:

>>>>>>"Andrea" == Andrea Riciputi <ari...@pi...> writes:
>>>>>>            
>>>>>>
>
>    Andrea> Hi all, I'm an absolutely matplotlib newbie, so I'm sorry
>    Andrea> if my question is trivial. Anyway I've read the user guide
>    Andrea> and looked at the examples without finding out a solution.
>
>    Andrea> Here it is my problem. Suppose I have a 2-dimensional
>    Andrea> array containg my data, and I want to produce a surface or
>    Andrea> a contour plot with it. Now the imshow() function seems
>    Andrea> the right way to go through. So far so good. Now suppose I
>    Andrea> want to draw the x,y axes for this plot, and suppose my
>    Andrea> axes are represented by **not-uniform** 1-dimensional
>    Andrea> array x[i], y[j]. How can I get the right ticks on the
>    Andrea> plot axes??
>
>You need to interpolate your data onto a rectilinear grid and then use
>pcolor.  imshow requires that your data be an image -- eg the dx and
>dy between rows and columns is the same between every row and column.
>pcolor only assumes a rectilinear grid, so the dx and dy can vary from
>row to row and column to column.  But you have unstructured data.
>
>In matlab, the interpolation is handled by the griddata function.
>Peter Groszkowski promised to post some code he uses to for this
>purpose back in December, but apparently he got lost in the stars.
>

yup.. i did get a little "lost in the stars" - I forgot about it in 
fact.  I promise I will post it in the next few days - this time I mean 
it. ;)

-- 
Peter Groszkowski         Gemini Observatory
Tel: +1 808 9742509       670 N. A'ohoku Place
Fax: +1 808 9359235       Hilo, Hawai'i 96720, USA 

Hi John,

On Monday 28 February 2005 12:11 pm, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> oops, I just noticed a bug, the first script I posted wont
>     Darren> run. This updated script worked for me with a fresh 0.72.1
>     Darren> installation. Sorry about the error.
>
> Hi Darren, this is very nice work.  Sorry for the delay in getting
> back but I've been tied up for the last week or so.

Thanks. 

>
> One comment I have is that I think we might choose the default offset
> label differently.  Visually
>
>  1e-5+12e-10
>           10
>            8
>            6
>            4
>            2
>
> is hard to read because the two 10s line up when you should be
> comparing the 12 with the 10.  I wonder if this is better
>
>  1e-5+1e-10*12
>             10
>              8
>              6
>              4
>              2
>
> Still an eyeful but at least the significant part of the ticks are
> co-registered.  What so you think?

I originally did it the way you suggest, and changed it to make it more 
compact....

[...]

>
> Another comment is that these labels take up a lot of space, and will
> pretty much break any default subplot which doesn't leave enough room
> for them.  
>
> Although I like the idea of using one of the tick labels 
> itself to handle the offset formatting, I wonder if we might be better
> off using a special axis.set_offset command, so that for example, the
> yaxis could place the offset above the ticks and thus take up less
> horizontal space.  Just a thought.

Yeah, my intention this weekend was just to get the information into the plot, 
so it was clear what I was trying to accomplish. I would really like to get 
the scientific notation out of that last ticklabel, and put it above the axis 
as you suggest.

Can we do proper exponential formatting, like with the logscale? I know there 
are scholarly journals out there that will complain about using the 'e' 
notation.

>
> Also, I'm inclined to make this the default formatter --

I am glad to hear that. 

> do you see 
> any problems with this?  What troubles did you run into when you tried
> to add these changes to the ScalarFormatter class and then rolled them
> back because of clashes with derived classes?

I originally hijacked ScalarFormatter, then noticed that the LogFormatter* 
classes inherited the pprint_val method from ScalarFormatter. That is really 
not a problem, we could just copy the old ScalarFormatter.pprint_val method 
to LogFormatter, then it will override the new ScalarFormatter method.

Questions/problems before making this the default formatter:

1) Will the gui windows still report the appropriate coordinates? I noticed in 
the script I posted that the y coordinate was only reported as an integer.

2) in the script, near the bottom, try changing

	figure(2,figsize=(6,6))
	ax1 = axes([.225,.74,.75,.2])
	ax1.plot(arange(11)*1e-4)

to read

	figure(2,figsize=(6,6))
	ax1 = axes([.225,.74,.75,.2])
	ax1.plot(arange(11)*1e-15)  #<--- changed order of magnitude

The resulting plot does not render the last ticklabel. I checked my script, 
and the string is generated by pprint_val, but it is not rendered. I dont 
understand why. Several orders of magnitude wont render. For example, 1e-107 
doesnt render, nor does 1e-60, but 1e-61 does. I didnt see a problem with 
scientific notation containing positive exponents. Maybe this odd bug will 
not be reproducible once the information is rendered in its own space, I dont 
know.

3) (Almost not worth mentioning) I could run the same script 10 times and once 
it would yield an unsubscriptable object error message. When this happened, 
self.locs was set to None, and pprint_val was choking on this line:

if x==self.locs[-1] and (self.orderOfMagnitude or self.offset):

This problem will not exist when we stop rendering the offset/sci.not. in the 
ticklabel. I hesitate to even bring this nonexistent problem up, but if 
somebody notices this behavior, they should know it will not exist in the 
final product.

-- 

Darren

>>>>> "Massimo" == Massimo Sabbatini <sab...@de...> writes:

    Massimo> Dear group, is it possible to set the default sequence of
    Massimo> line styles, colors, widths, etc. to be used when
    Massimo> plotting multiple lines ?  pylab.rc seems to set the
    Massimo> default parameters only for the first line.

    Massimo> I've googled about it, but it does not seem a very
    Massimo> popular question.

No, this is not currently possible.  The default line style does not
cycle, and the default color cycle is hardcoded.  It would be possible
to make these configurable, but since it is relatively easy to specify
which linestyles you want, I'm not sure it's necessary.

JDH

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

    Darren> oops, I just noticed a bug, the first script I posted wont
    Darren> run. This updated script worked for me with a fresh 0.72.1
    Darren> installation. Sorry about the error.

Hi Darren, this is very nice work.  Sorry for the delay in getting
back but I've been tied up for the last week or so.

One comment I have is that I think we might choose the default offset
label differently.  Visually

 1e-5+12e-10
          10  
           8
           6
           4
           2

is hard to read because the two 10s line up when you should be
comparing the 12 with the 10.  I wonder if this is better

 1e-5+1e-10*12
            10  
             8
             6
             4
             2

Still an eyeful but at least the significant part of the ticks are
co-registered.  What so you think?

Likewise

10e-5
    8
    6
    4
    2

Becomes

1e-5*10
      8
      6
      4
      2 



It takes more room but I find it easier to read because one naturally
expects the significant digits to be in the same place.

Another comment is that these labels take up a lot of space, and will
pretty much break any default subplot which doesn't leave enough room
for them.  Although I like the idea of using one of the tick labels
itself to handle the offset formatting, I wonder if we might be better
off using a special axis.set_offset command, so that for example, the
yaxis could place the offset above the ticks and thus take up less
horizontal space.  Just a thought.

Also, I'm inclined to make this the default formatter -- do you see
any problems with this?  What troubles did you run into when you tried
to add these changes to the ScalarFormatter class and then rolled them
back because of clashes with derived classes?

JDH

>>>>> "oliver" == oliver tomic <oli...@ma...> writes:

    oliver> Hi folks,

    oliver> this might be a trivial question, but I could not figure
    oliver> it out from the documentation or the examples.

    oliver> I have a plot where the x-scale ranges from 0 to 20.  When
    oliver> I plot a line it automatically starts at x=0. I would like
    oliver> the line to start at x=1. Is there a way to how I can do
    oliver> that?

If I understand your question correctly, you want to set the xlim to
range from 1-20 even if your data range from 0-20

  >>> plot(x,y)
  >>> xlim(1,20)

http://matplotlib.sf.net/matplotlib.pylab.html#-xlim
http://matplotlib.sf.net/matplotlib.pylab.html#-axis

JDH