Re: [matplotlib-devel] Fwd: python make.py html
On Thu, Jan 29, 2009 at 3:24 PM, Nils Wagner wrote: >>> I tried to build the HTML documentation. >>> Here are some failures Hi Nils, thanks for the report. The doc build makes every example in the examples directories. Unfortunately, a few of these have gone stale due to code rot, but we are aware of the ones you mentioned. In particular, they are in the mpl units dir, and we are trying to get better about having an automated test harness. In fact, the JPL is almost finished with a preliminary unit testing framework for mpl to catch these problems early, motivated by the units problems we have had. For you purposes though, the failures are mostly harmless, as it just means a few examples won't build thumbnails in the gallery because they are broken. JDH -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Axis.get_label question
On Thu, Jan 29, 2009 at 3:30 PM, Evans, James R wrote: > Is there a reason why Axis.get_label returns the label as a Text instance, or > should there really be set_label/get_label methods that takes a string and > set the text value of the Text instance and returns the string value of the > Text instance? > > Everywhere it is used in the code it is used in a two-step process to really > just get and set the string value of the Text instance. I don't think there is an easy answer to this one. Many of the axis getters return either artists or lists of artists, so I am disinclined to change the behavior since it does what it is documented to do and it is a minor inconvenience to have to "get_text". The end user might just as well want to set the font color, so returning the text instance facilitates that. What makes it trickier is that "label" is overloaded here, as all artists have a label property (eg the legend uses the label property for autolegending) which *is* a simple string. It's a bit more confusing still because the Axes accessor methods *do* convert these labels to strings, eg ax.get_xlabel and ax.get_xticklabels. To solve the label property clash, a better name would probably be "axislabel" or something like that, but I'm -0 on doing anything about it since in practice noone is using the label property in this way (though someone may want to down the road) . If there is a compelling use case for fixing it I'm amenable, but it looks more like a wart that is worth keeping rather than breaking someone's code is a way that may take them a while to figure out. JDH -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [sage-devel] Re: upgrading matplotlib and ignoring sage's matplotlibrc
On Thu, Jan 29, 2009 at 5:49 PM, William Stein wrote: > > On Wed, Jan 28, 2009 at 10:07 PM, Jason Grout > wrote: >> >> I just finished upgrading the matplotlib spkg to the newest version. >> See http://trac.sagemath.org/sage_trac/ticket/4774 >> >> This version of matplotlib deprecates some of the constructs found in >> Sage's matplotlibrc (which is located in $SAGE_ROOT and automatically >> copied to $DOT_SAGE if needed every time sage starts up). The result is >> a bunch of deprecation warnings every time Sage starts up (when >> matplotlib loads Sage's matplotlibrc file). In trying to figure out >> what to do about this with several other developers, one option that >> came up was just throwing away/ignoring the special Sage matplotlibrc >> and using the normal, standard defaults for matplotlibrc (including the >> standard location for a customized matplotlibrc). >> >> In investigating things more deeply, there were only a few real changes >> we made to the default behavior of matplotlib. IIRC, a few font choices >> were reordered, legends were changed to display a bit more of the >> function, and the dpi of saved images was bumped up from 80 dpi to 100 >> dpi (but this should be set when Sage saves an image anyway, so I don't >> know that this changes anything). >> >> So here's a proposal: Should Sage stop distributing a custom >> matplotlibrc, and ignore matplotlibrc files that already exist in the >> $DOT_SAGE directories? >> >> Note that if people really want to customize the matplotlib settings, >> they can always use the standard location for matplotlibrc (i.e., >> ~/.matplotlib/matplotlibrc, I think). This will clean code out of the >> bin repository and reduce startup time for sage as well. Patches which >> do this are posted to #4774. >> >> I vote yes, provided some sort of note is made in the release notes >> about the ignored matplotlibrc file. > > I vote no, since I created the $DOT_SAGE/matplotlib directory > *precisely* because of problems that happen if you were to do what you > describe above. For starters, people often also used a system-wide > Python with their own version of matplotlib -- then end result was > that if they tried to switch back and forth between sage and > python/ipython/matplotlib, they would get tons of deprecation > warnings, since the systemwide version of matplotlib is often > different than the sage version. > > Second, how will what you suggest solve any problems? All you do is > move the problem from $DOT_SAGE/matplotlib/matplotlibc to > $HOME/.matplotlibrc. It's exactly the same problem. You just > temporarily put it off for a while. > > I *wish* matplotlib would replace their stupid deprecation warnings by > something that just updates the matplotlibrc file, and say makes a > copy of the old one. Is there any way we could catch the warnings and > if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file, > then put a new matplotlibrc in place and print a message that this > just happened? You could do that by making slightly patching > matplotlib as well. I think matplotlib's behavior of emitting > warnings but doing nothing helpful to resolve them is just obnoxious. Maybe matplotlib developers would accept a patch fixing this. Ondrej -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [sage-devel] Re: upgrading matplotlib and ignoring sage's matplotlibrc
On Fri, Jan 30, 2009 at 9:30 AM, Ondrej Certik wrote: >> I *wish* matplotlib would replace their stupid deprecation warnings by >> something that just updates the matplotlibrc file, and say makes a >> copy of the old one. Is there any way we could catch the warnings and >> if they occur move $DOT_SAGE/matplotlib/matplotlibrc to another file, >> then put a new matplotlibrc in place and print a message that this >> just happened? You could do that by making slightly patching >> matplotlib as well. I think matplotlib's behavior of emitting >> warnings but doing nothing helpful to resolve them is just obnoxious. > > Maybe matplotlib developers would accept a patch fixing this. To address this problem, we went to an all commented out rc file. That way, when people change their mpl version, they don't get deprecation warnings. Only people who make specific changes to their rc file will get deprecation warnings. Those people will know what rc is and how to change it. I'm disinclined to overwrite files people have changed -- they may be running multiple versions of mpl under different scenarios, and each version would be competing with one another to overwrite the file. mpl has a general philospohy of not trying to be too helpful -- we want to make it easy for users to customize, we don't want to customize it for them. The verbose deprecation warnings are in my opinion mostly a solved problem: get a new rc file which is all commented out. Just change the things you want to change, and you will get very few warnings going forward. When you get them, fix the problem and you will get no more warnings. JDH -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What would you like to see in a book about Matplotlib?
Note: Posted to matplotlib-devel and debian-science. Sandro, Firstly, good luck with the book. The sort of book I'd buy would explain how to use the combination of matplotlib/ipython/scipy/numpy to analyse data. > - what are you using matplotlib for? I want to use matplotlib/ipython/numpy/scipy for analysis of experimental data - plotting and fitting models to it. Also perhaps simulation of the data. I have also wanted to use matplotlib to plot data as it was acquired - see below. I've not really used matplotlib in anger - but am likely to do so in the future (and it would have been useful during my PhD had it been around then). > - what are the things you like the most of matplotlib, that you want > to give emphasis to? And why? Quality plots. The ability to add TeX labels. I've been keeping an eye on matplotlib for several years - it looks good. I really must spend some time exploring it. > - what are the (basic) things that, when you were beginning to use > matplotlib, you wanted to see grouped up but couldn't find? > - what would you like to see in a book about matplotlib? Start off by reading data from a file, plotting it and fitting a function to that data. Often, several scans are in the same data file. An elegant solution to reading data something like this example would be useful. # Scan: 1 # Time: 18:00 # Temperature: 21 # t data 1 12 2 33 3 14 4 40 5 60 # Scan: 2 # Time: 18:02 # Temperature: 30 # t data 1 22 2 33 3 44 4 55 And so on. Fitting a function to several data sets - with some of the parameters fitted to both sets of data and some not would be useful. > - what are some those advanced feature that made you yell "WOW!!" ? > - what are the things you'd like to explore of matplotlib and never > had time to do? Plotting with related scales Sometimes it is useful to plot related scales on x1 and x2 axes. I've come across this several times in different contexts. In its simplest form, there is a linear relationship between the axes. In a mechanical test, you might want extension on the x1 axis and strain on the x2 axis (for example). Sometimes there is not a linear relationship. For example you might want to plot frequency (or photon energy) on x1 and wavelength on x2. An even more complex example is a Hall-Petch plot: (Yield Stress) = k/sqrt(Grain Size) So plotting 1/Sqrt(Grain Size) on the X1 axis gives a linear plot, but it would be useful to plot the grain size on the X2 scale. ipython and emacs - Suppose I want to write a script to analyse some data (perhaps I want a record of what I've done, or perhaps I'd like to perform the same analysis on several data sets). I'd probably do so in emacs - but it is useful to do some experimentation in ipython - tab completion is particularly useful. I feel there must be a good way to do my experimentation in ipython and save the important bits in emacs - but I've not sat down and worked out an efficient way of doing this. Data aqcuisition and experimental control: - Writing a simple application to acquire data - ideally from multiple sources and plot the data as it is acquired. In my case I wanted to combine mechanical with electrical tests. A couple of interesting articles by G Varoquaux are listed at http://wiki.debian.org/DebianScience/DataAcquisition This is perhaps beyond the scope of the book, but it has come up on the mailing lists a couple of times. The ideal application would have a gui for simple use, but a command line (probably ipython) for more more complex use - perhaps performing a series of tests under different conditions. Some discussion of plotting non gridded 2d data should also be in there. > > Your suggestions are really appreciated :) And wish me good luck! I don't think it is the thrust of your book, but another book I was looking for is "A cookbook of Numerical simulations of classic physics/engineering problems". For use by physicists/engineers who don't want to rewrite things from scratch. Good luck. Chris -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
