matplotlib-users Mailing List for matplotlib

>>>>> "Bob" == Bob Ippolito <bo...@re...> writes:

    Bob> On Jun 17, 2005, at 4:09 PM, John Hunter wrote:

    >>>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
    >>>>>>> 
    >>
    >>> Using data_files in this manner at all is usually the wrong
    >>> thing to do anyway.  Python packages should really put the
    >>> files they need into the package, not some semi-random
    >>> location on the filesystem.
    >>> 
    >>
    Chris> I tend to trust Bob in these matters. What is the logic for
    Chris> putting all that stuff outside of the package directory?
    >>  I was just following the lead of the distutils documentation
    >> circa 2003 which is when this section of setup.py written.
    >> Since distutils had a slot for data_files, I put my data files
    >> there, which seems reasonable even in hindsight.  I'm not
    >> opposed to putting them somewhere else, especially if someone
    >> explains the why and how.  I do try and preserve compatibility
    >> with older python versions, so 2.4 only solutions are not a
    >> good choice at the moment.

    Bob> Python 2.4 distutils has the functionality built-in,
    Bob> otherwise you can get it from setuptools (in the Python CVS
    Bob> sandbox, or from
    Bob> <http://peak.telecommunity.com/DevCenter/PythonEggs>).  There
    Bob> have been various other hacks throughout the years to do it,
    Bob> but setuptools is the standard now.

    Bob> py2app uses setuptools when building itself, and it is
    Bob> certainly Python 2.3 compatible.

Hi Bob, 

Sorry for the delay getting back on this.  I am starting to look at
setuptools and have read over (quickly)
http://peak.telecommunity.com/DevCenter/PythonEggs

A couple of questions:

  * Are you recommending using the full PythonEggs suite, or just the
    parts in the default setuptools that comes with python2.4 ?  I
    notice for example, that pkg_resources is not available in Python
    2.4.1 setuptools.  This is not a huge problem, since it is fairly
    easy to install/upgrade.  Just wondering.


  * It is not clear to me what the "right" way is to
    distribute/install data files (eg fonts).  You suggest above that
    the data_files directive is not the right way and that the data
    files should be placed in the package.  I naively tried
    package_data with
    
     from setuptools import setup
     
     setup(name="matplotlib",
        ...snip...
        package_data = {
          'matplotlib.fonts' : glob.glob('fonts/afm/*.afm'),
         },
        package_dir = {'': 'lib'},
        )

    where fonts/afm in the relative path has a bunch of *.afm fonts,
    but no files were added to site-packages/matplotlib/fonts/ when I
    did a 'sudo python setup.py install'.  I read over the py2app
    setup at http://svn.red-bean.com/bob/py2app/trunk/setup.py but
    still was unsure how to proceed.  The PythonEgg resource
    documentation spends a fair amount of space on how to "access"
    resources, but I missed how to specify them for the distribution
    (http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources)

    So that is a long-winded way of asking "how should data files be
    placed in the package for distribution?"

   
Thanks,
JDH

>>>>> "Torsten" =3D=3D Torsten Bronger <br...@ph...> wr=
ites:

    Torsten> Hall=F6chen!  John Hunter <jdh...@ac...>
    Torsten> writes:

    >>>>>>> "Torsten" =3D=3D Torsten Bronger
    >>>>>>> <br...@ph...> writes:
    >>
    Torsten> 2. The above loop is the last part of my program.  The
    Torsten> program terminates with
    >>
    Torsten> Fatal Python error: PyEval_RestoreThread: NULL tstate
    >>
    Torsten> Apparently, this is done by my improper handling of
    Torsten> matplotlib.  What's going wrong?
    >>  This is an annoyance we haven't been able to get rid of in all
    >> use cases.  animation using pylab and tkagg is one of the
    >> places.  I assume you are using the tkagg backend?

    Torsten> Yes.

    >> If you search the mailing list archives for
    >> PyEval_RestoreThread, you'll see this in many contexts.  For
    >> any semi-serious animation work, I suggest you not use the
    >> matplotlib/interactive mode shown in anim.py but rather use
    >> your GUI's idle handling or timer mechanism as in
    >> examples/anim_tk.py or examples/dyamic_image_gtkagg.py.

    Torsten> Thanks, I'll do.

    >> [...]
    >>=20
    Torsten> 3. How can I achieve that dynamic autoscaling of the
    Torsten> y-axis?  As noted in the source, "gcf().autoscale_view"
    Torsten> has no effect.
    >>  This is not legal matplotlib code -- I assume you mean
    >> gca().autoscale_view().

    Torsten> Yes, sorry.

    >> In the absence of more information it is hard top diagnose what
    >> the problem is.

    Torsten> Here is a complete example:


OK, that helps.  The update of the data limits happens when you call
plot and friends (technically plot calls ax.add_line which calls
ax.update_datalim_numerix) .  If you manually set the xdata or ydata
on the line object, you need to manually update the Axes datalim with



ax =3D gca()
for i in range(2*cycles):
    voltages =3D number_of_values * [i % 2 + 3]
    y_values[i * number_of_values : (i+1) * number_of_values] =3D \
                       voltages
    line.set_ydata(y_values)
    ax.update_datalim_numerix(x_values, y_values)
    ax.autoscale_view()

    draw()
    time.sleep(1)


JDH

Hi,

I am putting together a system model that uses wxpython sliders and
buttons for controls. I would like to use notebook tabs/windows for
different sections and have one notebook window for plotting. I have
hunted through the matplotlib examples but have not found any that use
something other than a wxFrame. I apologize for not digging deep to
solve the problem, but if someone had an example or an explanation of
what is necessary, I would greatly appreciate it.

Thanks,

Pat ODonnell

On Sat, 2005-07-02 at 09:59 -0500, John Hunter wrote:
[...]
> Also, we have to balance inconvenience of package developers with
> inconvenience of users.  Given a choice, I tend to inconvenience the
> power users, because they are more able and willing to deal with it.
Its not just a tradeoff between package developers and users because
if you make things easy for package developers you also make things
easier for users (who use those packages) since they are now able
to install from the package instead of using cvs or a tar or zip file.

> That said, I think there is a compromise solution which may satisfy
> everyone.  Following Chris Barker's suggestion, we can create a zip
> file or tarball of matplotlib deps, which has the src of all of the
> prereqs (except python and numerix) in it, and rewrite the setup to
> have a proper configure, checking for each prereq and issuing a kind
> error like "you are missing the freetype prereq, please install it or
> download http://someserver.com/mpldeps.zip and unzip it in this dir.
> This would keep the matplotlib distro (and CVS updates) as light as
> possible while making it easier to compile mpl on OSX and some linux
> distros.  Of course, to do this right requires a fair amount of
> effort, but I am all for it.  I worked for a while trying to use the
> distutils configure functionality (which can test for include headers,
> libs and the like) but was unsuccessful.  The question that stumped me
> was how to properly communicate the results of the config process to
> the build process.  I posted this to c.l.python but got no answer:
> http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/97cbe06f5efa58c0/18a015cba8bf2bd0?q=author:jdh...@ac...+group:comp.lang.python+distutils&rnum=1&hl=en#18a015cba8bf2bd0

A light cvs with a zipfile of dependencies seems like a good idea.

Maybe there was no response to the distutils question because nobody
knows how to do it, or because distutils is not powerful enough to
support it very well. Or just because nobody else writes Python packages
with as many dependencies as matplotlib!

The Python source code (and PyGTK) use gnu autotools (autoconf,
automake, etc) to configure and install themselves. Its more powerful
than distutils and is used by many C projects, but can be used for
Python too.

Steve



Send instant messages to your online friends http://au.messenger.yahoo.com 

Steve Chaplin wrote:
> On Fri, 2005-07-01 at 20:28 -0700,
> mat...@li... wrote:
> 
>>Eric Emsellem wrote:
>>
>>>Hi,
>>>a short report on 2 minor problems I face with matplotlib:
>>>
>>>- I tried to save a figure in gif. It gave me back an error message 
>>>saying that basically this is not supported. This is fine of course. 
>>>However, then the plot window crashed, and then the whole Ipython 
>>>session. It would be useful then to have this error not affecting the 
>>>session in this way if possible.
>>
>>I can see the problem in the GTK backend, but all other backends I tried under 
>>linux (TkAgg, QtAgg and WXAgg) all behave correctly.  This seems like a bug in 
>>the GTK backend to me: it puts out to the screen an error message box, but the 
>>OK button in that box is unresponsive.  Eventually the window manager just 
>>kills the window, which brings the whole python process down with it.
>>
>>I don't know the backends enough to know what the right solution should be here.
> 
> 
> I think this is an example where the IPython method of using threads to
> interactively execute gtk commands does not work.
> A minimal example that gives the same problem:
> 
> $ ipython -gthread
> In [1]: import gtk
> In [2]: md=gtk.MessageDialog(buttons=gtk.BUTTONS_CLOSE,
> message_format="message")
> In [3]: md.run()
> 
> gtk_dialog_run() blocks in a recursive main loop until the dialog either
> emits the response signal, or is destroyed.
> This gives the effect of a modal dialog. It works fine from within a GTK
> program, but gives problems when used through IPython.

Mmh, I just don't know enough about GTK to consider what the right approach 
should be.  Is this something that ipython should handle differently?  I'll 
gladly incorporate any fixes, if I knew what they need to be :)

