Re: [matplotlib-devel] Inches?
I agree that we have to remain in inches internally. Non-metric units are pretty ingrained in the printing world (not just in matplotlib) -- Postscript, for example, always does page sizes in inches, even if you're using a "metric" page size like A4. The current definition of a point as 1/72 of a modern inch is also fairly standard worldwide. Even printers in France, for example, are spec'd in points par pouce (ppp), which is exactly equivalent to dots per inch (dpi). However, that's just an implementation detail we have to stick with. Matplotlib has Figure.get/set_size_inches now. What's to stop us from adding get/set_size_cm, and doing the conversion right there? There might be some rounding error, but I don't think it matters in this particular case. We would probably also want to add a "figsize_cm" kwarg to the Figure constructor (which would be mutually exclusive to "figsize"). What do you think? Cheers, Mike Eric Firing wrote: > Coincidentally, I was just thinking about this a couple days ago, when > reviewing the units kwarg of the colorbar. I decided then that adding a > cm option just wasn't worth even the small amount of extra code; inches > are fairly deeply embedded, as witness the standard "dpi" way of > specifying pixel size on output devices. > > I do understand the rationale; many of us in the US would have preferred > if the US had continued with the transition to metric units instead of > backing off. For mpl right now, however, I don't think it is worthwhile > to add the extra complexity, no matter how small it may seem, of a > general cm option, or a great number of docstring additions saying > "There are 2.54 cm per inch." > > Somewhere along the line, it may make sense to support the metric system > better in mpl. > > Eric > > Olivier Verdier wrote: >> Hi! >> >> >> I really enjoy using matplotlib but something is strange with the units >> used for the figure size. It seems that it must be in inches? (I'm >> thinking of the figure.figsize value in matplotlibrc, for instance). >> >> >> Of course if one knows how long an inch is (apparently 2.5 cm) it's not >> difficult to convert a value in mm or cm to inches but most people >> around here (Europe) have never used inches in their life. >> >> >> I believe that centimetres (or millimetres) should be the default unit >> for all lengths because it is familiar to everybody... as far as I know. >> >> >> Then you might also allow the customary local units of various >> countries. If you really want to only use inches then i think that you >> should specify that an inch corresponds to 2.5 cm wherever a value in >> inches is needed. Most users of matplotlib have no clue as to how long >> an inch is. >> >> >> I'd be willing to help on that matter if you all agree that such a >> change would be a good idea. >> >> >> Thanks!! >> >> >> == Olivier >> >> >> >> >> - >> This SF.net email is sponsored by: Splunk Inc. >> Still grepping through log files to find problems? Stop. >> Now Search log events and configuration files using AJAX and a browser. >> Download your FREE copy of Splunk now >> http://get.splunk.com/ >> >> >> >> >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Inches?
Eric Firing wrote: > Somewhere along the line, it may make sense to support the metric system > better in mpl. It seems to me that the "right" way to do this is to use some sort of "array-with_units" class. Then what MPL would except was a "length", and the user would specify what they want. i.e: figure(figsize = units.inches((8.5,11)) rather than: figure(figsize = (8.5, 11), units=inches) Though this does make for more typing. With the later way, a system default for units could be used more easily. I really want a unit class like this for other stuff anyway. -- just thinking in email -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Missing or broken examples
I've been relying very heavily on the examples lately to test my refactored branch of matplotlib. In doing so, I've discovered a few that are currently broken in matplotlib's trunk. I'm reporting these just to bring them to the attention of the list, not because they are priority bugs for me. Some of these may simply be old and should be removed. Let me know if you need any more information for them. I've also run backend_driver.py through a code coverage tool (coverage.py) and identified a few large parts of the code that weren't covered. I added a dozen or so existing examples to backend_driver, and now though there are lots of little places that never get run (mainly error cases and such), the code coverage of backend_driver is quite good. The only high-level method in axes.py that isn't being tested is cohere(). Does anyone have a test for it that could be added? Errors follow. Cheers, Mike > python agg_resize.py Traceback (most recent call last): File "agg_resize.py", line 7, in interp = agg.span_interpolator_linear(imMatrix); AttributeError: 'module' object has no attribute 'span_interpolator_linear' > python embedding_in_wx2.py [The y-axis labels are being cut off at the bottom of the figure.] > python image_slices_viewer.py [It says the "use the scroll wheen to navigate images" [sic], but the scroll wheel doesn't appear to do anything in TkAgg on Linux.] > python keypress_demo.py [Pressing "g" to toggle the grid causes the grid to flash momentarily and then disappear again.] > python bar_unit_demo.py Traceback (most recent call last): File "bar_unit_demo.py", line 14, in p1 = ax.bar(ind, menMeans, width, color='r', bottom=0*cm, yerr=menStd) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 3307, in bar fmt=None, ecolor=ecolor, capsize=capsize) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 3727, in errorbar lower = y-yerr TypeError: unsupported operand type(s) for -: 'int' and 'TaggedValue' > python ellipse_with_units.py Traceback (most recent call last): File "ellipse_with_units.py", line 36, in ax.add_patch(e1) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1143, in add_patch self._update_patch_limits(p) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1150, in _update_patch_limits p.get_transform(), p.get_verts()) File "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/patches.py", line 814, in get_verts x = width/2. * npy.cos(theta) TypeError: unsupported operand type(s) for /: 'TaggedValue' and 'float' -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Missing or broken examples
On 10/29/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I've also run backend_driver.py through a code coverage tool > (coverage.py) and identified a few large parts of the code that weren't > covered. I added a dozen or so existing examples to backend_driver, and > now though there are lots of little places that never get run (mainly > error cases and such), the code coverage of backend_driver is quite > good. The only high-level method in axes.py that isn't being tested is > cohere(). Does anyone have a test for it that could be added? Once we get these bugs cleared up, and the tkagg segfault I mentioned earlier, it is probably a good time to prepare for a new release. There have been lots of major enhancements in the trunk since 0.90.1, most importantly the new mathtext. I encourage everyone to visit the bugs and patches page and let's knock out as many as we can and get any new features from developers trees in, and shoot for a release next week. After that, are you getting close Michael to merging your branch into the trunk? JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Missing or broken examples
On 10/29/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I've been relying very heavily on the examples lately to test my > refactored branch of matplotlib. In doing so, I've discovered a few > that are currently broken in matplotlib's trunk. I'm reporting these > just to bring them to the attention of the list, not because they are > priority bugs for me. Some of these may simply be old and should be > removed. Let me know if you need any more information for them. > I've also run backend_driver.py through a code coverage tool > (coverage.py) and identified a few large parts of the code that weren't > covered. I added a dozen or so existing examples to backend_driver, and > now though there are lots of little places that never get run (mainly > error cases and such), the code coverage of backend_driver is quite > good. The only high-level method in axes.py that isn't being tested is > cohere(). Does anyone have a test for it that could be added? This is great -- our backend _driver is a poor man's unit test, but it has served us well and it's good to make the most of it. I've added a cohere_demo.py and added it to backend_driver. > > python agg_resize.py > Traceback (most recent call last): >File "agg_resize.py", line 7, in > interp = agg.span_interpolator_linear(imMatrix); > AttributeError: 'module' object has no attribute 'span_interpolator_linear' Hmm, for some reason the following lines are commented out of swig.agg.i //%include "agg_span_interpolator_linear.h" //%template(span_interpolator_linear_affine) agg::span_interpolator_linear; //%include "agg_span_image_filter.i" I think I am the only one who has worked on this part of the code, so I must have done it but don't know why. This is a low priority bug since we are not using the low level agg renderer for much (it was written to try and decrease reliance and ultimately drop the CXX) but the endeavor has languished. I'll need to spend some time to figure out why this is commented out and if it can be restored. > > python embedding_in_wx2.py > [The y-axis labels are being cut off at the bottom of the figure.] This is a pretty low priority since I am already somewhat inclined to drop pure wx rendering. > > python image_slices_viewer.py > [It says the "use the scroll wheen to navigate images" [sic], but the > scroll wheel doesn't appear to do anything in TkAgg on Linux.] This works in gtkagg -- some tk users/developer/advocate needs to add support for the 'scroll_event'. I consider this to be fairly high priority and an easy fix. > > python keypress_demo.py > [Pressing "g" to toggle the grid causes the grid to flash momentarily > and then disappear again.] Fixed - this was written a long time ago before toggling the grid with 'g' was made the default. So this example simply toggled it on and off since two event handlers were being triggered. I rewrote it to to toggle the xlabel > > python bar_unit_demo.py > Traceback (most recent call last): >File "bar_unit_demo.py", line 14, in > p1 = ax.bar(ind, menMeans, width, color='r', bottom=0*cm, yerr=menStd) >File > "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line > 3307, in bar > fmt=None, ecolor=ecolor, capsize=capsize) >File > "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line > 3727, in errorbar > lower = y-yerr > TypeError: unsupported operand type(s) for -: 'int' and 'TaggedValue' fixed in svn > > python ellipse_with_units.py > Traceback (most recent call last): >File "ellipse_with_units.py", line 36, in > ax.add_patch(e1) >File > "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line > 1143, in add_patch > self._update_patch_limits(p) >File > "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line > 1150, in _update_patch_limits > p.get_transform(), p.get_verts()) >File > "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/patches.py", > line 814, in get_verts > x = width/2. * npy.cos(theta) > TypeError: unsupported operand type(s) for /: 'TaggedValue' and 'float' fixed in svn JDH - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Transforms branch
As some of you probably know, I've been working on a fairly major refactoring of matplotlib. It's now getting to the point where I think more people may want to check it out and kick the tires. It is definitely not ready for real work -- I guarantee the first thing you try will break ;) However, it is passing the vast majority of examples in examples/ (with some major exceptions). The only working backends are Agg and all Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been attempted, and I'm certain is broken. There's a very good chance that external tools like basemap will not work at all. If you care about any of these missing things, you may not want to try the branch yet, or better yet, you may want to check out the branch and get those things working ;) Or, please let me know if the changes make any of those things much harder to do, so the design can be refined while we still have the chance ;) There are more details about the changes in CHANGELOG and API_CHANGES. PASSED_DEMOS contains my own notes about what is currently working. The SVN URL is: https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transforms Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Missing or broken examples
John Hunter wrote: > After that, are you getting close Michael to merging your branch into > the trunk? I think our lines crossed -- I just sent an e-mail about this. This is probably implied, but I think it would be a good idea to keep a maintenance branch around based on the upcoming release -- it may be helpful to be able to make quick and easy bugfixes against the release without worrying about all the new bugs my branch has introduced ;) I've been merging trunk into my branch almost daily since I started, so the merge back into the trunk should be reasonably painless. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote: > As some of you probably know, I've been working on a fairly major > refactoring of matplotlib. It's now getting to the point where I think > more people may want to check it out and kick the tires. It is > definitely not ready for real work -- I guarantee the first thing you > try will break ;) > > However, it is passing the vast majority of examples in examples/ (with > some major exceptions). The only working backends are Agg and all > Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been > attempted, and I'm certain is broken. There's a very good chance that > external tools like basemap will not work at all. If you care about any > of these missing things, you may not want to try the branch yet, or > better yet, you may want to check out the branch and get those things > working ;) Or, please let me know if the changes make any of those > things much harder to do, so the design can be refined while we still > have the chance ;) > > There are more details about the changes in CHANGELOG and API_CHANGES. > PASSED_DEMOS contains my own notes about what is currently working. > > The SVN URL is: > > > https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transfor >ms I'm looking forward to trying it out. Maybe we can consider switching to the traited config package after the potential merge. I have been running with it for quite a long time, and haven't had any issues. Now that traits can be installed without any additional dependencies, and enthought has been working on playing well with debs and rpms, we could consider making traits an external dependency. I think it should be external, because that will make it easier to generate default config files at compile time. We could also benefit from a reorganization of the src directory tree, one that would not touch the actual api. I think I will have some free evenings and weekends for these projects starting Dec 4. Darren - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms branch
Darren Dale wrote: > > Maybe we can consider switching to the traited config package after the > potential merge. I have been running with it for quite a long time, and > haven't had any issues. Now that traits can be installed without any > additional dependencies, and enthought has been working on playing well with > debs and rpms, we could consider making traits an external dependency. I > think it should be external, because that will make it easier to generate > default config files at compile time. We could also benefit from a > reorganization of the src directory tree, one that would not touch the actual > api. I think I will have some free evenings and weekends for these projects > starting Dec 4. Darren, When I go to the enthought web site, the most recent traits release I see is 1.1, from August 2006. That doesn't make me optimistic about traits as an external dependency any time soon. Eric - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
