wiki

I agree.

I'm very confused by the wiki in general. I click on "wiki" and it takes me to something that doesn't obviously have anything to do with matplotlib... Like, what's scipy.org? Is it a company? Who is EnThought?

Amy I allowed to contribute to the wiki? It doesn't look like it. The whole thing is not very friendly.

And what is this whole MoinMoin thing?

···

----- Original Message ----- From: "Angus McMorland" <amcmorl@...287...>

We really shoud wiki more of these email discussions as they come
along. It's so much easier to search there, since things are in some
sort of logical arrangement.

I'm very confused by the wiki in general. I click on "wiki" and it takes me
to something that doesn't obviously have anything to do with matplotlib...

Well, it does say: matplotlib cookbook.

Like, what's scipy.org? Is it a company? Who is EnThought?

Oh.
What are you using to manipulate arrays ? numarray, Numeric, or numpy ?
Assuming that you use numpy, then you must know what scipy is, right ? If
not, well, br
scipy.org is just a central site for numpy/scipy-related information.
Enthought is a private company that works extensively with Python and numpy
in particular, and that hosts the site.

Amy I allowed to contribute to the wiki? It doesn't look like it. The whole
thing is not very friendly.

It's a wiki, so yes, you can contribute. No, it's not especially friendly, in
the sense that nobody's here to hold your hand.

And what is this whole MoinMoin thing?

"MoinMoin is a Python WikiClone, based on PikiPiki. "
This converstaion is really becoming surrealistic.

I'm very confused by the wiki in general. I click on "wiki" and it takes me
to something that doesn't obviously have anything to do with matplotlib...

Well, it does say: matplotlib cookbook.

Like, what's scipy.org? Is it a company? Who is EnThought?

Oh.
What are you using to manipulate arrays ? numarray, Numeric, or numpy ?
Assuming that you use numpy, then you must know what scipy is, right ? If
not, well, br
scipy.org is just a central site for numpy/scipy-related information.
Enthought is a private company that works extensively with Python and numpy
in particular, and that hosts the site.

Hi, Pierre. There's a lot of assumptions here.

I do most of my own manipulations in SQL and with custom-written programs in C, C++, and Python.

I sort of know what numarray, Numeric and numpy are, but I don't care all that much. I'm just interested in matplotlib for the plotting.

The point of my email (and the questions below) is that the entire scipy.org website is written for people who already know what's going on. If you want to expand the user community (and simultaneously cut down on questions) you need to make things dramatically more understandable than they currently are.

A related problem is the MoinMoin wiki. It is not a widely used wiki and it has many usability problems. It is dramatically harder to use than, say, mediawiki.

···

On Dec 16, 2006, at 11:58 AM, Pierre GM wrote:

Amy I allowed to contribute to the wiki? It doesn't look like it. The whole
thing is not very friendly.

It's a wiki, so yes, you can contribute. No, it's not especially friendly, in
the sense that nobody's here to hold your hand.

And what is this whole MoinMoin thing?

"MoinMoin is a Python WikiClone, based on PikiPiki. "
This converstaion is really becoming surrealistic.

Hi, Pierre. There's a lot of assumptions here.

Indeed, and I apologize

I sort of know what numarray, Numeric and numpy are, but I don't care
all that much. I'm just interested in matplotlib for the plotting.

Well, matplotlib relies on some packages to handle data arrays. It's probably
a good idea to check what you have below the hood, just in case something
goes wrong. It'll make things easier to help you.

The point of my email (and the questions below) is that the entire
scipy.org website is written for people who already know what's going
on. If you want to expand the user community (and simultaneously cut
down on questions) you need to make things dramatically more
understandable than they currently are.

That's true, and I guess that's the reason why there's a wiki. Please feel
free to add your comments and suggestions.

A related problem is the MoinMoin wiki. It is not a widely used wiki
and it has many usability problems. It is dramatically harder to use
than, say, mediawiki.

But it happens to be the solution that has been chosen.

Hi, Pierre. There's a lot of assumptions here.

Indeed, and I apologize

I sort of know what numarray, Numeric and numpy are, but I don't care
all that much. I'm just interested in matplotlib for the plotting.

Well, matplotlib relies on some packages to handle data arrays. It's probably
a good idea to check what you have below the hood, just in case something
goes wrong. It'll make things easier to help you.

