You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1
(2) |
2
(2) |
3
(4) |
4
(3) |
5
|
6
(3) |
7
(1) |
8
|
9
(7) |
10
(8) |
11
(14) |
12
(11) |
13
(14) |
14
(2) |
15
|
16
(4) |
17
(4) |
18
(9) |
19
(2) |
20
|
21
(2) |
22
|
23
(3) |
24
(7) |
25
(15) |
26
(2) |
27
(8) |
28
(4) |
29
(2) |
30
(5) |
31
(8) |
|
|
|
|
From: Eric F. <ef...@ha...> - 2010-08-27 07:15:13
|
On 08/26/2010 05:13 PM, Brian Granger wrote: > Hi, > > We are in the process of getting our new Qt IPython GUI working with > matplotlib. One problem we have found is that the matplotlib qt4 > backend always creates a QApplication. This is problematic in > situations where another part of an application has already created a > QApplication. The fix is to have matplotlib first see if a > QApplication already exists and then use that one. The attached patch > implements this fix. If needed, Fernando can help test this, but I > think the change is minor enough that it should be good to go. I committed it. I suspect the most recent changes to ipython may require changes to show, but they can wait until things settle down a bit. Eric > > Cheers, > > Brian |
From: Brian G. <ell...@gm...> - 2010-08-27 03:13:46
|
Hi, We are in the process of getting our new Qt IPython GUI working with matplotlib. One problem we have found is that the matplotlib qt4 backend always creates a QApplication. This is problematic in situations where another part of an application has already created a QApplication. The fix is to have matplotlib first see if a QApplication already exists and then use that one. The attached patch implements this fix. If needed, Fernando can help test this, but I think the change is minor enough that it should be good to go. Cheers, Brian |
From: Erik T. <eri...@gm...> - 2010-08-26 18:07:54
|
Oh, excellent, then I don't have to do the test case, because I believe this solves my original problem :) Thanks! On Wed, Aug 25, 2010 at 12:15 AM, Reinier Heeres <re...@he...> wrote: > Hi all, > > Sorry for not finishing this nicely. I was looking at this last > weekend, and concluded that this approach was not the way to fix the > problem. The real problem was that we still had the old X/Y axes > around and had to use new functions for the 3d axes (e.g. > set_xticks*3d*, set_xlim*3d* etc). I just extracted these fixes from > my working directory and committed them to svn (r8656). There are a > few more things to polish; for example it would be good to check > whether we have to change the view limits if we change the ticks. > > Next on my list is cleaning up some of the alpha handling in mplot3d. > > Cheers, > Reinier > > On Tue, Aug 24, 2010 at 9:04 PM, Benjamin Root <ben...@ou...> wrote: >> On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud <eri...@gm...> >> wrote: >>> >>> Sorry for the re-ping if it was taken care of in some way I didn't >>> undertand, but this doesn't seem to have been changed on the trunk >>> svn... should it have been, or is there some other branch that this >>> stuff is being worked on? >>> >>> On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...> >>> wrote: >>> > Great - if anything's unclear, I can fairly easily make a test case as >>> > Benjamin suggested, so just let me know if that's necessary - thank! >>> > >>> > On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> >>> > wrote: >>> >> Hi Erik, >>> >> >>> >> Sorry for the delay. From just looking at the diff I would say it's a >>> >> great addition. I'll test tomorrow and push it if it works (which I >>> >> assume it does). >>> >> >>> >> Cheers, >>> >> Reinier >>> >> >>> >> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud >>> >> <eri...@gm...> wrote: >>> >>> Just a quick ping about this - did it get applied, or was there >>> >>> something wrong with it? (Or am I just too impatient?) >>> >>> >>> >>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud >>> >>> <eri...@gm...> wrote: >>> >>>> I noticed some odd behavior when trying to set ticks on 3d plots made >>> >>>> using mplot3d.Axes3D ... specifically, if you tries to access any of >>> >>>> the 3D axes and change the ticks, it would result in a plot all >>> >>>> squashed to one side (indicating some sort of projection problem). >>> >>>> After a bit of digging, I discovered the source of the problem: >>> >>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, >>> >>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong >>> >>>> interval to get the range assigned when ticks were added. So the >>> >>>> solution was to implement set_view_interval on the 3D Axis. That fix >>> >>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff >>> >>>> . Now setting ticks seems to work just fine, so I've included >>> >>>> another >>> >>>> diff that additionally implements set_?ticks3d and get_?ticks3d >>> >>>> methods for Axes3D - that's attached as >>> >>>> mpl3d-ticks-fix-add-methods.diff . >>> >>>> >>> >>>> -- >>> >>>> Erik Tollerud >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Erik Tollerud >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> The Palm PDK Hot Apps Program offers developers who use the >>> >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>> >>> of $1 Million in cash or HP Products. Visit us here for more details: >>> >>> http://ad.doubleclick.net/clk;226879339;13503038;l? >>> >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/ >>> >>> _______________________________________________ >>> >>> Matplotlib-devel mailing list >>> >>> Mat...@li... >>> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Reinier Heeres >>> >> Tel: +31 6 10852639 >>> >> >>> > >>> > >>> > >>> > -- >>> > Erik Tollerud >>> > >>> >>> >>> >>> -- >>> Erik Tollerud >>> >> >> I don't believe so, and I think this was shortly before Reinier went on >> vacation. Erik, my question still applies. If you can make a nice short >> example that demonstrates the problem, we can then include it as a test to >> make sure it will always work properly. >> >> If the patch passes the test, I can apply it myself now. >> >> Ben Root >> >> > > > > -- > Reinier Heeres > Tel: +31 6 10852639 > -- Erik Tollerud |
From: Ryan M. <rm...@gm...> - 2010-08-26 03:59:56
|
On Fri, Jul 9, 2010 at 7:27 PM, John Hunter <jd...@gm...> wrote: > On Fri, Jul 9, 2010 at 5:22 PM, Ryan May <rm...@gm...> wrote: > >> I've been "hard" at work over the last couple of months putting >> together a set of classes that simplifies the creation of animations >> in matplotlib. This started when I resurrected some old code for > > Very nice -- people are going to really like this. I've had several > requests personally to add something like this so thanks for doing it > :-) > * I am happy to see this pushed into trunk at any time. I would not > push it into the branch, but we can do a 1.1 trunk release as soon as > we are ready (release early, release often). Putting it in the trunk > will facilitate testing and other developer contributions. But if > you'd rather leave it in github for a while, I have no problem with > that either. Since this has stalled 6 weeks with me not doing much with it, I went ahead and checked it in. Hopefully I'll have an easier time doing incremental development (especially ReST docs) with it in. There are definitely still some things to clean up, especially in the area of saving movies. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
From: Fernando P. <fpe...@gm...> - 2010-08-25 22:14:42
|
On Wed, Aug 25, 2010 at 3:06 PM, Eric Firing <ef...@ha...> wrote: > Looks fine to me. It's fixing a bug. I don't think the comment is even > necessary--the rationale looks pretty obvious, and the code is clear. > Great, thanks. I'll shorten the comment to just one line then: + # Lowercase only non-module backend names (modules are case-sensitive) so that it serves as a little safety for the bug not to return, but is less verbose than before. Committed as revision 8657. Thanks! f |
From: Fernando P. <fpe...@gm...> - 2010-08-25 22:07:31
|
On Wed, Aug 25, 2010 at 2:59 PM, Gael Varoquaux <gae...@no...> wrote: > > Freeking awesome! > > Go go team! Thanks :) We're pretty happy, we'll post more in a few weeks when there's something more solid to show. Take care, f |
From: Eric F. <ef...@ha...> - 2010-08-25 22:07:21
|
On 08/25/2010 11:57 AM, Fernando Perez wrote: > Hi folks, > > I'd like to know if the fix below looks reasonable to you, this is a > diff against current svn trunk: > > dreamweaver[matplotlib]> svn diff > Index: __init__.py > =================================================================== > --- __init__.py (revision 8656) > +++ __init__.py (working copy) > @@ -880,10 +880,14 @@ > if 'matplotlib.backends' in sys.modules: > if warn: warnings.warn(_use_error_msg) > return > - arg = arg.lower() > if arg.startswith('module://'): > name = arg > else: > + # For non-module backends, normalize name to lowercase. Note that this > + # must NOT be done to module backends, because those need to be valid > + # Python module specifications that can be imported, and Python module > + # names *are* case sensitive. > + arg = arg.lower() > be_parts = arg.split('.') > name = validate_backend(be_parts[0]) > if len(be_parts)> 1: > > ##### END PATCH > > I hope the comments explain clearly enough the problem. For a bit of > context, this is biting us in ipython where we're building a custom > backend for Qt terminals that inline mpl figures (very neat [1]), but > our backend's name is module://IPython.zmq.pylab.backend_payload_svg. > If you lowercase that, it won't import later. I know we shouldn't > have called IPython's module with that funny capitalization, but it's > a bit late to change now, I'm afraid. > > Do you foresee any problems with the above change? > > If everyone OK's it, I'm happy to commit it, but I won't do anything > until others better informed than I reply. Looks fine to me. It's fixing a bug. I don't think the comment is even necessary--the rationale looks pretty obvious, and the code is clear. Eric > > Regards, > > f > > [1] teaser for the curious: > http://fperez.org/tmp/ipython_qt_pylab.png. All code is in the > 'newkernel' github branch. Special credits to Evan Patterson from > Enthought, the Qt brains behind the magic. > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Gael V. <gae...@no...> - 2010-08-25 22:00:04
|
On Wed, Aug 25, 2010 at 02:57:50PM -0700, Fernando Perez wrote: > [1] teaser for the curious: > http://fperez.org/tmp/ipython_qt_pylab.png. All code is in the > 'newkernel' github branch. Special credits to Evan Patterson from > Enthought, the Qt brains behind the magic. Freeking awesome! Go go team! Gaël |
From: Fernando P. <fpe...@gm...> - 2010-08-25 21:58:18
|
Hi folks, I'd like to know if the fix below looks reasonable to you, this is a diff against current svn trunk: dreamweaver[matplotlib]> svn diff Index: __init__.py =================================================================== --- __init__.py (revision 8656) +++ __init__.py (working copy) @@ -880,10 +880,14 @@ if 'matplotlib.backends' in sys.modules: if warn: warnings.warn(_use_error_msg) return - arg = arg.lower() if arg.startswith('module://'): name = arg else: + # For non-module backends, normalize name to lowercase. Note that this + # must NOT be done to module backends, because those need to be valid + # Python module specifications that can be imported, and Python module + # names *are* case sensitive. + arg = arg.lower() be_parts = arg.split('.') name = validate_backend(be_parts[0]) if len(be_parts) > 1: ##### END PATCH I hope the comments explain clearly enough the problem. For a bit of context, this is biting us in ipython where we're building a custom backend for Qt terminals that inline mpl figures (very neat [1]), but our backend's name is module://IPython.zmq.pylab.backend_payload_svg. If you lowercase that, it won't import later. I know we shouldn't have called IPython's module with that funny capitalization, but it's a bit late to change now, I'm afraid. Do you foresee any problems with the above change? If everyone OK's it, I'm happy to commit it, but I won't do anything until others better informed than I reply. Regards, f [1] teaser for the curious: http://fperez.org/tmp/ipython_qt_pylab.png. All code is in the 'newkernel' github branch. Special credits to Evan Patterson from Enthought, the Qt brains behind the magic. |
From: John H. <jd...@gm...> - 2010-08-25 17:59:22
|
I've updated the PDF on the main docs page http://matplotlib.sourceforge.net/contents.html Direct link: http://matplotlib.sf.net/Matplotlib.pdf JDH On Wed, Aug 25, 2010 at 11:01 AM, Michael Droettboom <md...@st...>wrote: > > -------- Original Message -------- Subject: wrong PDF on matplotlib web > site? Date: Wed, 25 Aug 2010 10:32:03 -0400 From: Joe Harrington > <jh...@ph...> <jh...@ph...> Reply-To: jh...@ph... To: > Michael Droettboom <md...@st...> <md...@st...> CC: > jh...@ph... > > Hi Michael, > > I just noticed that the User Guide PDF on the Matplotlib web site says > 0.99.3, even though the page it's downloaded from says 1.0.0. > > Also, there's no main Download link, just the one in News. > > Just FYI, do as you will, and thanks for all you do on Matplotlib! > > --jh-- > > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Eric F. <ef...@ha...> - 2010-08-25 17:06:35
|
On 08/25/2010 04:50 AM, Benjamin Root wrote: > On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald > <aar...@ph... <mailto:aar...@ph...>> wrote: > > On 24 August 2010 22:22, Benjamin Root <ben...@ou... > <mailto:ben...@ou...>> wrote: > > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald > <aar...@ph... <mailto:aar...@ph...>> > > wrote: > >> > >> On 24 August 2010 19:16, Erik Tollerud <eri...@gm... > <mailto:eri...@gm...>> wrote: > >> > Whoops, yes, that should be True... Also realized a slight > error in > >> > the description of how the mimum is set - both of those are > fixed in > >> > the attached diff. > >> > >> Um, this is a kind of important point of style: it is much better to > >> use "if foo:" than "if foo is True:" or even "if foo == True:". > >> Long-standing python convention allows things like 1, 7.0, numpy > >> booleans that are true, and nonempty lists to have a value of True. > >> Using "if foo:", this works. Using "if foo is True:", this cannot > >> possibly work; even though 1==True, it is not true that 1 is True. > >> "is" has a very specific meaning that should be used only when > >> appropriate (generally, for None or for mutable objects). > > [snip] > > > While it probably could be better done, the logic of the entire > if statement > > is to first check to see if someone explicitly set a True value > (default is > > False), and that sets the minimum to 1.0. Then, if it isn't > explicitly > > True, then it checks to see if it is a numerical value and uses > that value > > to indicate the minimum. Only if it is None or False does it > then go to the > > last branch which would set minimum to zero. > > > > Maybe it should use a cbook function that test for a numerical value > > explicitly instead and do that first, then have a check for the > Truthiness > > of log? > > I realize API changes are a pain, but this seems error-prone from a > user's point of view. If they accidentally use 1 instead of "True" - > common among C or old Python users - suddenly the function does > something startling. (There's also an ambiguity between zero and > False, but that's probably not so serious here.) If I were designing > an API from scratch I'd probably go with a separate parameter for the > minimum (or not, if ylim can fix it after the fact) and a dedicated > one for "should we use a log scale". Failing that, maybe the string > "auto" to indicate automatic minimum values and None for a default? > > If you're going to use True to mean something different from 1, > though, I'd make sure to put a warning in the docstring. Unfortunately > you can't just rely on duck typing to tell numeric values from > booleans, since float(True) is 1.0. On the other hand, "is True" fails > for numpy booleans, and "== True" passes for 1.0. So if this is your > constraint, I'm not sure you can do better than "is True", but it's a > huge UI wart. > > Anne > > P.S. keep in mind that the values users pass are not always directly > visible to users - they might be passing a value output from someone > else's routine that is described as returning a boolean value but > actually returns an integer. This is particularly common among C or > Fortran routines, which are in turn very common in the numerical > world. From the other direction, if you pull a value out of a boolean > numpy array, you get a numpy boolean which will never "is True". -A > > > I agree. After thinking about it further, I realized a few other ways > that this will silently fail. Quite personally, I feel that the > hist/bar family of functions ought to be nuked from orbit. It is > absolutely amazing just how convoluted those functions are. We seem to > be acquiescing to every single feature request rather than thinking > about how one could use the existing matplotlib tools. For example, if > one wants error bars on their histograms/bar plots, then they should be > able to call hist() and then errorbars() to achieve their needs. Ben, "Me, too!" regarding dismay over the hist/bar family (including box plots). They need to be rethought and re-implemented in their own module. Dealing with the transition may be a pain, but so is every experience with trying to maintain them. Eric > > For logarithmic hist(), I am not exactly sure why we should have a > keyword argument to indicate a mode of operation. We have loglog(), > semilogx(), semilogy(). A user could also call set_xscale() or > set_yscale() and the limits accordingly. I am not saying they are the > best examples/approaches, merely pointing out the different ways we have > for log plotting. > > Should we have histlog() and barlog() functions? Are we willing to make > an effort to look at some of these plotting functions and clean them up? > > Ben Root |
From: Michael D. <md...@st...> - 2010-08-25 16:01:29
|
-------- Original Message -------- Subject: wrong PDF on matplotlib web site? Date: Wed, 25 Aug 2010 10:32:03 -0400 From: Joe Harrington <jh...@ph...> Reply-To: jh...@ph... To: Michael Droettboom <md...@st...> CC: jh...@ph... Hi Michael, I just noticed that the User Guide PDF on the Matplotlib web site says 0.99.3, even though the page it's downloaded from says 1.0.0. Also, there's no main Download link, just the one in News. Just FYI, do as you will, and thanks for all you do on Matplotlib! --jh-- |
From: Benjamin R. <ben...@ou...> - 2010-08-25 14:50:37
|
On Wed, Aug 25, 2010 at 12:00 AM, Anne Archibald <aar...@ph... > wrote: > On 24 August 2010 22:22, Benjamin Root <ben...@ou...> wrote: > > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald < > aar...@ph...> > > wrote: > >> > >> On 24 August 2010 19:16, Erik Tollerud <eri...@gm...> wrote: > >> > Whoops, yes, that should be True... Also realized a slight error in > >> > the description of how the mimum is set - both of those are fixed in > >> > the attached diff. > >> > >> Um, this is a kind of important point of style: it is much better to > >> use "if foo:" than "if foo is True:" or even "if foo == True:". > >> Long-standing python convention allows things like 1, 7.0, numpy > >> booleans that are true, and nonempty lists to have a value of True. > >> Using "if foo:", this works. Using "if foo is True:", this cannot > >> possibly work; even though 1==True, it is not true that 1 is True. > >> "is" has a very specific meaning that should be used only when > >> appropriate (generally, for None or for mutable objects). > > [snip] > > > While it probably could be better done, the logic of the entire if > statement > > is to first check to see if someone explicitly set a True value (default > is > > False), and that sets the minimum to 1.0. Then, if it isn't explicitly > > True, then it checks to see if it is a numerical value and uses that > value > > to indicate the minimum. Only if it is None or False does it then go to > the > > last branch which would set minimum to zero. > > > > Maybe it should use a cbook function that test for a numerical value > > explicitly instead and do that first, then have a check for the > Truthiness > > of log? > > I realize API changes are a pain, but this seems error-prone from a > user's point of view. If they accidentally use 1 instead of "True" - > common among C or old Python users - suddenly the function does > something startling. (There's also an ambiguity between zero and > False, but that's probably not so serious here.) If I were designing > an API from scratch I'd probably go with a separate parameter for the > minimum (or not, if ylim can fix it after the fact) and a dedicated > one for "should we use a log scale". Failing that, maybe the string > "auto" to indicate automatic minimum values and None for a default? > > If you're going to use True to mean something different from 1, > though, I'd make sure to put a warning in the docstring. Unfortunately > you can't just rely on duck typing to tell numeric values from > booleans, since float(True) is 1.0. On the other hand, "is True" fails > for numpy booleans, and "== True" passes for 1.0. So if this is your > constraint, I'm not sure you can do better than "is True", but it's a > huge UI wart. > > Anne > > P.S. keep in mind that the values users pass are not always directly > visible to users - they might be passing a value output from someone > else's routine that is described as returning a boolean value but > actually returns an integer. This is particularly common among C or > Fortran routines, which are in turn very common in the numerical > world. From the other direction, if you pull a value out of a boolean > numpy array, you get a numpy boolean which will never "is True". -A > I agree. After thinking about it further, I realized a few other ways that this will silently fail. Quite personally, I feel that the hist/bar family of functions ought to be nuked from orbit. It is absolutely amazing just how convoluted those functions are. We seem to be acquiescing to every single feature request rather than thinking about how one could use the existing matplotlib tools. For example, if one wants error bars on their histograms/bar plots, then they should be able to call hist() and then errorbars() to achieve their needs. For logarithmic hist(), I am not exactly sure why we should have a keyword argument to indicate a mode of operation. We have loglog(), semilogx(), semilogy(). A user could also call set_xscale() or set_yscale() and the limits accordingly. I am not saying they are the best examples/approaches, merely pointing out the different ways we have for log plotting. Should we have histlog() and barlog() functions? Are we willing to make an effort to look at some of these plotting functions and clean them up? Ben Root |
From: Jae-Joon L. <lee...@gm...> - 2010-08-25 09:34:07
|
Hmm, it seems that somehow I only applied the patch to the trunk. http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=8418 But I think the patch also need to be applied to the maint. version. I'll see what I can do. Regards, -JJ On Wed, Aug 25, 2010 at 3:42 AM, Erik Tollerud <eri...@gm...> wrote: > Did this fix ever get applied? I was looking at some other svn > changes and it still says none of this part of legend.py has been > altered... > > On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee <lee...@gm...> wrote: >> On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud <eri...@gm...> wrote: >>> Jae-Joon, your patch looks to be effectively the same except for >>> slightly different behavior when more than 3 points are present... but >>> that was what was originally intended - the numpoints-> scatterpoints >>> was a good catch! >> >> I'm not sure if I put those numbers in the first places (maybe not), >> yes, that was what was originally intended. And I'm inclined to leave >> it as is. >> >> I'll commit the change soon. >> Thanks again. >> >> -JJ >> > > > > -- > Erik Tollerud > |
From: Reinier H. <re...@he...> - 2010-08-25 07:45:21
|
Hi all, Sorry for not finishing this nicely. I was looking at this last weekend, and concluded that this approach was not the way to fix the problem. The real problem was that we still had the old X/Y axes around and had to use new functions for the 3d axes (e.g. set_xticks*3d*, set_xlim*3d* etc). I just extracted these fixes from my working directory and committed them to svn (r8656). There are a few more things to polish; for example it would be good to check whether we have to change the view limits if we change the ticks. Next on my list is cleaning up some of the alpha handling in mplot3d. Cheers, Reinier On Tue, Aug 24, 2010 at 9:04 PM, Benjamin Root <ben...@ou...> wrote: > On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud <eri...@gm...> > wrote: >> >> Sorry for the re-ping if it was taken care of in some way I didn't >> undertand, but this doesn't seem to have been changed on the trunk >> svn... should it have been, or is there some other branch that this >> stuff is being worked on? >> >> On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...> >> wrote: >> > Great - if anything's unclear, I can fairly easily make a test case as >> > Benjamin suggested, so just let me know if that's necessary - thank! >> > >> > On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> >> > wrote: >> >> Hi Erik, >> >> >> >> Sorry for the delay. From just looking at the diff I would say it's a >> >> great addition. I'll test tomorrow and push it if it works (which I >> >> assume it does). >> >> >> >> Cheers, >> >> Reinier >> >> >> >> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud >> >> <eri...@gm...> wrote: >> >>> Just a quick ping about this - did it get applied, or was there >> >>> something wrong with it? (Or am I just too impatient?) >> >>> >> >>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud >> >>> <eri...@gm...> wrote: >> >>>> I noticed some odd behavior when trying to set ticks on 3d plots made >> >>>> using mplot3d.Axes3D ... specifically, if you tries to access any of >> >>>> the 3D axes and change the ticks, it would result in a plot all >> >>>> squashed to one side (indicating some sort of projection problem). >> >>>> After a bit of digging, I discovered the source of the problem: >> >>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, >> >>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong >> >>>> interval to get the range assigned when ticks were added. So the >> >>>> solution was to implement set_view_interval on the 3D Axis. That fix >> >>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff >> >>>> . Now setting ticks seems to work just fine, so I've included >> >>>> another >> >>>> diff that additionally implements set_?ticks3d and get_?ticks3d >> >>>> methods for Axes3D - that's attached as >> >>>> mpl3d-ticks-fix-add-methods.diff . >> >>>> >> >>>> -- >> >>>> Erik Tollerud >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Erik Tollerud >> >>> >> >>> >> >>> ------------------------------------------------------------------------------ >> >>> The Palm PDK Hot Apps Program offers developers who use the >> >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> >>> of $1 Million in cash or HP Products. Visit us here for more details: >> >>> http://ad.doubleclick.net/clk;226879339;13503038;l? >> >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/ >> >>> _______________________________________________ >> >>> Matplotlib-devel mailing list >> >>> Mat...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >>> >> >> >> >> >> >> >> >> -- >> >> Reinier Heeres >> >> Tel: +31 6 10852639 >> >> >> > >> > >> > >> > -- >> > Erik Tollerud >> > >> >> >> >> -- >> Erik Tollerud >> > > I don't believe so, and I think this was shortly before Reinier went on > vacation. Erik, my question still applies. If you can make a nice short > example that demonstrates the problem, we can then include it as a test to > make sure it will always work properly. > > If the patch passes the test, I can apply it myself now. > > Ben Root > > -- Reinier Heeres Tel: +31 6 10852639 |
From: Anne A. <aar...@ph...> - 2010-08-25 05:06:40
|
On 24 August 2010 22:22, Benjamin Root <ben...@ou...> wrote: > On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald <aar...@ph...> > wrote: >> >> On 24 August 2010 19:16, Erik Tollerud <eri...@gm...> wrote: >> > Whoops, yes, that should be True... Also realized a slight error in >> > the description of how the mimum is set - both of those are fixed in >> > the attached diff. >> >> Um, this is a kind of important point of style: it is much better to >> use "if foo:" than "if foo is True:" or even "if foo == True:". >> Long-standing python convention allows things like 1, 7.0, numpy >> booleans that are true, and nonempty lists to have a value of True. >> Using "if foo:", this works. Using "if foo is True:", this cannot >> possibly work; even though 1==True, it is not true that 1 is True. >> "is" has a very specific meaning that should be used only when >> appropriate (generally, for None or for mutable objects). [snip] > While it probably could be better done, the logic of the entire if statement > is to first check to see if someone explicitly set a True value (default is > False), and that sets the minimum to 1.0. Then, if it isn't explicitly > True, then it checks to see if it is a numerical value and uses that value > to indicate the minimum. Only if it is None or False does it then go to the > last branch which would set minimum to zero. > > Maybe it should use a cbook function that test for a numerical value > explicitly instead and do that first, then have a check for the Truthiness > of log? I realize API changes are a pain, but this seems error-prone from a user's point of view. If they accidentally use 1 instead of "True" - common among C or old Python users - suddenly the function does something startling. (There's also an ambiguity between zero and False, but that's probably not so serious here.) If I were designing an API from scratch I'd probably go with a separate parameter for the minimum (or not, if ylim can fix it after the fact) and a dedicated one for "should we use a log scale". Failing that, maybe the string "auto" to indicate automatic minimum values and None for a default? If you're going to use True to mean something different from 1, though, I'd make sure to put a warning in the docstring. Unfortunately you can't just rely on duck typing to tell numeric values from booleans, since float(True) is 1.0. On the other hand, "is True" fails for numpy booleans, and "== True" passes for 1.0. So if this is your constraint, I'm not sure you can do better than "is True", but it's a huge UI wart. Anne P.S. keep in mind that the values users pass are not always directly visible to users - they might be passing a value output from someone else's routine that is described as returning a boolean value but actually returns an integer. This is particularly common among C or Fortran routines, which are in turn very common in the numerical world. From the other direction, if you pull a value out of a boolean numpy array, you get a numpy boolean which will never "is True". -A |
From: Benjamin R. <ben...@ou...> - 2010-08-25 02:22:58
|
On Tue, Aug 24, 2010 at 9:01 PM, Anne Archibald <aar...@ph...>wrote: > On 24 August 2010 19:16, Erik Tollerud <eri...@gm...> wrote: > > Whoops, yes, that should be True... Also realized a slight error in > > the description of how the mimum is set - both of those are fixed in > > the attached diff. > > Um, this is a kind of important point of style: it is much better to > use "if foo:" than "if foo is True:" or even "if foo == True:". > Long-standing python convention allows things like 1, 7.0, numpy > booleans that are true, and nonempty lists to have a value of True. > Using "if foo:", this works. Using "if foo is True:", this cannot > possibly work; even though 1==True, it is not true that 1 is True. > "is" has a very specific meaning that should be used only when > appropriate (generally, for None or for mutable objects). > > Incidentally, the stairstep look of histograms is something I use a > lot. But if we're looking for bells and whistles to add, I often need > error bars on the histogram values (usually the error bar should be > the square root of the value, though for really small values there's a > correction based on Poisson statistics). Since I also often deal with > background-subtracted histograms that often need to repeat the data, I > expect to need to use errorbar() regardless, so I wouldn't worry too > much about this. > > Anne > > > On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing <ef...@ha...> wrote: > >> On 08/24/2010 08:39 AM, Erik Tollerud wrote: > >>> I just realized the patch I sent before includes some other changes... > >>> the attached version should only be the fix for this particular bug. > >> > >> + if log is true: > >> + minimum = 1.0 > >> > >> > >> Don't you mean True, not true? > >> > >> Eric > >> > >> > ------------------------------------------------------------------------------ > >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > >> Be part of this innovative community and reach millions of netbook users > >> worldwide. Take advantage of special opportunities to increase revenue > and > >> speed time-to-market. Join now, and jumpstart your future. > >> http://p.sf.net/sfu/intel-atom-d2d > >> _______________________________________________ > >> Matplotlib-devel mailing list > >> Mat...@li... > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >> > > > > > > > > -- > > Erik Tollerud > > > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > > Be part of this innovative community and reach millions of netbook users > > worldwide. Take advantage of special opportunities to increase revenue > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > Anne, While it probably could be better done, the logic of the entire if statement is to first check to see if someone explicitly set a True value (default is False), and that sets the minimum to 1.0. Then, if it isn't explicitly True, then it checks to see if it is a numerical value and uses that value to indicate the minimum. Only if it is None or False does it then go to the last branch which would set minimum to zero. Maybe it should use a cbook function that test for a numerical value explicitly instead and do that first, then have a check for the Truthiness of log? Ben Root P.S. -- I think firefox needs to update its spell-check dictionary, I thought Steven Colbert got "truthiness" to be added to Webster's... |
From: Anne A. <aar...@ph...> - 2010-08-25 02:01:36
|
On 24 August 2010 19:16, Erik Tollerud <eri...@gm...> wrote: > Whoops, yes, that should be True... Also realized a slight error in > the description of how the mimum is set - both of those are fixed in > the attached diff. Um, this is a kind of important point of style: it is much better to use "if foo:" than "if foo is True:" or even "if foo == True:". Long-standing python convention allows things like 1, 7.0, numpy booleans that are true, and nonempty lists to have a value of True. Using "if foo:", this works. Using "if foo is True:", this cannot possibly work; even though 1==True, it is not true that 1 is True. "is" has a very specific meaning that should be used only when appropriate (generally, for None or for mutable objects). Incidentally, the stairstep look of histograms is something I use a lot. But if we're looking for bells and whistles to add, I often need error bars on the histogram values (usually the error bar should be the square root of the value, though for really small values there's a correction based on Poisson statistics). Since I also often deal with background-subtracted histograms that often need to repeat the data, I expect to need to use errorbar() regardless, so I wouldn't worry too much about this. Anne > On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing <ef...@ha...> wrote: >> On 08/24/2010 08:39 AM, Erik Tollerud wrote: >>> I just realized the patch I sent before includes some other changes... >>> the attached version should only be the fix for this particular bug. >> >> + if log is true: >> + minimum = 1.0 >> >> >> Don't you mean True, not true? >> >> Eric >> >> ------------------------------------------------------------------------------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Erik Tollerud > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Benjamin R. <ben...@ou...> - 2010-08-25 01:05:11
|
On Tue, Aug 24, 2010 at 6:16 PM, Erik Tollerud <eri...@gm...>wrote: > Whoops, yes, that should be True... Also realized a slight error in > the description of how the mimum is set - both of those are fixed in > the attached diff. > > On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing <ef...@ha...> wrote: > > On 08/24/2010 08:39 AM, Erik Tollerud wrote: > >> I just realized the patch I sent before includes some other changes... > >> the attached version should only be the fix for this particular bug. > > > > + if log is true: > > + minimum = 1.0 > > > > > > Don't you mean True, not true? > > > > Eric > > > > > ------------------------------------------------------------------------------ > > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > > Be part of this innovative community and reach millions of netbook users > > worldwide. Take advantage of special opportunities to increase revenue > and > > speed time-to-market. Join now, and jumpstart your future. > > http://p.sf.net/sfu/intel-atom-d2d > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > -- > Erik Tollerud > > Just one quick issue, in the docstring, you have a typo "Toutlines" in the part that describes 'steps'. I believe that was supposed to be "The outlines". Ben Root |
From: Erik T. <eri...@gm...> - 2010-08-24 23:17:24
|
Whoops, yes, that should be True... Also realized a slight error in the description of how the mimum is set - both of those are fixed in the attached diff. On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing <ef...@ha...> wrote: > On 08/24/2010 08:39 AM, Erik Tollerud wrote: >> I just realized the patch I sent before includes some other changes... >> the attached version should only be the fix for this particular bug. > > + if log is true: > + minimum = 1.0 > > > Don't you mean True, not true? > > Eric > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Erik Tollerud |
From: Eric F. <ef...@ha...> - 2010-08-24 20:54:18
|
On 08/24/2010 08:39 AM, Erik Tollerud wrote: > I just realized the patch I sent before includes some other changes... > the attached version should only be the fix for this particular bug. + if log is true: + minimum = 1.0 Don't you mean True, not true? Eric |
From: Benjamin R. <ben...@ou...> - 2010-08-24 19:05:09
|
On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud <eri...@gm...>wrote: > Sorry for the re-ping if it was taken care of in some way I didn't > undertand, but this doesn't seem to have been changed on the trunk > svn... should it have been, or is there some other branch that this > stuff is being worked on? > > On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...> > wrote: > > Great - if anything's unclear, I can fairly easily make a test case as > > Benjamin suggested, so just let me know if that's necessary - thank! > > > > On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> > wrote: > >> Hi Erik, > >> > >> Sorry for the delay. From just looking at the diff I would say it's a > >> great addition. I'll test tomorrow and push it if it works (which I > >> assume it does). > >> > >> Cheers, > >> Reinier > >> > >> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> > wrote: > >>> Just a quick ping about this - did it get applied, or was there > >>> something wrong with it? (Or am I just too impatient?) > >>> > >>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud < > eri...@gm...> wrote: > >>>> I noticed some odd behavior when trying to set ticks on 3d plots made > >>>> using mplot3d.Axes3D ... specifically, if you tries to access any of > >>>> the 3D axes and change the ticks, it would result in a plot all > >>>> squashed to one side (indicating some sort of projection problem). > >>>> After a bit of digging, I discovered the source of the problem: > >>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, > >>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong > >>>> interval to get the range assigned when ticks were added. So the > >>>> solution was to implement set_view_interval on the 3D Axis. That fix > >>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff > >>>> . Now setting ticks seems to work just fine, so I've included another > >>>> diff that additionally implements set_?ticks3d and get_?ticks3d > >>>> methods for Axes3D - that's attached as > >>>> mpl3d-ticks-fix-add-methods.diff . > >>>> > >>>> -- > >>>> Erik Tollerud > >>>> > >>> > >>> > >>> > >>> -- > >>> Erik Tollerud > >>> > >>> > ------------------------------------------------------------------------------ > >>> The Palm PDK Hot Apps Program offers developers who use the > >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share > >>> of $1 Million in cash or HP Products. Visit us here for more details: > >>> http://ad.doubleclick.net/clk;226879339;13503038;l? > >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/ > >>> _______________________________________________ > >>> Matplotlib-devel mailing list > >>> Mat...@li... > >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > >>> > >> > >> > >> > >> -- > >> Reinier Heeres > >> Tel: +31 6 10852639 > >> > > > > > > > > -- > > Erik Tollerud > > > > > > -- > Erik Tollerud > > I don't believe so, and I think this was shortly before Reinier went on vacation. Erik, my question still applies. If you can make a nice short example that demonstrates the problem, we can then include it as a test to make sure it will always work properly. If the patch passes the test, I can apply it myself now. Ben Root |
From: Erik T. <eri...@gm...> - 2010-08-24 18:49:24
|
Sorry for the re-ping if it was taken care of in some way I didn't undertand, but this doesn't seem to have been changed on the trunk svn... should it have been, or is there some other branch that this stuff is being worked on? On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud <eri...@gm...> wrote: > Great - if anything's unclear, I can fairly easily make a test case as > Benjamin suggested, so just let me know if that's necessary - thank! > > On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> wrote: >> Hi Erik, >> >> Sorry for the delay. From just looking at the diff I would say it's a >> great addition. I'll test tomorrow and push it if it works (which I >> assume it does). >> >> Cheers, >> Reinier >> >> On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote: >>> Just a quick ping about this - did it get applied, or was there >>> something wrong with it? (Or am I just too impatient?) >>> >>> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote: >>>> I noticed some odd behavior when trying to set ticks on 3d plots made >>>> using mplot3d.Axes3D ... specifically, if you tries to access any of >>>> the 3D axes and change the ticks, it would result in a plot all >>>> squashed to one side (indicating some sort of projection problem). >>>> After a bit of digging, I discovered the source of the problem: >>>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, >>>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong >>>> interval to get the range assigned when ticks were added. So the >>>> solution was to implement set_view_interval on the 3D Axis. That fix >>>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff >>>> . Now setting ticks seems to work just fine, so I've included another >>>> diff that additionally implements set_?ticks3d and get_?ticks3d >>>> methods for Axes3D - that's attached as >>>> mpl3d-ticks-fix-add-methods.diff . >>>> >>>> -- >>>> Erik Tollerud >>>> >>> >>> >>> >>> -- >>> Erik Tollerud >>> >>> ------------------------------------------------------------------------------ >>> The Palm PDK Hot Apps Program offers developers who use the >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>> of $1 Million in cash or HP Products. Visit us here for more details: >>> http://ad.doubleclick.net/clk;226879339;13503038;l? >>> http://clk.atdmt.com/CRS/go/247765532/direct/01/ >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >> >> >> >> -- >> Reinier Heeres >> Tel: +31 6 10852639 >> > > > > -- > Erik Tollerud > -- Erik Tollerud |
From: Erik T. <eri...@gm...> - 2010-08-24 18:42:48
|
Did this fix ever get applied? I was looking at some other svn changes and it still says none of this part of legend.py has been altered... On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee <lee...@gm...> wrote: > On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud <eri...@gm...> wrote: >> Jae-Joon, your patch looks to be effectively the same except for >> slightly different behavior when more than 3 points are present... but >> that was what was originally intended - the numpoints-> scatterpoints >> was a good catch! > > I'm not sure if I put those numbers in the first places (maybe not), > yes, that was what was originally intended. And I'm inclined to leave > it as is. > > I'll commit the change soon. > Thanks again. > > -JJ > -- Erik Tollerud |
From: Erik T. <eri...@gm...> - 2010-08-24 18:39:57
|
I just realized the patch I sent before includes some other changes... the attached version should only be the fix for this particular bug. On Mon, Aug 23, 2010 at 7:23 PM, Erik Tollerud <eri...@gm...> wrote: > This is definitely a bug, but I thought I'd clarify and add in a little more... > > The distinction between 'step' and 'stepfilled' is that 'step' is > supposed to show only the outline of the histogram with no lines in > between bins (standard practice in some fields), while 'stepfilled' is > supposed to do the same, but have a different-colored fill between the > steps and the x-axis. This is different from 'bar' because the bars > always have either an outline bounding each bar, or no outline at all. > An alternative approach, presumably, would be to eliminate > 'stepfilled' and instead just pass in some keyword that tells whether > or not to draw the filled color region or not, but that was judged > confusing because it would have no meaning for the bar types. > > As for the log=True errors, I think what this was supposed to do was > have the minimum number of bin *counts* be the replacement for 0s, > rather the minimum *value*, so that's just a pure bug. This is might > have been my fault - the code has changed quite a bit from the > original patch, so I'm not sure at this point. The logic was that > this makes more sense than arbitrarily choosing 1 - if you have a > histogram where the bins are all within, say, 1000 and 10000, but one > of them is 0, it perhaps looks better to set the bottom to the 1000 > rather than 1... It was really just an arbitrary choice that no one > objected to at the time. > > As I think about it, it might make sense to change it so that the log > keyword can be used to set the assumed minimum value for empty bins if > it is greater than 0 (and stick with the default you suggested of 1 if > log=True). The attached patch includes this change, adopted from > Ben's original patch, as well as clarifying all of this in teh > docstring. > > > On Wed, Aug 11, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote: >> On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root <ben...@ou...> wrote: >>> >>> I am tracing down a bug in hist() and I am trying to figure out what is it >>> about the 'stepfilled' mode that is different from the regular 'bar' mode. >>> Currently, the hist() code has a separate if branch for dealing with 'step' >>> and 'stepfilled', and that branch has a bunch of bugs. The best that I can >>> figure is that it prevents lines from being drawn in between the bins. If >>> that is the only difference, maybe we could somehow use the bar functions? >>> >>> At the very least, I think this needs to be documented better to make it >>> clear why this oddball approach is happening. >>> >>> Thanks, >>> Ben Root >> >> By the way, the bugs I was referring to both have to do with log=True and >> the two stepped modes. >> >> First, the smallest of values to histogram (the minimum bin value) is, for >> some reason, used to clip the lower bounds of the histogram count. In some >> situations, this can result in most if not all the graph not being shown. >> >> Second, related to the first is a problem with the 'stepfilled' mode in log >> space. The stepfilled mode uses the minimum bin value to anchor the >> patches. However, this can cause the polygon to not close correctly and can >> get some unsightly artifacts. I have attached an image demonstrating this >> bug. This has been reported before: >> >> http://old.nabble.com/hist%28%29-with-log-and-step-tp28888742p28888742.html >> http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html >> >> In one of the comments, the reporter concluded that it appeared fixed, but >> either he was experiencing a slightly different problem, or he was mistaken. >> >> I have also included a possible patch for addressing these issues. The >> approach simply sets the minimum value to be zero when not doing log, and >> use 1.0 when log=True. This differs slightly from how the normal bar graphs >> are done where a value of 1e-100 is used when log=True, but then the axes >> limits are adjusted to use 1.0 as a lower limit. >> >> Cheers, >> Ben Root >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > > -- > Erik Tollerud > -- Erik Tollerud |