Cheers,

f

On Fri, 2005-07-01 at 20:28 -0700,
mat...@li... wrote:
> Eric Emsellem wrote:
> > Hi,
> > a short report on 2 minor problems I face with matplotlib:
> > 
> > - I tried to save a figure in gif. It gave me back an error message 
> > saying that basically this is not supported. This is fine of course. 
> > However, then the plot window crashed, and then the whole Ipython 
> > session. It would be useful then to have this error not affecting the 
> > session in this way if possible.
> 
> I can see the problem in the GTK backend, but all other backends I tried under 
> linux (TkAgg, QtAgg and WXAgg) all behave correctly.  This seems like a bug in 
> the GTK backend to me: it puts out to the screen an error message box, but the 
> OK button in that box is unresponsive.  Eventually the window manager just 
> kills the window, which brings the whole python process down with it.
> 
> I don't know the backends enough to know what the right solution should be here.

I think this is an example where the IPython method of using threads to
interactively execute gtk commands does not work.
A minimal example that gives the same problem:

$ ipython -gthread
In [1]: import gtk
In [2]: md=gtk.MessageDialog(buttons=gtk.BUTTONS_CLOSE,
message_format="message")
In [3]: md.run()

gtk_dialog_run() blocks in a recursive main loop until the dialog either
emits the response signal, or is destroyed.
This gives the effect of a modal dialog. It works fine from within a GTK
program, but gives problems when used through IPython.