Thanks. In fact, after I read through the matplotlib tutorial and user's manual, I downloaded and read the numpy manual too. It's a nice package. I especially liked the line about numpy not making things possible that weren't possible before, but that it just allows things to be finished before we are dead.

Overall, the package is really impressive. I don't like the way that arrays aren't resizable, though. And for the work I'm doing, I have a different number of observations and data points on different days, so it's a pain that the current boxplot infrastructure expects all of the boxes to be in a single array. Hence my questions.

The point of my email (and the questions below) is that the entire
scipy.org website is written for people who already know what's going
on. If you want to expand the user community (and simultaneously cut
down on questions) you need to make things dramatically more
understandable than they currently are.

That's true, and I guess that's the reason why there's a wiki. Please feel
free to add your comments and suggestions.

Thanks. I will.

A related problem is the MoinMoin wiki. It is not a widely used wiki
and it has many usability problems. It is dramatically harder to use
than, say, mediawiki.

But it happens to be the solution that has been chosen.

Yep.

···

On Dec 16, 2006, at 1:01 PM, Pierre GM wrote:

And for the work I'm doing, I have a
different number of observations and data points on different days,
so it's a pain that the current boxplot infrastructure expects all of
the boxes to be in a single array. Hence my questions.

Ah OK, now I get it. Sorry for being a bit slow today.
So yes, there's a problem here. The sequence is transformed into an array
with 'asarray', which obviously won't work if you have different sizes of
dataset.

But there's a trick, tested on numpy:

import numpy
set1 = (rand(50)+1) * 100
set2 = (rand(25)+2) * 100
data = array([set1,set2], dtype=numpy.object_)
boxplot(data,positions=[732659.,732660.])

The trick here is to force the data as objects, and not as floats. Your array
is in fact an array of arrays of different sizes. That's enough to fool
asarray.

Pierre GM wrote:

And for the work I'm doing, I have a
different number of observations and data points on different days,
so it's a pain that the current boxplot infrastructure expects all of
the boxes to be in a single array. Hence my questions.

Ah OK, now I get it. Sorry for being a bit slow today.
So yes, there's a problem here. The sequence is transformed into an array with 'asarray', which obviously won't work if you have different sizes of dataset.

But there's a trick, tested on numpy:

import numpy
set1 = (rand(50)+1) * 100
set2 = (rand(25)+2) * 100
data = array([set1,set2], dtype=numpy.object_)
boxplot(data,positions=[732659.,732660.])

The trick here is to force the data as objects, and not as floats. Your array is in fact an array of arrays of different sizes. That's enough to fool asarray.

It sounds like the real problem is that the initial use of asarray in boxplot is a bug--it should transparently support an object array, as you suggest (but numpy only), or an ordinary array, *or* a list or tuple of data vectors, and all this should be clear in the docstring and the example. Correct? I hope so, because I have made the change in svn. (Well, maybe not enough changes to the example yet.)

Eric

Fully agreed. There's no need for the transformation to array: the only
variable which is array-related is the number of columns (viz, the number of
boxes to plot).
OK, there's also that:
for i,pos in enumerate(positions):
            d = x[:,i]
But it'd be as easy to enumerate the array (after a first transpose, if its a
regular ndarray...)

···

On Saturday 16 December 2006 16:02, Eric Firing wrote:

It sounds like the real problem is that the initial use of asarray in
boxplot is a bug--it should transparently support an object array, as
you suggest (but numpy only), or an ordinary array, *or* a list or tuple
of data vectors, and all this should be clear in the docstring and the
example. Correct? I hope so, because I have made the change in svn.
(Well, maybe not enough changes to the example yet.)

Yep. I would like to pass in a list of lists, where each sublist (or array)
describes a boxplot to plot.

Meanwhile, i've been having fun with histograms. The Y axis labels are a
pain. I think defaulting to scientific notation, as matplotlib frequently
does, is annoying...

···

___
Sent with SnapperMail
www.snappermail.com

...... Original Message .......
On Sat, 16 Dec 2006 11:02:28 -1000 "Eric Firing" <efiring@...202...> wrote:

Pierre GM wrote:

And for the work I'm doing, I have a
different number of observations and data points on different days,
so it's a pain that the current boxplot infrastructure expects all of
the boxes to be in a single array. Hence my questions.

Ah OK, now I get it. Sorry for being a bit slow today.
So yes, there's a problem here. The sequence is transformed into an

