>>>>> "Simson" == Simson Garfinkel <[EMAIL PROTECTED]> writes:
Simson> I'm very interested in putting together a document that
Simson> would be incorporated into the user's manual that would
Simson> describe the abstractions used by matplotlib. I think that
Simson> this would help me to understand it better, and would also
Simson> be useful to the community. Does anything like this
Simson> 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.
Simson> To answer Eric's most recent posting:
Simson> 1. I think that scientific notation should not be the
Simson> 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.
Simson> 2. It would be nice if there was an easy way to get commas
Simson> into numbers. (This is forever a problem; I wish that the
Simson> original C folks had thought to put commas into their
Simson> original printf formatting. I have a nice python commas
Simson> function if you want it, although you can probably create
Simson> 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.
Simson> 3. If I was going to make a major change to the API at
Simson> this point, it would be to make it so that you don't have
Simson> a class/function/ identifier called "axes" and another one
Simson> called "axis." I frequently get confused between these two
Simson> words; I imagine that non-native English speakers get
Simson> confused even more frequently. Irregular noun plurals in
Simson> English are confusing, and it probably isn't necessary to
Simson> use both. One approach would be to never allow "axis," to
Simson> only allow "xaxis" and "yaxis" and perhaps something
Simson> (either_axis?) for the abstract super-class, but this may
Simson> be a bigger change than you wish to consider at the
Simson> present time.
Yes, this is a confusing and poor nomenclature. We're probably stuck
with it at this point, since it fairly deeply ingrained.
Simson> Ah, the matplotlibrc file. It seems that you are trying
Simson> to do too much with this file. Is the point of the file
Simson> to have default graphing behavior, or to have site-wide
Simson> configuration information? You may wish to split the file
Simson> into two parts --- a config part and a graphing
Simson> preferences part --- because it seems that sometimes
Simson> people wish to change one without changing the other. Or
Simson> you may want to have explicit inheritance --- like an
Simson> "-include" feature so that a local file can just shadow
Simson> some variables and then include the master file. I
Simson> understand that this can be done with a few lines of
Simson> python at the top of a program. Of course, given that
Simson> option, you may wish to do away with the local files
Simson> 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.
Simson> Have the matplotlib developers put together a roadmap of
Simson> 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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