Regards
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

Hallöchen!

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

>>>>>> "Torsten" == Torsten Bronger <br...@ph...> writes:
>
>     Torsten> 2. The above loop is the last part of my program.  The
>     Torsten> program terminates with
>
>     Torsten>        Fatal Python error: PyEval_RestoreThread: NULL
>     Torsten> tstate
>
>     Torsten>    Apparently, this is done by my improper handling of
>     Torsten> matplotlib.  What's going wrong?
>
> This is an annoyance we haven't been able to get rid of in all use
> cases.  animation using pylab and tkagg is one of the places.  I
> assume you are using the tkagg backend?

Yes.

> If you search the mailing list archives for PyEval_RestoreThread,
> you'll see this in many contexts.  For any semi-serious animation
> work, I suggest you not use the matplotlib/interactive mode shown
> in anim.py but rather use your GUI's idle handling or timer
> mechanism as in examples/anim_tk.py or
> examples/dyamic_image_gtkagg.py.

Thanks, I'll do.

> [...]
>
>     Torsten> 3. How can I achieve that dynamic autoscaling of the
>     Torsten> y-axis?  As noted in the source, "gcf().autoscale_view"
>     Torsten> has no effect.
>
> This is not legal matplotlib code -- I assume you mean
> gca().autoscale_view().

Yes, sorry.

> In the absence of more information it is hard top diagnose what
> the problem is.

Here is a complete example:

#----------------------------------------------------------
from pylab import *
import time

ion()

cycles = 10
number_of_values = 100
total_number_values = 2 * cycles * number_of_values
x_values = arange(0, 2 * cycles, 1.0 / number_of_values)
y_values = total_number_values * [0.0]
line, = plot(x_values, y_values)

for i in range(2*cycles):
    voltages = number_of_values * [i % 2 + 3]
    y_values[i * number_of_values : (i+1) * number_of_values] = \
                       voltages
    line.set_ydata(y_values)
    gca().autoscale_view()
    draw()
    time.sleep(1)
#----------------------------------------------------------

Here, no autoscaling happens.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus

===== Original message from John Hunter | Tue, 05 Jul 2005:
> This was just a suggestion of an interface that could be implemented,
> not one that exists.  The interface would be
>   axvline(x=0, noupdate=True)

it is a good idea.

what about (in this case)

   grid(x=[0], y=[0])

to control grid lines separate from xtic and ytic settings?


> I agree -- could you add a feature request to the sourceforge site
> with a description of the problem and a link to this thread?

will do. :)

