[matplotlib-devel] Unit Converter Interface Issue
All, I have a suggestion for the units.ConversionInterface class. It seems to me that for each method of the ConversionInterface there should be another parameter passed in, the Axis instance that is requesting the conversion/info. Doing so would allow for any custom conversion code to make checks on the Axis, whether it is X/Y, or even make checks on the Axes the Axis is attached to. Additionally this would allow for converters to apply any necessary changes before they are really used (such as DateConverter making sure that the axis bounds are >= 1). Comments/Suggestions? If it is okay, I would like to apply the necessary changes. --James Evans -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Updated units.ConversionInterface
All, I have just submitted an updated units.ConversionInterface. For each of the static methods it now takes the invoking Axis instance as a parameter. I have updated the appropriate calling functions. This allows the DateConverter to now guarantee that the default axes no longer attempts to convert a value of zero to a date (ie. The 'ordinal <= 0' datetime conversion error is now a lot more difficult to invoke). Additionally I have modified the DateConverter class to make use of any specified units, such that the timezone is used for the units value. --James Evans PS: I expect to be submitting a fully functioning test harness by the end of this week. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updated units.ConversionInterface
Eric, I was looking at it from the perspective of most of the other API calls throughout matplotlib have the Axes or Axis as the first argument. Typically this is because it is what wants the work to be done or is being worked on. I was just following suit. I can see where you are coming from. I have no real strong argument for or against, so if I should swap them around as you had suggested, then I have no problem changing it. --James > -Original Message- > From: Eric Firing [mailto:[email protected]] > Sent: Wednesday, January 28, 2009 10:48 AM > To: James Evans > Cc: 'matplotlib development list' > Subject: Re: [matplotlib-devel] Updated units.ConversionInterface > > James Evans wrote: > > All, > > > > I have just submitted an updated units.ConversionInterface. For each of > > the static methods it now > takes the invoking Axis instance > > as a parameter. I have updated the appropriate calling functions. This > > allows the DateConverter to > now guarantee that the default > > axes no longer attempts to convert a value of zero to a date (ie. The > > 'ordinal <= 0' datetime > conversion error is now a lot more > > difficult to invoke). Additionally I have modified the DateConverter class > > to make use of any > specified units, such that the > > timezone is used for the units value. > > > > James, > > I have not thought all this through, but a quick look at your changeset > raises the question: > > Why are you making such a complete change in the API? In every > instance, you are changing the method signature so that the new arg, > "axis", is the first. This seems particularly odd for the "convert" > method--the new signature, convert(axis, value, unit), gives the > arguments in what seems to be an unintuitive order. Why not have > something like convert(value, unit, axis=None), so that convert can be > called without specifying an axis, and so that the argument order is > still natural: "convert the value with unit, taking advantage of the > axis if specified"? > > Is there some compelling logic to having the "axis" argument now at the > head of the list? > > Eric > > > --James Evans > > > > PS: I expect to be submitting a fully functioning test harness by the end > > of this week. > > > > > > -- > > 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 > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Updated units.ConversionInterface
Okay. Done. --James > -Original Message- > From: John Hunter [mailto:[email protected]] > Sent: Wednesday, January 28, 2009 11:46 AM > To: James Evans > Cc: Eric Firing; matplotlib development list > Subject: Re: [matplotlib-devel] Updated units.ConversionInterface > > On Wed, Jan 28, 2009 at 1:19 PM, James Evans wrote: > > Eric, > > > > I was looking at it from the perspective of most of the other API calls > > throughout matplotlib have > the Axes or Axis as the first > > argument. Typically this is because it is what wants the work to be done > > or is being worked on. I > was just following suit. I can > > see where you are coming from. I have no real strong argument for or > > against, so if I should swap > them around as you had suggested, > > then I have no problem changing it. > > I tend to agree with Eric -- then people writing converters who don't > care about the axis input can ignore it more easily. > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] FW: Polar Plot Design Issues
Ok. Thanks for the information. That does do exactly what I would expect. I would place my vote for having this be the default behavior since this is what it means to say "go from point A to B" on a polar plot. --James > -Original Message- > From: Michael Droettboom [mailto:[email protected]] > Sent: Monday, February 02, 2009 8:28 AM > To: James Evans; matplotlib development list > Subject: Re: FW: Polar Plot Design Issues > > You can get this behavior you are asking for by passing "resolution=1" > to polar. (This has been there for ages, but unfortunately wasn't > documented until recently). We can consider making 1 the default. > > There are cases in which the automatic interpolation is useful, but in > the present implementation the onus is on the user to avoid this "going > the long way" problem. > > Mike > > James Evans wrote: > > Michael, > > > > John said you were the one to go to for this one. I was wondering if you > > had any comments about the > following? > > > > --James Evans > > > > > >> All, > >> > >> While looking over the polar plot code I came across the following issue: > >> When plotting something > >> like 'polar( [2*pi/180, 358*pi/180], [2.0, 1.0] )' the plotted line will > >> actually wrap around the > >> origin of the plot before reaching its destination. Initially I thought > >> that this was correct > >> behavior. The line numerically passed through all angles between 2 and > >> 358 degrees in a linear > >> fashion. However after consulting several colleagues and text books I > >> believe that the behavior is > >> actually wrong. > >> > >> It is my understanding that for polar plots there is no linear mapping of > >> the axes as it is > currently > >> implemented. Rather for a simple two-point line defined in polar > >> coordinates, the line should > >> essentially take the direct route. This is highlighted by the two-point > >> equation of a line for > polar > >> plots: > >> > >> r = ( r1*r2*sin(t2-t1) ) / ( (r1*sin(t-t1)) - (r2*sin(t-t2)) ) > >> > >> If you were to plug in the two points given above, then increment theta > >> (t) from 2 degrees to 358 > >> degrees, then convert to Cartesian cords, and plot the results, you will > >> get the correct line that > >> directly crosses the zero degree line and not one that wraps around the > >> origin. > >> > >> Is the polar plot function implemented this way on purpose? Which way > >> should it really be > >> implemented? > >> > > > > > > -- > 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: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A Couple of additions
All, I have just submitted the following two additions to the code: 1) Added ability to have X and Y Axis autoscale independently. This is handled by the addition of the following methods to Axes: -- Axes.get_autoscalex_on() / Axes.set_autoscalex_on( bool ) -- Axes.get_autoscaley_on() / Axes.set_autoscaley_on( bool ) The original method of Axes.set_autoscale_on( bool ) will set the auto scale for the x and y axes to be the same (thus keeping its functionality exactly the same). The method Axes.get_autoscale_on() currently acts exactly as the original in that it returns True is the x and y axes are both auto scaling (since the original behavior was that both axes had the same flag). This can be changed however so that it returns True if either axis has auto scaling enabled. 2) Fixed a bug where any user specified formatter, locator, of axis labels would get overwritten if anything tickled the unit handling code after they were set. In order to facilitate this I added the following methods to Axis: -- Axis.get_label_text() / Axis.get_label_text( str ) Essentially user-specified explicit values will take precedence over any "default" or "smart" generated values. --James Evans -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Unit-Test Structure Submitted
All, I have just submitted a first-cut at a unit-test harness. The unit-tests do require the use of the 'nose' python module. Everything has been placed in the 'test' directory off of the root trunk branch. There is a README file with lots of information on how to use it. This is in addition to a few test cases already bundled in (they make great examples)! The idea is that whenever somebody adds a new feature or makes a change they update/add the appropriate test case and re-run the harness to make sure nothing is broken. There is most definitely room for improvement with this, but it gives a starting point from which discussions and modifications can take place. Any questions or comments? --James Evans -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] broken examples/units/*
Done. > -Original Message- > From: Eric Firing [mailto:[email protected]] > Sent: Saturday, February 21, 2009 12:18 PM > To: James Evans > Cc: matplotlib development list > Subject: broken examples/units/* > > James, > > The scripts in examples/units (and run by backend_driver.py) are broken; > they have not been updated to match your addition of the new mandatory > axis argument to convert() and default_units(). Would you fix them, > please? (While you are in the neighborhood, you might also update the > methods by switching to the @staticmethod decorator.) > > The argument was also missing from the units.py docstring, but I have > fixed that. > > Thank you. > > Eric -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Tests and matplotlibrc
When I wrote the test stuff I had forgotten all about the matplotlibrc stuff. I think it would make sense to just use a default (empty) matplotlibrc for the tests, this way we are always testing against the defaults. If the defaults ever change it would also allow us to more easily catch those changes to note if there is any negative consequences of the change. Do the defaults ever differ based upon platform? Backend? Phase of the moon? --James Evans > Date: Wed, 20 May 2009 10:32:12 -0500 > From: John Hunter > Subject: Re: [matplotlib-devel] Tests and matplotlibrc > To: Ryan May > Cc: Ted Drain , "Evans, James R" > , Matplotlib Devel > > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, May 20, 2009 at 10:27 AM, Ryan May wrote: > > > Thanks, I wasn't aware of that. It seems that if I just put an empty > > matplotlibrc file in that directory, it serves the same purpose. Can I just > > check that in (perhaps containing only a clarifying comment) so that it > > stays in sync with the current matplotlib defaults? > > Not sure what is the best way here -- one is to put in an rc w/ > everything uncommented for the tests, so that even if the mpl defaults > change the regression suite won't break. The other is to assume the > defaults in the test suite (empty rc) and if someone changes an rc > default it breaks the test suite. Perhaps James or Ted have a > view/preference? > > JDH -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Units issue
There seems to be some confusion as to how the mpl unit system works, I hope the following will help to clarify that and keep this thread focused on the issue. Currently mpl provides an API via the 'ConversionInterface' class in 'matplotlb.units' that allows a user to define how to translate their data into something meaningful for mpl to process (i.e. floats). If you are already passing around floats, then this interface is not for you. This interface is for typed data that is to be plotted (i.e. it needs to be "manipulated" to convert it to a float). This manipulation is handled via the user-defined and registered ConversionInterface sub-class. The idea is not that a user will do the following: >>> ax.plot( cms ) >>> ax.plot( inches ) As that would imply that the user has already converted their data to floats. But that the user will this intead: >>> ax.plot( length_data1 ) >>> ax.plot( length_data2 ) Where the length_dataX is some user-defined data type and a user-defined conversion class has been pre-registered. mpl will choose the default units based upon what the user-defined conversion class says the default should be. But if a more explicit specification is required, then the user does the following instead: >>> ax.plot( length_data1, xunits="cm" ) >>> ax.plot( length_data2 ) This would plot the length data in centimeters. If desired then the user can do the following: >>> ax.xaxis.set_units( "cm" ) And the plot would be updated. The following also currently works: >>> ax.plot( length_data1, xunits="cm" ) >>> ax.plot( length_data2, xunits="inches" ) And the final plot would be in inches. The current mpl interface for units is quite robust and supports a very generic interface that is highly user-customizable (should the user want to do so). The interface is so robust that I defined a simple converter class that will "convert" strings to floats. I use this with bar plots and do something like the following: >>> ax.bar( ["a", "b', "c"], [1, 2, 3] ) An example can be seen in the matplotlib 'test/mplTest/units/StrConverter.py' file. Additionally other unit example classes can be found in the 'test/mplTest/units' directory. The issue is, as John has already stated with the individual plot functions. 'ax.plot' works perfectly fine due to the way the line data is cached and updated as needed (the updates take into account if units might have changed). Some individual plot functions strip out the units then manipulate the data, and others keep the unitized data and pass it along to be stripped out later. The issue is getting a consistent mechanism for dealing with where the conversion is to occur. I think that John's proposal of having higher level classes that handle this (as well as the caching) might be the way to go. It would allow the individual plot functions to stay simplistic and true to what they provide and let the data handle itself. This type of mechanism promises to be faster since the data only needs to be converted once (in the typical use case). Overhead of re-converting would only occur when the user explicitly changes the units for a specified axis. Additionally this approach looks to be more appealing when it comes to making plottable data items that are selectable and ultimately manipulatable via a gui interface. --James Evans -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://www.creativitycat.com ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Question Regarding units.py
I have a question regarding a change made to units.py Revision# 6165 added a block of code that essentially filters out all numpy arrays that are not 'dtype == object'. Why exactly are object arrays only allowed? Shouldn't this allow arrays of any type, so long as a converter was registered? Thanks, --James Evans -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Artist default alpha value
All, I have a question regarding the default alpha value for an Artist. Why is it 1.0 instead of None? The color conversion code takes into account if alpha is None and having it default to something other than None makes it impossible for any Patch to have a fill_color specified as an RGBA value (and possibly other Artist sub-classes). Should this be something else, or should the Patch.set_facecolor method pre-process the incoming color value and set any specified alpha as appropriate (I hope not since this would cause the color value to be processed several times)? Thanks, --James Evans -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Z-Order Sorting
All, I have been looking at some of the recent z-order changes and have found an issue that breaks previous behavior. Previously when items were added to a Figure or an Axes with the same z-order value, they were rendered in order of when they were added, so that the first one added is 'underneath' the others and the last one added is rendered 'over' all the other items of the same z-order value. This no longer is the case. The following snippet of code demonstrates the problem: #=== class ZSortClass( object ): def __init__( self, name, zorder = 0 ): self.name = name self.zorder = zorder def doit( self ): print "z-order [%s] = %s" % (self.name, self.zorder) # Instantiate out of order to prove a point a = ZSortClass( 'a', 0 ) c = ZSortClass( 'c', 0 ) b = ZSortClass( 'b', 0 ) all = [ a, b, c ] dsu = [ (x.zorder, x.doit, x.name) for x in all ] print dsu dsu.sort() print dsu #=== All three instances have the same 'zorder' value, which causes the sort command to resort to sorting on the memory address. This can change from run to run. In simple cases the memory addresses typically increase in order of instantiation, but in larger blocks of code, python can perform garbage collection at any time and this would no longer hold true, and cause the effect to appear random (This is also affecting the rendering of filled continents in basemap). I couldn't think of an easy solution without making some intrusive changes to what is already in place, so I thought that I'd post my findings for further discussion. --James Evans -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] FontProperties being ignored...
All, I just submitted bug #2963827 detailing this, but thought that I would echo the problem here. When plotting annotations and specifying the FontProperties to use, the specified values are completely ignored. See the attached script and image for an example. Am I doing something inherently wrong, or is this really a bug? Thanks, --James Evans textFormat.png Description: Binary data #!/usr/bin/env python import pylab from matplotlib.font_manager import FontProperties fig = pylab.figure() ax = pylab.subplot( 1, 1, 1 ) normalFont = FontProperties( family = "Sans Serif", style = "normal", variant = "normal", weight = 500, stretch = 500, size = 14, ) ax.annotate( "Normal Font", (0.1, 0.1), xycoords='axes fraction', fontproperties = normalFont ) boldFont = FontProperties( family = "Sans Serif", style = "normal", variant = "normal", weight = 750, stretch = 500, size = 14, ) ax.annotate( "Bold Font", (0.1, 0.2), xycoords='axes fraction', fontproperties = boldFont ) boldItemFont = FontProperties( family = "Sans Serif", style = "italic", variant = "normal", weight = 750, stretch = 500, size = 14, ) ax.annotate( "Bold Italic Font", (0.1, 0.3), xycoords='axes fraction', fontproperties = boldItemFont ) lightFont = FontProperties( family = "Sans Serif", style = "normal", variant = "normal", weight = 200, stretch = 500, size = 14, ) ax.annotate( "Light Font", (0.1, 0.4), xycoords='axes fraction', fontproperties = lightFont ) condensedFont = FontProperties( family = "Sans Serif", style = "normal", variant = "normal", weight = 500, stretch = 100, size = 14, ) ax.annotate( "Condensed Font", (0.1, 0.5), xycoords='axes fraction', fontproperties = condensedFont ) pylab.show() -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release schedule for version 1.0.1?
In reference to the configuration package idea... I (and the users that I support) use matplotlib both as a standalone plotter for generating lots of plots, as an interactive plotter, and as an embedded plot in an application environment. In all of these instances we have found the '.matplotlibrc' mechanism to be severely lacking in control of plot formats. Users will be generating series of plots that are going to be embedded into documents and therefore want a uniform look and feel to those plots. Later they want to generate some plots for use on an overhead projector (which has a much different DPI). Another time they are interactively plotting on their workstation and still again doing all this in an embedded form as well. The solution we have come up with, although a little bit of a hack, is a configuration/formatter class, where instances are used to manage the formatting of the plots. Each instance can represent a specific set of configurations controlling everything from font properties to background color. The difference here is that having global defaults is all fine and dandy, but sometimes just setting a global default is not enough and controlling the setting as an encapsulated entity that can be passed around and selected at will can be quite useful. Just my $0.02 --James Evans > On 10/28/10 12:46 PM, Russell E. Owen wrote: > > > It's an interesting question. You can't call a matplotlib function to > do > > it because it has to happen before matplotlib is loaded. I suppose > there > > could be a configuration package to perform the operation. > > I actually like that idea. It could even do a bit more, like have the > matplotlib.use() function, and who knows how many others. > > I've never liked the .matplotlibrc approach -- it makes great sense for > an interactive environment, but not so much for embedding MPL in other > apps, for all the reason's Russell has laid out. > > If there was a mplconfig module that you could import first, and have > functions in there where you could set all the defaults the way tyou > like them, it would be easier to make self-contained MPL apps that > didn't step on each-others toes. -- Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Bug: plot numpy.nans vs. datetime objects
All, This is due to the fact that you have nothing to plot and the axes range defaults to 0->1. Unfortunately 0 cannot map to a valid datetime. I thought that I had fixed this so that using datetimes would cause the axes to initialize to a valid datetime value. Once I get up to speed with the whole 'git' thing and figure out how to make submissions again, etc. A quick work-around is to manually set the bounds for our datetime axis and turn off autoscaling until you have some data to display. I can probably take another look at it, but I am pretty busy and learning the git model of doing things is only slowing things down. :( --James > -Original Message- > From: Benjamin Root [mailto:[email protected]] > Sent: Friday, March 25, 2011 6:34 AM > To: Gerrit Kuhlmann > Cc: [email protected] > Subject: Re: [matplotlib-devel] Bug: plot numpy.nans vs. datetime objects > > On Friday, March 25, 2011, Gerrit Kuhlmann > wrote: > > On Fri, 2011-03-25 at 01:08 -0700, Paul Ivanov wrote: > >> Gerrit Kuhlmann, on 2011-03-25 14:26, wrote: > >> > Hi all, > >> > > >> > I get a ValueError, if I try to plot a list of numpy.nans against > >> > datetime objects. I'm using Python 2.6.5 and Matplotlib 1.0.1 on > >> > Ubuntu Linux 10.04. Code and traceback are below. > >> > > >> > Best regards, > >> > Gerrit > >> > > >> > > >> > > >> > Code > >> > > >> > import matplotlib.pyplot as plt > >> > import numpy as np > >> > from datetime import datetime as DateTime > >> > > >> > t = [DateTime(2011,1,day) for day in xrange(1,20)] x = [np.nan for > >> > i in xrange(1,20)] > >> > > >> > plt.plot(t,x) > >> > plt.show() > >> > >> Hi Gerrit, > >> > >> Thanks for the report, though I'm not sure what you expect to happen > >> here? > >> > >> Changing at least one of the elements of x to be something other than > >> nan does not cause the error. > >> > >> There is an inconsistency, though, in that plt.plot(x,x) when x is > >> full of nans does not cause any errors. > >> > >> best, > > > > Hi Paul, > > > > thanks for your answer. I would expect similar behaviour as for > > "plot([0,1,2], [nan,nan,nan])", which creates an empty plot. A passed > > through exceptions from the datetime module seems a bit odd. > > > > Regards, > > Gerrit > > > > Agreed, I just came across this yesterday while working on my general exam > project. I have no clue why the behavior would be different because we are > using datetime objects. > > Ben Root > > > > > > -- > > Enable your software for Intel(R) Active Management > > Technology to meet the growing manageability and security demands of > > your customers. Businesses are taking advantage of Intel(R) vPro (TM) > > technology - will your software be a part of the solution? Download > > the Intel(R) Manageability Checker today! > > http://p.sf.net/sfu/intel-dev2devmar > > ___ > > Matplotlib-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > Enable your software for Intel(R) Active Management Technology to meet > the growing manageability and security demands of your customers. > Businesses are taking advantage of Intel(R) vPro (TM) technology - will your > software be a part of the solution? Download the Intel(R) Manageability > Checker today! http://p.sf.net/sfu/intel-dev2devmar > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] git repository access
Hello All, I am finally getting around to checking out a local copy of the git repository following the directions here: http://matplotlib.github.com/devel/gitwash/set_up_fork.html and I keep getting the following error: ~/source % git clone [email protected]:jrevans/matplotlib.git matplotlib-git Cloning into matplotlib-git... Permission denied (publickey). fatal: The remote end hung up unexpectedly I also tried replacing 'git@' with my github username 'jrevans@' Is this a github permission error? This is my first time using git, so I am still learning. Any help would be appreciated. Thanks, --James Evans -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] git repository access
Doh! That was exactly it. I followed every single step, but that one must have been invisible when I read it. Yes, thats it, it was invisible! :) Thanks for the quick response, --James > -Original Message- > From: Matthew Brett [mailto:[email protected]] > Sent: Wednesday, March 30, 2011 12:10 PM > To: James Evans > Cc: [email protected] > Subject: Re: [matplotlib-devel] git repository access > > Hi, > > On Wed, Mar 30, 2011 at 12:06 PM, James Evans > wrote: > > Hello All, > > > > > > > > I am finally getting around to checking out a local copy of the git > > repository following the directions here: > > > > http://matplotlib.github.com/devel/gitwash/set_up_fork.html > > > > > > > > and I keep getting the following error: > > > > > > > > ~/source % git clone [email protected]:jrevans/matplotlib.git > > matplotlib-git > > > > Cloning into matplotlib-git... > > > > Permission denied (publickey). > > > > fatal: The remote end hung up unexpectedly > > > > > > > > I also tried replacing git@ with my github username jrevans@ > > > > > > > > Is this a github permission error? This is my first time using git, > > so I am still learning. > > Did you follow the instructions at > http://matplotlib.github.com/devel/gitwash/forking_hell.html#set-up-and- > configure-a-github-account > ? Particularly the ssh key stuff? > > http://help.github.com/linux-set-up-git/ > > Best, > > Matthew > > -- > Create and publish websites with WebMatrix Use the most popular FREE > web apps or write code yourself; WebMatrix provides all the features you > need to develop and publish your website. http://p.sf.net/sfu/ms- > webmatrix-sf > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] What is rcParams['units'] for?
Honestly, I do not know what the units rc param is for. Personally I try to stay away from anything rc parameter related. I would guess that it was put in to handle default units, but the unit system handles defaults based on the type of data being plotted. Perhaps it was added in the first draft of the unit code and never removed when it was revised? As far as I know, there is no need for it. --James > -Original Message- > From: Darren Dale [mailto:[email protected]] > Sent: Tuesday, April 19, 2011 4:42 AM > To: Eric Firing; [email protected] > Cc: matplotlib development list > Subject: Re: [matplotlib-devel] What is rcParams['units'] for? > > On Tue, Apr 19, 2011 at 3:07 AM, Eric Firing wrote: > > While investigating the imshow problem reported today by Emanuale > > Passera (a problem that seems to have been fixed, though I don't know > > when or how), I stumbled across the verbose-helpful report of the > > "units" rcParams entry. Sure enough, it is in rcsetup.py and in > > matplotlibrc.template, but a quick code scan turned up no evidence > > that it is used anywhere. Is it vestigial, and a candidate for surgical > removal? > > James, do you know what the units rc parameter was for, and can it be > removed? > > Darren > > -- > Benefiting from Server Virtualization: Beyond Initial Workload Consolidation - > - Increasing the use of server virtualization is a top > priority.Virtualization can > reduce costs, simplify management, and improve application availability and > disaster protection. Learn more about boosting the value of server > virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Qt backend submit
All, I just submitted an update to backend_qt.py and backend_qt4.py. Both updates remove the 'mainloop' flag from the 'show' function as it is now handled automatically. Essentially the qt event-loop will only be started by matplotlib if matplotlib was the one to create the qApp, if not then it is up to the creator of the Qt qApp to start the event-loop when they are ready for it. This allows for applications with embedded Qt event loops to work with matplotlib. I have run some test cases in a few different python environments (including the vanilla python) and all seem to be working. I have not, however tested this in the iPython environment (although I don't think that iPython uses Qt, does it?). Any feedback would be appreciated. --James Evans - 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Axis Length
Is there any way to get the length (in pixels) of a particular axis? More specifically I am trying to make a clean-looking Formatter object that spaces out the labels so that the text does not write on top of each other, but in order to do so, I need to know the length of the Axis that the Formatter object is being applied to. Is there any easy (or proper) way to do this? While I am on the topic, are there any ways to get the pixel size of a string if it were to be rendered as text? I know that Qt can do this, but I wasn't sure if the matplotlib backend system has this implemented to make it generic for all backends. Right now I just have a hard-coded parameter for this, but it would be nice to make more automatic. Thanks, --James Evans - 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] R3237 breaks mri_with_eeg.py demo
Fixed. Try again. > -Original Message- > From: Eric Firing [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 18, 2007 12:22 AM > To: James Evans > Cc: matplotlib development list > Subject: R3237 breaks mri_with_eeg.py demo > > Revision 3237 to fix set_ticklabels seems to have a problem: it breaks > examples/mri_with_eeg.py. > > Eric - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bar plot forget units information
When using the 'bar' plot command, unit information is lost when changing the
units for a given axis. The attached script
demonstrates this.
This is not the case for line plots because of the use of Line2D's 'recache'
method.
--James Evans
"""
plot using a variety of cm vs inches conversions. The example shows
how default unit instrospection works (ax1), how various keywords can
be used to set the x and y units to override the defaults (ax2, ax3,
ax4) and how one can set the xlimits using scalars (ax3, current units
assumed) or units (conversions applied to get the numbers to current
units)
"""
from basic_units import cm, inch
from pylab import figure, show, nx
cms = cm *nx.arange(0, 10, 2)
fig = figure()
ax1 = fig.add_subplot(2,2,1)
ax1.bar(cms, cms)
ax2 = fig.add_subplot(2,2,2)
ax2.bar(cms, cms, xunits=cm, yunits=inch)
ax3 = fig.add_subplot(2,2,3)
ax3.bar(cms, cms, xunits=inch, yunits=cm)
ax3.set_xlim(3, 6) # scalars are interpreted in current units
ax4 = fig.add_subplot(2,2,4)
ax4.bar(cms, cms, xunits=inch, yunits=inch)
#fig.savefig('simple_conversion_plot.png')
ax4.set_xlim(3*cm, 6*cm) # cm are converted to inches
show()
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Several Axes issues
The attached script demonstrates several bugs that are all related to the Axes
class. Areas affected are:
* Autoscaling
* Ellipse
* Inverting Axis objects
* Fixed aspect ratio
1) Auto scaling is not enacted when adding a Patch to an axes (more of a
feature)
2) When manually calling axes.autoscale_view(), the boundaries of an Ellipse
are incorrectly computed as they do not take into
account the rotation of the ellipse.
3) Inverting the axes using the current method of reversing the axes limits
does not always take effect right away. An explicit
call to axes.apply_aspect() fixes this.
4) When the axes are inverted and an Ellipse is rendered, then it becomes
asymptotic and not an ellipse.
5) When the axes are inverted and axes.set_aspect('equal', 'datalim') has been
called, then resizing the plot window will result in
the axes reverting back to their original state.
When it comes to handling inverted axes I have a proposition on how to better
handle this. It seems like every other month a user
asks the question how to do this and perhaps there should be a direct interface
to do so. Something like the following...
axes.invert_xaxis()
axes.invert_yaxis()
Each method would set a flag on the corresponding Axis object and all calls to
'axes.set_xlim' & 'axes.set_ylim' would check the
appropriate flag and automatically set the values in the correct order.
Additionally all calls to 'axes.get_xlim' and
'axes.get_ylim' would return the values in min, max order. I believe that an
interface like this would greatly simplify things for
both the user and the maintainer of the internal code (no need to put in checks
to see if the axes have been inverted). A simple
'axes.xaxis_inverted' or 'axes.yaxis_inverted' call would be sufficient to
determine if the axes have been inverted (for those users
who would need to check).
from pylab import *
from matplotlib.patches import Ellipse
delta = 45.0 # degrees
angles = arange(0, 360+delta, delta)
ells = [Ellipse((1, 1), 4, 2, a) for a in angles]
a = subplot(111, aspect='equal')
#BUG 1792567: Setting the autoscale to on does nothing when plotting a patch
a.set_autoscale_on(True)
# set the aspect ratio
a.set_aspect("equal", "datalim")
for e in ells:
e.set_alpha(0.1)
a.add_patch(e)
# Since autoscale does not work for patches we call manually
a.autoscale_view()
# put this here to force the axes to flush whatever caching it is is doing
# so that we can actually invert the axes
a.apply_aspect()
#BUG 1792575: Once the autoscale happens, it doesn't take into account
# the rotation value of an ellipse for calculating the view limits.
#BUG 1792599: Inverting the y-axis does nothing regardless of calling it before
# or after 'a.autoscale_view()
ymin, ymax = a.get_ylim()
a.set_ylim(ymax, ymin)
#BUG 1792603: Inverting the y-axis causes the rendered ellipse to be asymptotic.
show()
#BUG 1792615: Resizing the figure window with winverted axes looses the
inversion.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] annotate fails with unitized data
When passing unitized data into the annotate function it will fail because it attempts to use the data as a float. See the attached script for an example. --James Evans import pylab from basic_units import cm fig = pylab.figure() ax = fig.add_subplot(111) #BUG: This will fail. ax.annotate( "Note 01", [0.5*cm, 0.5*cm] ) pylab.show() - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] API additions
All, Based on what everyone has been saying I have submitted an update to axes.py that reverts the get/set xlim/ylim methods to their original state with their original interface. I have removed the state flag that keeps track of inverted axes. Currently I have added the method get/set xbound/ybound that handles getting and setting of the upper and lower bounds and will handle inverted axes. I have made a couple of changes within the Axes class to now call the xbound/ybound methods so that the handling of inversion is automatic. This at least solves the immediate problems and provides some level of protection by giving a "safe" method to call when writing methods that deal with axes limits. Let me know what you think. --James Evans > -Original Message- > From: Ted Drain [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 04, 2007 2:34 PM > To: Eric Firing > Cc: James Evans; John Hunter; matplotlib development list > Subject: Re: [matplotlib-devel] API additions > > Sounds fine - I don't think we care too much about the "how". I > talked w/ James and as far as we know, the aspect code is the only > area that's having a problem right now (James is going to submit a > patch to that to handle x1>x2 today). > > Since we do these plots all the time, we've just seen a number of > problems come up as new features get added and people forget that > x1 > x2 is a possibility. We were just trying to think of ways of > "future proofing" the new system by making it more obvious that this > case does show up. It might be able to be handled by some extra > comments in the existing code so that people who are looking for > examples would get a reminder that this case has to be handled. > > Ted > > At 02:11 PM 10/4/2007, Eric Firing wrote: > >Ted Drain wrote: > > > John, > > > I think keeping the existing API is probably a good idea. What about > > > something like this: > > > > > > - Keep xlim and viewlim as they are. > > > > > > - Add xbound() (or maybe a better name) that returns (x1,x2) where x1 < > > > x2. > > > > > > - Add set_xbound(x1,x2) that takes x1 > > then calls set_xlim() w/ the args in the proper order. > > > >The fundamental object containing the relevant information is the > >Interval instance. Instead of having a proliferation of flags and > >functions at the python level, I am thinking about adding a few very > >simple methods to the Interval object. Maybe > > > >swap() to reverse the order of the bounds > >increasing() to yield True if val2 >= val1 > > > >Your xbound and set_xbound functionality could also be done this way, as > >Interval methods. > > > > > >Mike, how would this fit in with your reworking of transforms? > > > >Eric > > > > > > > > - Change the existing axis code that messes w/ bounds (autoscale, aspect > > > ratio, etc) to use xbound. These algorithm can then be written so > > > they're independent of the order of x1 and x2 and they won't flip the > > > bounds back if the inversion flag is set. > > > > > > Ted > > > >- > >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 > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > Ted Drain Jet Propulsion Laboratory [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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Annotation 'data offset'
All, I have just submitted a patch to the Annotation class that allows specification of a 'data offset' frame for the text coordinate. This allows you to specify a data point to annotate and an offset that will stay the same regardless of scale. Please let me know if this should be given a different name (like 'offset' or 'point offset', etc). --James Evans - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Problem with Agg Ellipses
There appears to be an issue with the agg backend with how it is drawing ellipses (or maybe it is how matplotlib uses agg), but the attached script shows how a point, which should be coincident with the center circle, but it is not. The second plot shows the same data, but using a custom (and much slower) algorithm for drawing the ellipses, where the point is properly coincident. The problem appears to be with the way that agg discretizes its Bezier curves before drawing. It does not take into account the scale of the curve on in the viewable region of the rendering device. I think that ideally this would be fixed in the agg side since then there would be the smallest of performance hits but matplotlib could attempt to work around it by specifying more points on the ellipse curve. # This example can be boiled down to a more simplistic example # to show the problem, but bu including the upper and lower # bound ellipses, it demonstrates how significant this error # is to our plots. import math from pylab import * from matplotlib.patches import Ellipse # given a point x, y x = 2692.440 y = 6720.850 # get is the radius of a circle through this point r = math.sqrt( x*x+y*y ) # show some comparative circles delta = 6 ## def custom_ellipse( ax, x, y, major, minor, theta, numpoints = 750, **kwargs ): xs = [] ys = [] incr = 2.0*math.pi / numpoints incrTheta = 0.0 while incrTheta <= (2.0*math.pi): a = major * math.cos( incrTheta ) b = minor * math.sin( incrTheta ) l = math.sqrt( ( a**2 ) + ( b**2 ) ) phi = math.atan2( b, a ) incrTheta += incr xs.append( x + ( l * math.cos( theta + phi ) ) ) ys.append( y + ( l * math.sin( theta + phi ) ) ) # end while incrTheta = 2.0*math.pi a = major * math.cos( incrTheta ) b = minor * math.sin( incrTheta ) l = sqrt( ( a**2 ) + ( b**2 ) ) phi = math.atan2( b, a ) xs.append( x + ( l * math.cos( theta + phi ) ) ) ys.append( y + ( l * math.sin( theta + phi ) ) ) ellipseLine = ax.plot( xs, ys, **kwargs ) ## # make the axes ax = subplot( 211, aspect='equal' ) ax.set_aspect( 'equal', 'datalim' ) # make the lower-bound ellipse diam = (r - delta) * 2.0 lower_ellipse = Ellipse( (0.0, 0.0), diam, diam, 0.0, fill=False, edgecolor="darkgreen" ) ax.add_patch( lower_ellipse ) # make the target ellipse diam = r * 2.0 target_ellipse = Ellipse( (0.0, 0.0), diam, diam, 0.0, fill=False, edgecolor="darkred" ) ax.add_patch( target_ellipse ) # make the upper-bound ellipse diam = (r + delta) * 2.0 upper_ellipse = Ellipse( (0.0, 0.0), diam, diam, 0.0, fill=False, edgecolor="darkblue" ) ax.add_patch( upper_ellipse ) # make the target diam = delta * 2.0 target = Ellipse( (x, y), diam, diam, 0.0, fill=False, edgecolor="#DD1208" ) ax.add_patch( target ) # give it a big marker ax.plot( [x], [y], marker='x', linestyle='None', mfc='red', mec='red', markersize=10 ) ## # now lets do the same thing again using a custom ellipse function # make the axes ax = subplot( 212, aspect='equal', sharex=ax, sharey=ax ) ax.set_aspect( 'equal', 'datalim' ) # make the lower-bound ellipse custom_ellipse( ax, 0.0, 0.0, r-delta, r-delta, 0.0, color="darkgreen" ) # make the target ellipse custom_ellipse( ax, 0.0, 0.0, r, r, 0.0, color="darkred" ) # make the upper-bound ellipse custom_ellipse( ax, 0.0, 0.0, r+delta, r+delta, 0.0, color="darkblue" ) # make the target custom_ellipse( ax, x, y, delta, delta, 0.0, color="#BB1208" ) # give it a big marker ax.plot( [x], [y], marker='x', linestyle='None', mfc='red', mec='red', markersize=10 ) ## # lets zoom in to see the area of interest ax.set_xlim(2650, 2735) ax.set_ylim(6705, 6735) show() - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Agg Ellipses
I have taken the transforms branch and played with it a bit and my super simple ellipse test cases appeared to be working great. I couldn't run our more intensive tests since they use unitized data and I was getting errors that looked like the transforms branch wasn't completely handling unitized data properly. It would be great if we could see this fix in the main branch, then we can make use of it right away without having to wait for the transforms branch to be completed. --James Evans > Date: Tue, 11 Dec 2007 15:47:45 -0500 > From: Michael Droettboom <[EMAIL PROTECTED]> > Subject: Re: [matplotlib-devel] Problem with Agg Ellipses > To: Ted Drain <[EMAIL PROTECTED]> > Cc: matplotlib development list > > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > And an actually interesting part of the plot... ;) > > Michael Droettboom wrote: > > Sorry -- correct attachment this time. > > > > Michael Droettboom wrote: > >> I have a working draft of something that may work for this problem on > >> the transforms branch. I am happy to backport this to the trunk, but > >> that will require some effort, as the implementation relies on many of > >> the new geometric utilities on the branch that would also have to be > >> brought over. It may be some time until the branch is ready for > >> production use, but if you are able to use it to experiment with this > >> approach to this specific problem, that would certainly make my life > >> easier, so I don't have to do the backporting work more than once. > >> > >> Attached is a plot comparing the new approach (above) vs. a 750-edge > >> polygonal approximation for the ellipses (based directly on James > >> Evans' example). Here's a description of what it does: > >> > >> > >> Ellipses are normally drawn using an approximation that uses > >> eight cubic bezier splines. The error of this approximation > >> is 1.89818e-6, according to this unverified source: > >> > >> Lancaster, Don. Approximating a Circle or an Ellipse Using > >> Four Bezier Cubic Splines. > >> > >> http://www.tinaja.com/glib/ellipse4.pdf > >> > >> There is a use case where very large ellipses must be drawn > >> with very high accuracy, and it is too expensive to render the > >> entire ellipse with enough segments (either splines or line > >> segments). Therefore, in the case where either radius of the > >> ellipse is large enough that the error of the spline > >> approximation will be visible (greater than one pixel offset > >> from the ideal), a different technique is used. > >> > >> In that case, only the visible parts of the ellipse are drawn, > >> with each visible arc using a fixed number of spline segments > >> (8). The algorithm proceeds as follows: > >> > >> 1. The points where the ellipse intersects the axes bounding > >> box are located. (This is done be performing an inverse > >> transformation on the axes bbox such that it is relative to > >> the unit circle -- this makes the intersection calculation > >> much easier than doing rotated ellipse intersection > >> directly). > >> > >> This uses the "line intersecting a circle" algorithm from: > >> > >> Vince, John. Geometry for Computer Graphics: Formulae, > >> Examples & Proofs. London: Springer-Verlag, 2005. > >> > >> 2. The angles of each of the intersection points are > >> calculated. > >> > >> 3. Proceeding counterclockwise starting in the positive > >> x-direction, each of the visible arc-segments between the > >> pairs of vertices are drawn using the bezier arc > >> approximation technique implemented in Path.arc(). > >> > >> > >> Cheers, > >> Mike > >> > >> > >> Ted Drain wrote: > >>> All of these sound like good ideas to me. Just for some history: the > >>> original reason we worked w/ John to get an Ellipse primitive in (vs > >>> a normal line plot of sampled points) were to: > >>> - improve ellipse plotting speeds (we plot a LOT of them at once) > >>> - improve post script ou
[matplotlib-devel] Polar plot ignores units
All, The polar plot function ignores unitized data units in the v0.91-maint branch, I have yet to test it with the main branch. Currently the xaxis and yaxis manage the unit conversion, but since a PolarAxes does not have and x and y Axis object there is nothing to do the conversion and it gets skipped, one possibility is to have the PolarAxes manage a pair of converters for the 'theta' and 'r' axes. I plan to really test out the main branch later this month and will give feedback if this exists in the main branch. --James Evans - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] set_xlim (and set_ylim) reset labels and tickers
When using unitized data any call to 'set_xlim' or 'set_ylim' will reset any user specified labels or tickers for a given axis and replace it with the values specified via the unitized data 'axisinfo' See the following for an example: ### from basic_units import cm, inch from pylab import figure, show import numpy cms = cm *numpy.arange(0, 10, 2) fig = figure() ax1 = fig.add_subplot(2,2,1) ax1.plot(cms, cms) ax2 = fig.add_subplot(2,2,2) ax2.plot(cms, cms, xunits=cm, yunits=inch) ax3 = fig.add_subplot(2,2,3) ax3.plot(cms, cms, xunits=inch, yunits=cm) ax3.set_xlabel( "My Label" ) ax3.set_xlim(3, 6) # scalars are interpreted in current units # Since we call set_xlim with unitized data, the label will be reset. ax4 = fig.add_subplot(2,2,4) ax4.plot(cms, cms, xunits=inch, yunits=inch) ax4.set_xlabel( "My Label" ) ax4.set_xlim(3*cm, 6*cm) # cm are converted to inches show() ####### --James Evans - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] nxutils
All, I have not touched the code for several months, so it has taken me up until just now to realize that nxutils has been removed from the build. I there any real reason for this? Particularly when you consider that there are still functions present that use it and now they just fail. In particular I am referring to 'mlab.inside_poly'. In my case I was using 'nxutils.points_inside_poly' directly, but the end result is the same. Thanks, --James Evans -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] nxutils
I was just shocked to find the source code still present, just not compiled during the build step and at least one completely broken function call still referencing the un-built module and no apparent reason for removal. I have updated mlab.inside_poly to use Path instead and will submit it later today. --James From: Michael Droettboom [mailto:[email protected]] Sent: Friday, November 18, 2011 6:23 AM To: [email protected] Subject: Re: [matplotlib-devel] nxutils Perhaps another alternative is to just include a small compatibility module that would call the new functionality under the hood. Mike On 11/18/2011 09:07 AM, Michael Droettboom wrote: nxutils has been removed from master because it is completely redundant to the Path functionality that has been in matplotlib since 0.98. In the process of porting to Python 3, I felt it was important to reduce code duplication, because every additional line requires additional testing. That said, there seems to be a lot of push back on this. We can reinstate it, but I would suggest raising DeprecationWarnings for one release and then removing it entirely in the next. Mike On 11/18/2011 12:21 AM, Benjamin Root wrote: Huh? Nxutils removed? Then how am I still using points_inside_poly? And, if I remember right, Path uses that to calculate contains(). Ben Root On Thursday, November 17, 2011, Eric Firing wrote: > On 11/17/2011 10:19 AM, Michael Droettboom wrote: >> Most of what was in nxutils has been superseded by things in Numpy, and >> it makes more sense for it to be over there. >> >> In the case of points_inside_poly, you can use the Path object in >> path.py and the "contains_point" method. >> >> Mike > > Mike, > > This, however, brings us back to the plea by Volker Blum: > > http://www.mail-archive.com/[email protected]/msg22669. html > > There is a real tension between the need to clean things up and simplify > them, and users' desire for minimal loss of backwards compatibility. > Personally, my instincts are in the "clean it up" camp, but a good > balance has to be found. > > nxutils was definitely a vestige of an earlier era; but I don't think it > went through any official, publicized, deprecation process, did it? > Maybe it didn't need to; I don't know. Perhaps we need to formulate and > write down a deprecation policy. > > Eric > >> >> On 11/17/2011 12:03 PM, James Evans wrote: >>> >>> All, >>> >>> I have not touched the code for several months, so it has taken me up >>> until just now to realize that nxutils has been removed from the build. >>> >>> I there any real reason for this? Particularly when you consider that >>> there are still functions present that use it and now they just fail. >>> >>> In particular I am referring to 'mlab.inside_poly'. In my case I was >>> using 'nxutils.points_inside_poly' directly, but the end result is the >>> same. >>> >>> Thanks, >>> >>> --James Evans >>> >>> >>> >>> -- >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-novd2d >>> >>> >>> ___ >>> Matplotlib-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> -- >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> >> >> >> ___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity,
Re: [matplotlib-devel] adding second formatter/locater set to axes objects
For what it is worth, we attacked this problem about four years ago at my work. We just implemented a simple formatter. A locator can also be done in a similar manner if that is desired. This is not exactly is a perfect solution, but it worked really well for us. class ScaledFormatter( ticker.Formatter ): """: Takes an exisiting formatter and scales the value by a specified amount. """ def __init__( self, scale, formatter ): """Initialize the scaled formatter. = INPUT VARIABLES - scale The scale factor to apply to the values specified by the other formatter. - formatter Another matplotlib formatter to use for formatting the data labels. """ self.scale = scale self.formatter = formatter def __call__( self, x, pos = None ): 'Return the format for tick val x at position pos' # get the string form of the value valueStr = self.formatter( x, pos ) if len(valueStr) == 0: return '' # remove the unicode hyphen valueStr = valueStr.replace( u'\u2212', '-' ) # convert to a float value = float( valueStr ) # now scale the value value *= self.scale # convert ot a Unicode string s = unicode( value ) # add the unicode hyphen s.replace( '-', u'\u2212' ) return s def set_locs( self, locs ): 'Make sure the encompassed formatter get these set.' ticker.Formatter.set_locs( self, locs ) self.formatter.set_locs( locs ) def set_axis( self, axis ): 'Make sure the encompassed formatter get these set.' ticker.Formatter.set_axis( self, axis ) self.formatter.set_axis( axis ) def set_view_interval( self, vmin, vmax ): 'Make sure the encompassed formatter get these set.' ticker.Formatter.set_view_interval( self, vmin, vmax ) self.formatter.set_view_interval( vmin, vmax ) def set_data_interval( self, vmin, vmax ): 'Make sure the encompassed formatter get these set.' ticker.Formatter.set_data_interval( self, vmin, vmax ) self.formatter.set_data_interval( vmin, vmax ) def set_bounds( self, vmin, vmax ): 'Make sure the encompassed formatter get these set.' ticker.Formatter.set_bounds( self, vmin, vmax ) self.formatter.set_bounds( vmin, vmax ) --James > -Original Message- > From: Thomas Caswell [mailto:[email protected]] > Sent: Thursday, May 23, 2013 5:26 PM > To: [email protected] > Subject: [matplotlib-devel] adding second formatter/locater set to axes > objects > > A question I have seen go by twice on SO is how to add a tick marks to the > top/right of a plot which are re-scaled version of the values on the > bottom/lefit axis (ex km/h on the left and mph on the right). My > understanding of the best way to do this is to use twin* and then keep the > range of the two axes in sync by hand. > > I am proposing adding at set of alternate formatters/locators to the `axis` > objects which if they exist are used for the top/right labels. > Before I dive too deep into this, I want to check that a) there isn't a better > way to do this that I do not know and b) if this sounds like a reasonable > approach. > > Tom > > -- > Thomas Caswell > [email protected] > > -- > Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS- > based application performance monitoring service that delivers powerful full > stack analytics. Optimize and monitor your browser, app, & servers with just > a few lines of code. Try New Relic and get this awesome Nerd Life shirt! > http://p.sf.net/sfu/newrelic_d2d_may > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
