John Hunter wrote: > On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jdh2...@gmail.com> wrote: > >> OK, I figured this out. The new failure was on formatter4, not >> formatter5. I didn't see that when I posted earlier. It turns out >> when we were working at scipy and I wrote that script to move new >> saved-results into baseline, I inadvertently moved a bad formatter4 >> image into the baseline, so the baseline image was broken. When I >> fixed the bug, the unit test caught the difference. I've updated the >> baseline so now everything should be good for that particular test. > > The empty_datetime continues to mystefy me. The actual had ticks from > 1..23 and the baseline had ticks from 2..00. The current behavior on > my box is 1..23 and that seems fine to me, so I re-updated the > baseline with that file. I'm attaching the actual and baseline from > the last buildbot before my update. The sage box *should* pass on the > next build test because I've corrected the two known failures. If > there is anything I am missing about this empty datetime test, let me > know
So it sounds like there have been three different behaviors: 0 to 24, 1 to 23, and 2 to 24. I think what we are seeing here is differences in floating point behavior among different platforms, and/or differences in datetime implementation from one python version to another. The standard python library datetime is being used to generate the floating point xlim in days. It looks like (2009, 1, 20) and (2009, 1, 21) can end up as floating point numbers a hair above or a hair below the target integers, and that difference of a hair is enough to determine whether a tick is generated or not. A side point here is that the precision of the floating point numbers is lousy for most applications, because of the choice of "year 1" as the origin. This is a case of mpl following a bad choice by Matlab. One way to get around the first problem--the datetime tick dependence on platform--would be to put fudge factors into the autoscaling so that the limits would be expanded some small amount. More generally, the autoscaling could have margins, which might default to the tiny amount necessary to prevent the datetime indeterminacy, but might be put to other good uses by the user. Often one really wants the xlim and ylim to be a little wider than the data range, so that symbols are plotted entirely within the axes, for example. This was suggested a very long time ago, and it has resurfaced many times in my mind, but obviously I never did anything about it. Eric ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