array

with 'asarray', which obviously won't work if you have different sizes

of

dataset.

But there's a trick, tested on numpy:

import numpy
set1 = (rand(50)+1) * 100
set2 = (rand(25)+2) * 100
data = array([set1,set2], dtype=numpy.object_)
boxplot(data,positions=[732659.,732660.])

The trick here is to force the data as objects, and not as floats. Your array
is in fact an array of arrays of different sizes. That's enough to fool
asarray.

It sounds like the real problem is that the initial use of asarray in
boxplot is a bug--it should transparently support an object array, as
you suggest (but numpy only), or an ordinary array, *or* a list or tuple
of data vectors, and all this should be clear in the docstring and the
example. Correct? I hope so, because I have made the change in svn.
(Well, maybe not enough changes to the example yet.)

Eric

Simson L. Garfinkel's Treo 700p wrote:

Yep. I would like to pass in a list of lists, where each sublist (or array) describes a boxplot to plot.

This is now present in svn.

Meanwhile, i've been having fun with histograms. The Y axis labels are a pain. I think defaulting to scientific notation, as matplotlib frequently does, is annoying...

I think you are not the first who has been annoyed by this, so I added a couple of methods to the ScalarFormatter class, which is used by default for labelling ticks with linear axes.

If you have a plot with linear axes and you want to turn off scientific notation on the x-axis, for example, this will do it:

gca().xaxis.major.formatter.set_scientific(False)

(If plotting interactively with ipython you will need to force a redraw. The draw() command is one way to do it.)

If you want to use scientific notation but with a different threshold, you can do:

gca().xaxis.major.formatter.set_powerlimits((-2,3))

to change the thresholds from the default, 1e-3 and 1e4, to 1e-2 and 1e3.

It may make sense to have a simpler interface to this--especially simply turning scientific notation on or off on one or both axes--at the Axes class level and the pylab level, but I thought I would take it a step at a time. I am open to suggestions as to method/function name and signature. The matplotlibrc interface could even be used if people really want to be able to make no-scientific-notation their default, but I am wary of dumping more and more knobs into matplotlibrc.

Eric

A friend of mine from MIT who is just finishing his PhD was over for dinner tonight. We discussed the learning curve of matplotlib and compared it with other plotting systems that we've both used, including gnuplot & PyX.

My friend said that he thought that the learning curve was really high, but that he had been motivated to do something with it, so he had persevered. He wasn't entirely happy with what he got, but it was okay. He co-author on a paper, though, couldn't figure it out and thought that it wasn't worth the effort.

Interestingly enough, Crossroads, the ACM student publication, had a really interested article on this in the Summer 2006 issue. The article, by Christopher Scaffidi, is titled "Why Are APIs Difficult to Learn and Use?" I would recommend it to anyone who is developing an API or a package. You can read it at http://www.acm.org/crossroads/xrds12-4/difficultapis.html. The gist of the article is that documentation is extremely important, after which "hello world" programs can be helpful. However, it's really important to have an API that is orthogonal and has the right abstractions.

One of the things that I would have added to the article is the importance of having decent defaults.

I'm very interested in putting together a document that would be incorporated into the user's manual that would describe the abstractions used by matplotlib. I think that this would help me to understand it better, and would also be useful to the community. Does anything like this currently exist?

To answer Eric's most recent posting:

1. I think that scientific notation should not be the default, unless numbers exceed 1E+7.
2. It would be nice if there was an easy way to get commas into numbers. (This is forever a problem; I wish that the original C folks had thought to put commas into their original printf formatting. I have a nice python commas function if you want it, although you can probably create one that is more efficient.)

3. If I was going to make a major change to the API at this point, it would be to make it so that you don't have a class/function/identifier called "axes" and another one called "axis." I frequently get confused between these two words; I imagine that non-native English speakers get confused even more frequently. Irregular noun plurals in English are confusing, and it probably isn't necessary to use both. One approach would be to never allow "axis," to only allow "xaxis" and "yaxis" and perhaps something (either_axis?) for the abstract super-class, but this may be a bigger change than you wish to consider at the present time.

It may make sense to have a simpler interface to this--especially simply turning scientific notation on or off on one or both axes--at the Axes class level and the pylab level, but I thought I would take it a step at a time. I am open to suggestions as to method/function name and signature. The matplotlibrc interface could even be used if people really want to be able to make no-scientific-notation their default, but I am wary of dumping more and more knobs into matplotlibrc.