>>>>> "Torsten" == Torsten Bronger <br...@ph...> writes:

    Torsten> 2. The above loop is the last part of my program.  The
    Torsten> program terminates with

    Torsten>        Fatal Python error: PyEval_RestoreThread: NULL
    Torsten> tstate

    Torsten>    Apparently, this is done by my improper handling of
    Torsten> matplotlib.  What's going wrong?

This is an annoyance we haven't been able to get rid of in all use
cases.  animation using pylab and tkagg is one of the places.  I
assume you are using the tkagg backend?  If you search the mailing
list archives for PyEval_RestoreThread, you'll see this in many
contexts.  For any semi-serious animation work, I suggest you not use
the matplotlib/interactive mode shown in anim.py but rather use your
GUI's idle handling or timer mechanism as in examples/anim_tk.py or
examples/dyamic_image_gtkagg.py.

Note that the gtkagg backend runs fine on windows and is the fastest
for animation, though installing the GTK runtime and pygtk takes a bit
more time.


    Torsten> 3. How can I achieve that dynamic autoscaling of the
    Torsten> y-axis?  As noted in the source, "gcf().autoscale_view"
    Torsten> has no effect.

This is not legal matplotlib code -- I assume you mean
gca().autoscale_view().  In the absence of more information it is hard
top diagnose what the problem is.  gca().autoscale_view() followed by
a draw command should rescale the axes to include all the data in x
and y.  If you want to have only the y axis autoscaled and not the x
axis, I suggest writing a custom tick locator for the xaxis which
returns fixed axis ranges and ticks, and use whatever ticker you want
for the yaxis (eg the default).  See examples/custom_ticker.py,
http://matplotlib.sourceforge.net/matplotlib.ticker.html and Chapter 5
of the users guide.

JDH

>>>>> "Christian" == Christian Meesters <mee...@un...> writes:

    Christian> Hi I'm trying to plot some error-bars in my GUI making
    Christian> use of the WXAgg-backend. My code looks like this: if
    Christian> parent.error_bar:
    Christian> a.errorbar(x.ichannel,x.intensity,x.intensity_error,ecolor='k')
    Christian> Now, I can plot the error bars in any arbitrary color,
    Christian> but the my actually black-on-white data are colored
    Christian> blue upon adding error-bars this way. What I want is
    Christian> that everything (data and their errors) is plotted
    Christian> black. Can anybody tell how to achieve this behavior?

