Re: [matplotlib-devel] The new logo (was: future of mpl documentation)
I agree that the new logo looks nice, but I also think that Rob is right: When you see the logo you wouldn't know that we are talking about a general purpose plotting package. So the question is: are we going for looks over meaning? I guess the other way around would be terrible: choosing meaning over looks you are stuck with an ugly logo that carries the right message. So to me, looks it is, Mark > On Jun 1, 2008, at 9:47 AM, Rob Hetland wrote: > > > > 2. I like the figure to the side (and agree that there should be > > only one), but it seems that polar plots are more rarely used than > > normal x-y plots. Perhaps an x-y plot (the histogram, for example) > > would be better advertising. > > I was the one who originally chose the polar plot. I admit, it was > mainly for aesthetics. Here are a few reasons: > > * I think a circular plot works better on the logo than a rectangular > plot would. > * The polar plot is one of the more attractive plots in the examples. > * It's a plotting featuring that most plotting software wouldn't have > so it seems to differentiate matplotlib from other plotting software. > > Originally, it wasn't a big deal because there were other plots in the > logo. Still, I'd be in favor of keeping the polar plot for aesthetic > reasons. > > Great, now I'm that guy who's arguing for looks over practicality. :( > > -Tony > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] pyplot vs pylab?
Hi folks,
I've added this little bit of code to the default ipython -pylab startup:
exec ("import numpy\n"
"import numpy as np\n"
"import matplotlib\n"
"import matplotlib.pylab as pylab\n"
"try:\n"
"import matplotlib.pyplot as plt\n"
"except ImportError:\n"
"pass\n"
) in user_ns
to try and encourage use of the 'canonical' ways of calling/executing
numpy and mpl calls. This is just in my branch, not publicly visible
yet. I wanted to know:
1. If I should keep the try/except around.
2. If this is your 'approved' manner of loading. It worries me a bit
that if we promote pyplot/plt as the entry point, it needs a proper
docstring. Just try 'pylab?' vs 'pyplot?' and you'll see the
difference.
Cheers,
f
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] log in hist() and toggling
John Hunter wrote:
> On Sat, May 24, 2008 at 6:02 PM, Olle Engdegård <[EMAIL PROTECTED]> wrote:
>
>> I very much miss the 'l' shortcut for toggling log/lin y-scale in the
>> trunk! I use it a lot.
>>
>> I suggest restoring it with something like
>>
>> if self.get_yscale() is ("log" or "linear"):
>>self.toggle_log_lineary()
>> else: pass
>>
>> I think most of time most people use log or linear scales.
>
>
> This seems reasonable, but when I tried to implement it it looked like
> the nan mask for the simple_plot.py example was sticky, eg when I
> toggled back to linear the negative values were still masked. I tried
> a simpler example still (all positive y data) and got something very
> strange: the plotted y values appear to change on a toggle from log
> and back to linear:
>
> In [18]: import matplotlib.pyplot as plt
>
> In [19]: plt.close('all')
>
> In [20]: ax = plt.subplot(111)
>
> In [21]: ax.plot(np.random.rand(20))
> Out[21]: []
>
> In [22]: ax.set_yscale('linear'); ax.figure.canvas.draw()
>
> In [23]: ax.set_yscale('log'); ax.figure.canvas.draw()
>
> In [24]: ax.set_yscale('linear'); ax.figure.canvas.draw() # the y
> data are now plotted differently
>
>
> I am not sure what is going on yet, but I'm sure Michael will chime in
> since I think we are seeing some funkiness in the new transforms and
> path infrastructure.
>
>
>> The new hist() function looks really good, I especially welcome the "step"
>> mode. A couple of comments:
>>
>> The latest svn incarnation doesn't allow for log scale in step-mode
>> (unless you set it manually).
>>
>> Also, I think the step-mode should have fill=False as default, otherwise
>> it does not look that much different from bar-mode. The nice thing about
>> step histograms is that you can put several of them in the same plot while
>> keeping it intelligible!
>
> Manuel is the developer behind these nice new changes to hist --
> hopefully he can help you here.
log-scale support for step-histograms is done now on the trunk.
Manuel
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
Darren Dale wrote:
> On Saturday 31 May 2008 11:44:34 pm Darren Dale wrote:
>
>> On Saturday 31 May 2008 10:19:47 pm John Hunter wrote:
>>
>>> On Sat, May 31, 2008 at 9:01 PM, Fernando Perez <[EMAIL PROTECTED]>
>>>
> I tracked this down by checking the contents of the generated
> build/latex/Matplotlib.tex, line 954. It is from the following code from
> mathtext.rst:
>
>
>> When using the STIX fonts, you also have the choice of:
>>
>> =
>> Command Result
>> =
>> ``\mathbb`` :math:`\mathbb{Blackboard}`
>> ``\mathcircled`` :math:`\mathcircled{Circled}`
>> ``\mathfrak``:math:`\mathfrak{Fraktur}`
>> ``\mathsf`` :math:`\mathsf{sans-serif}`
>> =
>>
>
>
> I'm not sure this is being properly rendered in the HTML output for me,
> either. Mike, are you able to compile this into a pdf on your machine, and if
> so, would you tell us how to configure STIX support? I commented this block
> out in svn for now.
>
Sorry about that. It requires the amssymb and/or amsmath LaTeX packages
to render correctly. Perhaps it is better to not require the LaTeX
installation to have anything special though. I think the best course
of action is to just include pre-generated images in the documentation
source for this. I'll go ahead and do that.
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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] scatter segfaults - mpl 0.91.2
It's giving a floating point exception on the following operation: i % Nface where Nface is the number of face colors, which in this case is 0. We probably want to trap for this case in the C code so it at least doesn't crash, but am I right that "c=''" is an invalid input? What should that do, if not raise an exception? Cheers, Mike Eric Firing wrote: > Dave wrote: > >> Whilst trying to plot a scatter plot with no facecolor I was able to reliably >> reproduce a segfault in mpl 0.91.2 - see below: >> >> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] >> IPython 0.8.3.svn.r3001 -- An enhanced Interactive Python. >> >> In [1]: import matplotlib >> In [2]: matplotlib.__version__ >> Out[2]: '0.91.2' >> In [3]: from pylab import scatter, rand >> In [4]: scatter(rand(100),rand(100),c='') >> <--SegFault--> >> >> That's probably not the right way to do it but it does work in 0.98.0. >> I'm unable to test on 0.91.3 at the moment. >> > > On ubuntu hardy with 0.91.3 from the svn maintenance branch: > > In [1]:import matplotlib > > In [2]:matplotlib.__version__ > Out[2]:'0.91.3' > > In [3]:from pylab import scatter, rand > > In [4]:scatter(rand(100), rand(100), c='') > Out[4]: > > In [5]:from pylab import show > > In [6]:show() > Floating point exception > > On the svn trunk it works. > > Eric > > - > 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 > 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
John Hunter wrote: > On Sat, May 31, 2008 at 9:19 AM, Darren Dale <[EMAIL PROTECTED]> wrote: > >> I'll be working on converting docstrings to rest this weekend. Should any of >> this be done on the branch? Or should we just focus on the trunk? >> > > As far as I am concerned, the documentation effort is for the trunk. > The only reason to do them on the branch too is to make merges of > other code changes easier, which may be a compelling reason. If the > docstrings get far out of whack, it may make merging other changes > very painful. But at the same time, I don't want the burden of > trying to keep the two in sync stopping you from getting the work done > that you need to do. Maybe you can try it and see how hard it is, and > if proves to be too much of an impediment, just concentrate on the > trunk. Michael, any advice here? > I was away on the weekend, so just getting back. Darren: you rock. The documentation is looking great! I agree with John -- I think the documentation effort should be focused on the trunk. Now that we have (apparently) such a stable 0.91.3, hopefully the maintenance branch will be much less frequently modified anyway. Theoretically, we should only run into merge conflicts related to docstrings if the docstrings on the maintenance branch are themselves edited. If we're just going to be doing bugfixes on the branch, that seems unlikely. 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] future of mpl documentation
On Mon, Jun 2, 2008 at 8:12 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > I agree with John -- I think the documentation effort should be focused on > the trunk. Now that we have (apparently) such a stable 0.91.3, hopefully > the maintenance branch will be much less frequently modified anyway. > Theoretically, we should only run into merge conflicts related to > docstrings if the docstrings on the maintenance branch are themselves > edited. If we're just going to be doing bugfixes on the branch, that seems > unlikely. Up to know, we've been adding features and bugs on the branch and then merging them in. Going forward, I think we should just focus on bug-fixes on the branch and mostly implement a feature-freeze, which will promote stability and encourage people who want the new stuff onto the trunk. We don't have to be fanatical about this -- if there is a great feature we can put in w/o compromising stability, that's fine, but I think our default should be bug-fixes only. JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] scatter segfaults - mpl 0.91.2
On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > We probably want to trap for this case in the C code so it at least > doesn't crash, but am I right that "c=''" is an invalid input? What > should that do, if not raise an exception? facecolor='' or facecolor='None' in other parts of the code (eg Line2D), mean do not fill the marker. But the principle of least surprise, we should probably support this for the polygon collections too, unless there is a good reason not to. JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot vs pylab?
On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <[EMAIL PROTECTED]> wrote: > I've added this little bit of code to the default ipython -pylab startup: The latest releases of pylab already provide np and plt in the pylab namespace. Would it be better to simply add a "pyplot" mode to ipython to encourage the proper usage, and in this mode import only as few symbols (np, plt, and sp if possible)? > it needs a proper docstring. Just try 'pylab?' vs 'pyplot?' We can easily add the docstring for the next bug fix release JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] scatter segfaults - mpl 0.91.2
Ok. This should now be fixed in r5358. Cheers, Mike John Hunter wrote: > On Mon, Jun 2, 2008 at 7:45 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > >> We probably want to trap for this case in the C code so it at least >> doesn't crash, but am I right that "c=''" is an invalid input? What >> should that do, if not raise an exception? >> > > facecolor='' or facecolor='None' in other parts of the code (eg > Line2D), mean do not fill the marker. But the principle of least > surprise, we should probably support this for the polygon collections > too, unless there is a good reason not to. > JDH > -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] svnmerge question
Hey Michael, I recently committed a pyplot patch for the switch_backends functionality, and when I went to svnmerge it I go the changes for your backend_agg fix. Since I would rather let you handle these, what is the best way to back out of the situation I am in. I guess what I would like to do is * ignore the backend_agg changes on my end * just merge the pyplot changes * not screw anything up that you are doing and preserve the merge for you What is the best way to proceed in this situation? JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] pyplot vs pylab?
On Mon, Jun 2, 2008 at 7:28 AM, John Hunter <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 3:26 AM, Fernando Perez <[EMAIL PROTECTED]> wrote: > >> I've added this little bit of code to the default ipython -pylab startup: > > The latest releases of pylab already provide np and plt in the pylab > namespace. > > Would it be better to simply add a "pyplot" mode to ipython to > encourage the proper usage, and in this mode import only as few > symbols (np, plt, and sp if possible)? I'm not sure the duplication is worthwhile (users don't read mailing lists on weekends, you know? They have lives and all that :) Besides, for ipython the 'import *' mode *is* a reasonable use case, since when you're working interactively, you really just want to type plot(x,cos(x**2)+sin(x**3)) and not some plt.foo/np.bar contraption. So I think there remains a use case for importing all the names in at the top level (remember that you can configure now ipython to NOT do 'from pylab import *' anymore if you reall want a clean namespace). The use case is mostly to provide an environment where the standard examples and docstrings that may use either numpy or np, pylab/pyplot/plt are always defined, so users can copy/paste without fear. Cheers, f - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] svnmerge question
John Hunter wrote: > Hey Michael, > > I recently committed a pyplot patch for the switch_backends > functionality, and when I went to svnmerge it I go the changes for > your backend_agg fix. Since I would rather let you handle these, what > is the best way to back out of the situation I am in. I guess what I > would like to do is > > * ignore the backend_agg changes on my end > > * just merge the pyplot changes > > * not screw anything up that you are doing and preserve the merge for you > > What is the best way to proceed in this situation? > None of those _backend_agg.cpp changes apply to the trunk. Just replace _backend_agg.cpp with _backend_agg.cpp.working and commit. (Or I can do that...) 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Neat vector field plots
Howdy, just saw this on the sage list: http://sview01.wiredworkplace.net/pub/vfplot/index.html The code is partly GPL (it uses a BSD kd-tree library), so don't go looking there. But the basic ideas sound pretty neat for producing very clean-looking vector fields. It would be neat if mpl grew something along these lines... Cheers f - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Neat vector field plots
On Mon, Jun 2, 2008 at 2:42 PM, Fernando Perez <[EMAIL PROTECTED]> wrote: > The code is partly GPL (it uses a BSD kd-tree library), so don't go > looking there. But the basic ideas sound pretty neat for producing > very clean-looking vector fields. It would be neat if mpl grew > something along these lines... And now that we have spline path elements in mpl98, we can actually implement curved arrows w/o an onerous polygon approximation. JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Neat vector field plots
John Hunter wrote: > And now that we have spline path elements in mpl98, we can actually > implement curved arrows w/o an onerous polygon approximation. Then could we do this too? http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg from: http://ccom.unh.edu/vislab/projects/FlowVis.html -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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Neat vector field plots
On Mon, Jun 2, 2008 at 4:32 PM, Christopher Barker <[EMAIL PROTECTED]> wrote: > John Hunter wrote: >> And now that we have spline path elements in mpl98, we can actually >> implement curved arrows w/o an onerous polygon approximation. > > Then could we do this too? > > http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg That appears to have a gradient field gray->white on the arrows, which we haven't implemented. But I'd like too... JDH - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Neat vector field plots
On Mon, Jun 2, 2008 at 2:32 PM, John Hunter <[EMAIL PROTECTED]> wrote: >> http://ccom.unh.edu/vislab/images/projects/Kat350Vert2.jpg > > That appears to have a gradient field gray->white on the arrows, which > we haven't implemented. But I'd like too... A bit of acid and the right music on top of that figure, and you can sell MPL for psychedelic raves :) Cheers, f - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A few more proposed hist() changes
While going through and updating some scripts to use the new features
that were recently added to hist(), I found myself very confused by
the align keywords - I had to go and look at Manuel Metz's post a
couple weeks ago to believe it wasn't a typo in the documentation...
"center" and "edge" are exactly the opposite of what one would have
thought (as he noted)... I've attached a diff of my proposed solution
- accepting the old keywords for backwards-compatibility, but have the
documentation only mention two keywords that make more sense ('left'
and 'mid').
I've added two other features as well - for some of the histograms I'm
making, it makes sense to have plots that are cumulative from the left
instead of the right - with this patch, that's allowed by passing in
cumulative=-1 (or anything else that is less than 0 - True still
operates the way it did before). To make this also easier from the
perspective of how some might want the histogram to look, I've also
added a 'right' option to the 'align' keyword.
Hopefully these changes will now satisfy all possible uses that anyone
can imagine for a histogram. :)
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5368)
+++ lib/matplotlib/axes.py (working copy)
@@ -5592,7 +5592,7 @@
def hist(self, x, bins=10, normed=False, cumulative=False,
- bottom=None, histtype='bar', align='edge',
+ bottom=None, histtype='bar', align='mid',
orientation='vertical', rwidth=None, log=False, **kwargs):
"""
call signature::
@@ -5628,6 +5628,10 @@
The last bin gives the total number of datapoints. If normed is
also True then the histogram is normalized such that the last bin
equals one.
+If a value that evaluates to less that one (e.g. -1), the
+direction of accumulation is reversed. In this case, If normed is
+also True then the histogram is normalized such that the first bin
+equals one.
histtype:
[ 'bar' | 'barstacked' | 'step' ] The type of histogram
@@ -5636,9 +5640,10 @@
stacked on top of each other, and 'step' generates a lineplot.
align:
-['edge' | 'center' ] Controles how the histogram is plotted.
-If 'edge', bars are centered between the bin edges.
-If 'center', bars are centered on the left bin edges
+['left' | 'mid' | 'right' ] Controles how the histogram is plotted.
+If 'left', bars are centered on the left bin edges.
+If 'mid', bars are centered between the bin edges.
+If 'right', bars are centered on the right bin edges.
orientation:
[ 'horizontal' | 'vertical' ] If horizontal, barh will be used
@@ -5688,10 +5693,15 @@
n = [n,]
if cumulative:
-if normed:
-n = [(m * np.diff(bins)).cumsum() for m in n]
-else:
-n = [m.cumsum() for m in n]
+ if cumulative < 0:
+ slc=slice(None,None,-1)
+ else:
+ slc=slice(None)
+
+ if normed:
+ n = [(m * np.diff(bins))[slc].cumsum()[slc] for m in n]
+ else:
+ n = [m[slc].cumsum()[slc] for m in n]
ccount = 0
colors = _process_plot_var_args.defaultColors[:]
@@ -5721,9 +5731,13 @@
else:
raise ValueError, 'invalid histtype: %s' % histtype
-if align=='edge':
+if align == 'mid' or align=='edge':
boffset += 0.5*totwidth
-elif align != 'center':
+elif align == 'left' or align == 'center':
+pass #TODO?
+elif align == 'right':
+boffset += totwidth
+else:
raise ValueError, 'invalid align: %s' % align
if orientation == 'horizontal':
@@ -5758,10 +5772,14 @@
y = np.zeros( 2*len(bins), np.float_ )
x[0::2], x[1::2] = bins, bins
-
-if align == 'center':
+
+if align == 'mid' or align=='edge':
+pass
+elif align == 'left' or align == 'center':
x -= 0.5*(bins[1]-bins[0])
-elif align != 'edge':
+elif align == 'right':
+x -= (bins[1]-bins[0])
+else:
raise ValueError, 'invalid align: %s' % align
if log:
-
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