Ah, the matplotlibrc file. It seems that you are trying to do too much with this file. Is the point of the file to have default graphing behavior, or to have site-wide configuration information? You may wish to split the file into two parts --- a config part and a graphing preferences part --- because it seems that sometimes people wish to change one without changing the other. Or you may want to have explicit inheritance --- like an "-include" feature so that a local file can just shadow some variables and then include the master file. I understand that this can be done with a few lines of python at the top of a program. Of course, given that option, you may wish to do away with the local files entirely. I'm not sure.

Have the matplotlib developers put together a roadmap of their directions that they want to take this project?

-Simson

I'm very interested in putting together a document that

    > would be incorporated into the user's manual that would
    > describe the abstractions used by matplotlib. I think that
    > this would help me to understand it better, and would also
    > be useful to the community. Does anything like this
    > currently exist?

The best starting point for this is the "Leftwich tutorial"

  http://matplotlib.sourceforge.net/leftwich_tut.txt

This is written in structured text. If you are interested in
extending this (and a lot can be done here) the best place to start
IMO is to get this into the proper format for the matplotlib wiki and
uploaded there, so we can all make contributions to it. There may be
minor differences in the structured text format that need to be
addressed.

    > To answer Eric's most recent posting:

    > 1. I think that scientific notation should not be the
    > default, unless numbers exceed 1E+7.

I agree with this -- scientific notation kicks in too soon IMO. I
think an rc setting would be fine. I am not adverse to more rc
settings personally. I haven't seen too many problems arising from
having a lot of rc settings.

    > 2. It would be nice if there was an easy way to get commas
    > into numbers. (This is forever a problem; I wish that the
    > original C folks had thought to put commas into their
    > original printf formatting. I have a nice python commas
    > function if you want it, although you can probably create
    > one that is more efficient.)

This would be a great custom formatter -- see
http://matplotlib.sf.net/matplotlib.ticker.html for details on the
Formatter. Please contribute one if you can.

    > 3. If I was going to make a major change to the API at
    > this point, it would be to make it so that you don't have
    > a class/function/ identifier called "axes" and another one
    > called "axis." I frequently get confused between these two
    > words; I imagine that non-native English speakers get
    > confused even more frequently. Irregular noun plurals in
    > English are confusing, and it probably isn't necessary to
    > use both. One approach would be to never allow "axis," to
    > only allow "xaxis" and "yaxis" and perhaps something
    > (either_axis?) for the abstract super-class, but this may
    > be a bigger change than you wish to consider at the
    > present time.

Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.

    > Ah, the matplotlibrc file. It seems that you are trying
    > to do too much with this file. Is the point of the file
    > to have default graphing behavior, or to have site-wide
    > configuration information? You may wish to split the file
    > into two parts --- a config part and a graphing
    > preferences part --- because it seems that sometimes
    > people wish to change one without changing the other. Or
    > you may want to have explicit inheritance --- like an
    > "-include" feature so that a local file can just shadow
    > some variables and then include the master file. I
    > understand that this can be done with a few lines of
    > python at the top of a program. Of course, given that
    > option, you may wish to do away with the local files
    > entirely. I'm not sure.

The rc file is meant to support local customization, and directory
specific files are meant to support project specific customizations.
The idea here is: you may want a general configuration for most plots,
interactive plotting, etc, but you may want something entirely
different for a directory which contains a figure for a journal
article: PS backend, latex text, larger fontsizes, thicker lines...

The current implementation certainly has some limitations: we'd prefer
the file to be python rather than our own yet-another-rc-file-markup
and yes, we'd like to support includes and overrides with a basic
inheritance and namespace support, which we would get for free by
simply making the rc file python. This is an idea waiting to be
implemented. We'd probably borrow some work from recent changes to
ipython which were implemented to solve some of the same problems.

    > Have the matplotlib developers put together a roadmap of
    > their directions that they want to take this project?

  http://matplotlib.sf.net/goals.html

though it is not updated as often as it should be and is not entirely current.