This is actually covered in the errorbar docstring, but subtly, so
I'll elaborate here (and update the errorbar docs with this example)


    def errorbar(self, x, y, yerr=None, xerr=None,
                 fmt='b-', ecolor=None, capsize=3,
                 barsabove=False, **kwargs):
        """
        ERRORBAR(x, y, yerr=None, xerr=None,
                 fmt='b-', ecolor=None, capsize=3, barsabove=False)

        Plot x versus y with error deltas in yerr and xerr.
        Vertical errorbars are plotted if yerr is not None
        Horizontal errorbars are plotted if xerr is not None

        ....snip.....snip....snip
===>    kwargs are passed on to the plot command for the markers


So you can add additional key=value pairs to control the errorbar
markers.  For example, this code makes big red squares with thick
green edges

  >>> x,y,yerr = rand(3,10)
  >>> errorbar(x, y, yerr, marker='s', mfc='red', mec='green', ms=20, mew=4)

As you may know, mfc, mec, ms and mew are aliases for the longer
property names, markerfacecolor, markeredgecolor, markersize and
markeredgewith.  For more information on which properties are settable
(and their aliases), you can use the setp function

   >>> setp(Line2D)


    alpha: float
    antialiased or aa: [True | False]
    clip_box: a matplotlib.transform.Bbox instance
    clip_on: [True | False]
    color or c: any matplotlib color - see help(colors)
    dash_capstyle: ['butt' | 'round' | 'projecting']
    dash_joinstyle: ['miter' | 'round' | 'bevel']
    dashes: sequence of on/off ink in points
    data: (array xdata, array ydata)
    data_clipping: [True | False]
    figure: a matplotlib.figure.Figure instance
    label: any string
    linestyle or ls: [ '-' | '--' | '-.' | ':' | 'steps' | 'None' ]
    linewidth or lw: float value in points
    lod: [True | False]
    marker: [ '+' | ',' | '.' | '1' | '2' | '3' | '4' | '<' | '>' | 'D' | 'H' | '^' | '_' | 'd' | 'h' | 'o' | 'p' | 's' | 'v' | 'x' | '|' ]
    markeredgecolor or mec: any matplotlib color - see help(colors)
    markeredgewidth or mew: float value in points
    markerfacecolor or mfc: any matplotlib color - see help(colors)
    markersize or ms: float
    solid_capstyle: ['butt' | 'round' |  'projecting']
    solid_joinstyle: ['miter' | 'round' | 'bevel']
    transform: a matplotlib.transform transformation instance
    visible: [True | False]
    xclip: (xmin, xmax)
    xdata: array
    yclip: (ymin, ymax)
    ydata: array
    zorder: any number


In the API, setp is defined in matplotlib.artist and Line2D in
matplotlib.lines.

Cheers!
JDH

>>>>> "Vidar" == Vidar Gundersen <vid...@37...> writes:

    Vidar> ===== Original message from John Hunter | Mon, 04 Jul 2005:

    >> One could add a kwarg to the various plot commands like
    >> noupdate to suppress updating the datalim,

    Vidar> example?

This was just a suggestion of an interface that could be implemented,
not one that exists.  The interface would be

  # do not update the data limits which control autoscaling
  axvline(x=0, noupdate=True)

    >> Basically, you would like to add string symbol markers to
    >> scatter, and have them colored with colormaps and support
    >> variable sizeing as well, right?

    Vidar> yes. i think it would be a useful addition to pylab.

I agree -- could you add a feature request to the sourceforge site
with a description of the problem and a link to this thread?

    Vidar> making the plot window smaller, each marker are constant in
    Vidar> size, taking up a larger area when reducing the plot area.
    Vidar> (this is not a big issue though.)

I see.  Yes there are times when you want the size of your markers to
be in data coordinates rather than in physical coordinates.  This can
introduce other headaches, though.

    >> for gline in ax.get_xgridlines(): xmin, xmax =
    >> gline.get_xdata() # both should be the same
    >> gline.set_visible(xmin==0.0) # visible only at x==0

    Vidar> it didn't work at all. i started out with ax = gca(),
    Vidar> started with grids turned on and off.


There are two problems here.  One is that you may need to control for
floating point inaccuracies and so want to test for "close to" zero.
This is trivial.  The more subtle one has to do with how mpl manages
ticks and gridlines.  These are created dynamically as needed, often
at draw time.  So if interactive mode is off, the actual tick
locations may not be updated until draw time, which is why the call to 

  gline.set_visible(closeto(ymin,0.0))    # visible only at y==0

isn't behaving properly.  I consider this to be a bug, but I'll have
to think a little bit about the way to fix it.  Feel free to file a
bug report on the sf site to help remind me :-)  In the meantime, here
is a workaround which manipulates the interactive and draw state
directly, as described at
http://matplotlib.sourceforge.net/installing.html

from pylab import arange, ion, draw, rand, figure, show

# turn interactive mode on
ion()  

fig = figure()
ax = fig.add_subplot(111)
ax.plot(rand(100)-0.5, rand(100)-0.5, 'go')
ax.set_xlim((-0.5, 0.5))
ax.set_xticks(arange(-0.5, 0.51, 0.1))

ax.grid(True)



def closeto(x, y, eps=1e-10):
    'return true if x close to y with some tolerance eps'
    return abs(x-y)<eps

# force a draw to create the ticks and gridlines
draw()

# now turn off all the grids except at zero
for gline in ax.get_xgridlines():
    xmin, xmax = gline.get_xdata()  # both should be the same
    gline.set_visible(closeto(xmin,0.0))    # visible only at x==0

for gline in ax.get_ygridlines():
    ymin, ymax = gline.get_ydata()  # both should be the same
    gline.set_visible(closeto(ymin,0.0))    # visible only at y==0

draw() # force a redraw
show()

===== Original message from John Hunter | Mon, 04 Jul 2005:
> One could add a kwarg to the various plot commands like
> noupdate to suppress updating the datalim,

example?


> Basically, you would like to add string symbol markers to
> scatter, and have them colored with colormaps and support
> variable sizeing as well, right?

yes. i think it would be a useful addition to pylab.


Vidar:
> what approach do you recommend for scaling the marker size
> relative to axis ranges and figure size?

John:
> I'm not sure what you are after here. marker sizes are in points, so
> you can pick the physical sizes you want.

making the plot window smaller, each marker are constant in
size, taking up a larger area when reducing the plot area.
(this is not a big issue though.)


> for gline in ax.get_xgridlines():
>    xmin, xmax = gline.get_xdata()  # both should be the same
>    gline.set_visible(xmin==0.0)    # visible only at x==0

it didn't work at all. i started out with ax = gca(),
started with grids turned on and off.

On Monday 04 July 2005 16:24, John Hunter wrote:
> >>>>> "Jesper" == Jesper Larsen <jl...@dm...> writes:
>     >> 2) How do I make a CheckButtons class with only one button? The
>     >> example below fails with a "TypeError: unsubscriptable object".
>
>     Jesper> I still don't know the answer to this problem.
>
> This was fixed in revision 1.15 of widgets.py in CVS, available at
>
>  
> http://cvs.sourceforge.net/viewcvs.py/matplotlib/matplotlib/lib/matplotlib/
>widgets.py?rev=1.15&view=log
>
> You should be able to just drop the updated file in
> site-packages/matplotlib.

Thanks John,

I works fine now but I think you need to switch lines 269 and 270 in 
widgets.py (and maybe 272 and 273 for aestetic reasons). dy is referenced 
before it is used when you have more than one check button.

Cheers,
Jesper

Hi

I'm trying to plot some error-bars in my GUI making use of the 
WXAgg-backend. My code looks like this:
if parent.error_bar: 
a.errorbar(x.ichannel,x.intensity,x.intensity_error,ecolor='k')
Now, I can plot the error bars in any arbitrary color, but the my 
actually black-on-white data are colored blue upon adding error-bars 
this way. What I want is that everything (data and their errors) is 
plotted black. Can anybody tell how to achieve this behavior?

TIA
Christian

Torsten,


> 
> I visualize experimental data in quasi-realtime while it's acquired.
> The x-axis is fixed right from the beginning.  However, the y-axis
> must be autoscaled depending on the data that's coming in.
> 
> So far, I do the following on Windows:
> 
> #--------------------------------------------------
> ion()
> 
> NaN = 0.0
> 
> x_values = arange(0, 2 * zyklen, 1.0 / number_of_values)
> y_values = total_number_of_values * [NaN]
> line, = plot(x_values, y_values)
.....
> 
> I have three questions:
> 
> 1. On Linux, I can say NaN=float("NaN"), which suppresses plot
>    points in an area where no plot exists so far.  On Windows, I seem
>    to be forced to set the un-measures interval to "0".  This is
>    uglier, is there a better way?

This looks to me like a place where you should try using masked arrays 
instead of NaN.  NaN is not uniformly supported in Python and numerix, 
but masked arrays, in both numarray and Numeric, can accomplish the same 
thing and more.  See masked_demo.py in the mpl examples subdirectory, 
and see 
http://stsdas.stsci.edu/numarray/numarray-1.3.html/module-numarray.ma.html
for an explanation of masked arrays.

Eric

Hi Tim,

On Monday 04 July 2005 10:26 pm, Tim Leslie wrote:
> Hi all,
>
> Currently when plotting data with large numbers, the scale on each axis is
> done in scientific notation, so for example you might get ticks of 1, 2, 3
> then a x10^5 to indicate that it's actually 100000, 200000, 300000.
>
> While this is a rather nice feature, I find it quite difficult to wrap my
> head around numbers which aren't of the form x10^(3n). Is there some way
> to change the default behaviour so that in the example above it would give
> 100, 200, 300 x10^3, etc?

I think your suggestion is a good one. 

Try replacing ticker.ScalarFormatter._set_orderOfMagnitude with this:

    def _set_orderOfMagnitude(self,range):
        # if scientific notation is to be used, find the appropriate exponent
        # if using a numerical offset, find the exponent after applying the offset
        locs = absolute(self.locs)
        if self.offset: self.orderOfMagnitude = math.floor(math.log10(range)/3)*3
        else: 
            if locs[0] > locs[-1]: val = locs[0]
            else: val = locs[-1]
            if val == 0: oom = 0
            else: self.orderOfMagnitude = math.floor(math.log10(val)/3)*3

I'm deep in the process of writing my thesis, and won't have time to test it. Would you?


Darren

Hi all,

Currently when plotting data with large numbers, the scale on each axis is
done in scientific notation, so for example you might get ticks of 1, 2, 3
then a x10^5 to indicate that it's actually 100000, 200000, 300000.

While this is a rather nice feature, I find it quite difficult to wrap my
head around numbers which aren't of the form x10^(3n). Is there some way
to change the default behaviour so that in the example above it would give
100, 200, 300 x10^3, etc?

Cheers,

Tim Leslie