JDH

    > 3. If I was going to make a major change to the API at
    > this point, it would be to make it so that you don't have
    > a class/function/ identifier called "axes" and another one
    > called "axis." I frequently get confused between these two
    > words; I imagine that non-native English speakers get
    > confused even more frequently. Irregular noun plurals in
    > English are confusing, and it probably isn't necessary to
    > use both. One approach would be to never allow "axis," to
    > only allow "xaxis" and "yaxis" and perhaps something
    > (either_axis?) for the abstract super-class, but this may
    > be a bigger change than you wish to consider at the
    > present time.

Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.

It's never to late to change something. For any successful project, there will always be more users in the future than in the past. The key thing is to make the change without breaking backwards compatibility. But that's not hard: you can accept the old value while nevertheless standardizing on the new one.

    > Ah, the matplotlibrc file. It seems that you are trying
    > to do too much with this file. Is the point of the file
    > to have default graphing behavior, or to have site-wide
    > configuration information? You may wish to split the file
    > into two parts --- a config part and a graphing
    > preferences part --- because it seems that sometimes
    > people wish to change one without changing the other. Or
    > you may want to have explicit inheritance --- like an
    > "-include" feature so that a local file can just shadow
    > some variables and then include the master file. I
    > understand that this can be done with a few lines of
    > python at the top of a program. Of course, given that
    > option, you may wish to do away with the local files
    > entirely. I'm not sure.

The rc file is meant to support local customization, and directory
specific files are meant to support project specific customizations.
The idea here is: you may want a general configuration for most plots,
interactive plotting, etc, but you may want something entirely
different for a directory which contains a figure for a journal
article: PS backend, latex text, larger fontsizes, thicker lines...

The problem with the RC file this way, though, is that I can give you a pice of python code and it will plot differently on your computer than on mine because of a change in your rc file.

If you think that's okay, then it's okay. You're the designer, not me! But it is clearly a concern that I would have.

The current implementation certainly has some limitations: we'd prefer
the file to be python rather than our own yet-another-rc-file-markup
and yes, we'd like to support includes and overrides with a basic
inheritance and namespace support, which we would get for free by
simply making the rc file python. This is an idea waiting to be
implemented. We'd probably borrow some work from recent changes to
ipython which were implemented to solve some of the same problems.

    > Have the matplotlib developers put together a roadmap of
    > their directions that they want to take this project?

  http://matplotlib.sf.net/goals.html

Thanks!

···

though it is not updated as often as it should be and is not entirely current.

JDH

The axis/axes function names are Matlab relics, so to have used something else would probably have caused other complaints.

On the bright side, at least w/matplotlib, you're not paying out the wazoo :slight_smile: for such things.

--b

···

On Dec 16, 2006, at 8:10 PM, John Hunter wrote:

    > 3. If I was going to make a major change to the API at
    > this point, it would be to make it so that you don't have
    > a class/function/ identifier called "axes" and another one
    > called "axis." I frequently get confused between these two
    > words; I imagine that non-native English speakers get
    > confused even more frequently. Irregular noun plurals in
    > English are confusing, and it probably isn't necessary to
    > use both. One approach would be to never allow "axis," to
    > only allow "xaxis" and "yaxis" and perhaps something
    > (either_axis?) for the abstract super-class, but this may
    > be a bigger change than you wish to consider at the
    > present time.

Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.

On the bright side, at least w/matplotlib, you're not paying out the
wazoo :slight_smile: for such things.

I actually made the mistake of buying the matlab student edition.

John Hunter wrote:
[...]

    > To answer Eric's most recent posting:

    > 1. I think that scientific notation should not be the
    > default, unless numbers exceed 1E+7.

I agree with this -- scientific notation kicks in too soon IMO. I
think an rc setting would be fine. I am not adverse to more rc
settings personally. I haven't seen too many problems arising from
having a lot of rc settings.

I have added an rc setting called axes.formatter.limits and set the defaults to -7, 7, so that now scientific notation starts at 1e+-7. This may be too large for some tastes--but at least now it is configurable. Maybe other users will comment on what they think the defaults should be. I don't have a strong opinion.

I also added a convenience method to the Axes class (called ticklabel_format())to make it easier to turn scientific notation on or off on either or both axes, with the idea that other formatting control might be added to the method later. I have not made the method a pylab function yet; I would rather wait until it settles down and people have had a chance to request a different name or turn thumbs down on the whole thing or whatever.

Suggestions for better names or other aspects of these API additions are welcome. I have found it difficult to come up with short and descriptive names, and don't feel I have done particularly well.

    > 2. It would be nice if there was an easy way to get commas
    > into numbers. (This is forever a problem; I wish that the
    > original C folks had thought to put commas into their
    > original printf formatting. I have a nice python commas
    > function if you want it, although you can probably create
    > one that is more efficient.)

I wrote part of an "add_commas" function with the idea of letting its use be an option in the ScalarFormatter--I think this would be better than adding a whole separate Formatter. But it is not finished (lacks support for signs and exponential notation) and I need to do other things now. Simson, if you have not already plunged into John's suggestion below, I would be happy to see your comma function--please send it. But if you are inspired to come up with a comma-adding formatter or modification to ScalarFormatter, that's even better.

This would be a great custom formatter -- see
http://matplotlib.sf.net/matplotlib.ticker.html for details on the
Formatter. Please contribute one if you can.

[...]
Eric

There are good reasons to use scientific notation for smaller numbers than
10e+-7: We dont want neighboring tick labels to run into each other on the x
axis, and we dont tick labels to run out of the window on the y axis. For
examples, see the attachments at the bottom of this page:
http://sourceforge.net/tracker/index.php?func=detail&aid=1196027&group_id=80706&atid=560720

Darren

···

On Saturday 16 December 2006 20:00, Simson Garfinkel wrote:

1. I think that scientific notation should not be the default, unless
numbers exceed 1E+7.

It really depends on your audience as to whether or not 1,000,000 through 9,000,000 is better displayed in scientific notation or not. For audiences that I frequently present to, any scientific notation is just unacceptable. You can add quantifiers (like KBps, MBps, GBps), but presenting something a 5e+5 Bps will just be lost. You *might* get away with e+3, e+6, and e+9, but never the other e's.

···

On Dec 18, 2006, at 8:53 AM, Darren Dale wrote:

On Saturday 16 December 2006 20:00, Simson Garfinkel wrote:

1. I think that scientific notation should not be the default, unless
numbers exceed 1E+7.

There are good reasons to use scientific notation for smaller numbers than
10e+-7: We dont want neighboring tick labels to run into each other on the x
axis, and we dont tick labels to run out of the window on the y axis. For
examples, see the attachments at the bottom of this page:
http://sourceforge.net/tracker/index.php?func=detail&aid=1196027&group_id=80706&atid=560720

Darren

Where I come from (Europe) 9,000,000 means 9.0 and 9.000.000 means
what you mean. That is why there is an international standard of
having 9 000 000. Basically these things should be tunable through
simple rc options.
As to the point that different rc options can produce different
results on different machines, as far as I am aware, all options can
be overridden in the script itself (correct me if I am wrong?).

Best regards,
John

···

On 18/12/06, Simson Garfinkel <simsong@...1340...> wrote:

It really depends on your audience as to whether or not 1,000,000
through 9,000,000 is better displayed in scientific notation or not.
For audiences that I frequently present to, any scientific notation
is just unacceptable. You can add quantifiers (like KBps, MBps,
GBps), but presenting something a 5e+5 Bps will just be lost. You
*might* get away with e+3, e+6, and e+9, but never the other e's.

John Hunter wrote:
[...]

> > To answer Eric's most recent posting:
>
> > 1. I think that scientific notation should not be the
> > default, unless numbers exceed 1E+7.
>
> I agree with this -- scientific notation kicks in too soon IMO. I
> think an rc setting would be fine. I am not adverse to more rc
> settings personally. I haven't seen too many problems arising from
> having a lot of rc settings.

I have added an rc setting called axes.formatter.limits and set the
defaults to -7, 7, so that now scientific notation starts at 1e+-7. This
may be too large for some tastes--but at least now it is configurable.
Maybe other users will comment on what they think the defaults should
be. I don't have a strong opinion.

I think think the name for this rc setting could be improved. How about:

(x,y)tick.scientific_notation.threshold
or
axes.scientific_notation.threshold

I also added a convenience method to the Axes class (called
ticklabel_format())to make it easier to turn scientific notation on or
off on either or both axes, with the idea that other formatting control
might be added to the method later. I have not made the method a pylab
function yet; I would rather wait until it settles down and people have
had a chance to request a different name or turn thumbs down on the
whole thing or whatever.

Suggestions for better names or other aspects of these API additions are
welcome.

Something like use_scientific_notation() would be much clearer, in my opinion.

···

On Sunday 17 December 2006 20:06, Eric Firing wrote: