semilogx and semilogy don't reset linear scale

Eric Firing <efiring@...229...> writes:

Andrew Straw wrote:

Eric Firing wrote:

Specifically, it looks like the farthest left xticklabel is no longer
getting displayed. Personally, I think it looks better this way, but now
that the test suite is coming online, we will finally start noticing
little things like this.

I agree that the newer version, without the first label, is better--but
I can't imagine how the change to semilogx and semilogy could make a
difference like this. It must be something else.

Well, if you look at
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
versus
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio

that's where the difference happened, thus leading to my assertion. What
changed between those two builds was r7585. Perhaps something else is
responsible, though...

7584 was the Tony's change on the branch; 7585 was the svnmerge to the
trunk, which pulled in earlier changes that had not been merged yet. The
others were just documentation, though, so I am still mystified. Oh, well.

If I'm reading the waterfall display correctly, it looks like my commit
7597 changed the result again. I only touched documentation and
docstrings... have you tried running the buildbot several times on the
same sources?

···

--
Jouni K. Sepp�nen

Jouni K. Seppänen wrote:

Eric Firing <efiring@...229...> writes:

Andrew Straw wrote:
    

Eric Firing wrote:
      

Specifically, it looks like the farthest left xticklabel is no longer
getting displayed. Personally, I think it looks better this way, but now
that the test suite is coming online, we will finally start noticing
little things like this.
          

I agree that the newer version, without the first label, is better--but
I can't imagine how the change to semilogx and semilogy could make a
difference like this. It must be something else.
        

Well, if you look at
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/34/steps/test/logs/stdio
versus
http://mpl-buildbot.code.astraw.com/builders/build%20and%20test%3A%20Mac%20OS%20X%20x86%20(sage%20buildslave)/builds/35/steps/test/logs/stdio

that's where the difference happened, thus leading to my assertion. What
changed between those two builds was r7585. Perhaps something else is
responsible, though...
      

7584 was the Tony's change on the branch; 7585 was the svnmerge to the
trunk, which pulled in earlier changes that had not been merged yet. The
others were just documentation, though, so I am still mystified. Oh, well.
    
If I'm reading the waterfall display correctly, it looks like my commit
7597 changed the result again. I only touched documentation and
docstrings... have you tried running the buildbot several times on the
same sources?
  
Curiouser and curiouser...

No, I hadn't considered that it might be non-deterministic. However,
looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
this is a totally different failure than we were seeing with Eric's
patch. I should probably start archiving the results of the failed
images so we can go back in time looking at these things.

I'm going to ponder this for a while.

-Andrew

So now I am getting what looks like a font error on the sage buildbot,
even though I wasn't getting one before on this image. Is this
because the new good was generated on linux with a different font
config, you think? It would be really nice if we could crack this
font issue.

I tracked down and fixed the unitized tick formatter, and removed the
known failure decorator from that test, so we hopefully will see that
error drop out of the next build.

JDH

···

On Sun, Aug 30, 2009 at 10:24 AM, Andrew Straw<strawman@...36...> wrote:

No, I hadn't considered that it might be non-deterministic. However,
looking at the absdiff image of test_matplotlib.TestAxes.empty_datetime,
this is a totally different failure than we were seeing with Eric's
patch. I should probably start archiving the results of the failed
images so we can go back in time looking at these things.

I'm going to ponder this for a while.

Hey this is strage now the baseline image is wrong (it has one line
and should have two). Earlier didn't the baseline have two and the
actual have one? Did someone upload the broken one line version as
the new baseline. I can fix the baseline with the new actual, but I
am curious how this baseline image got in there.

JDH

···

On Sun, Aug 30, 2009 at 11:42 AM, John Hunter<jdh2358@...149...> wrote:

So now I am getting what looks like a font error on the sage buildbot,
even though I wasn't getting one before on this image. Is this
because the new good was generated on linux with a different font
config, you think? It would be really nice if we could crack this
font issue.

I tracked down and fixed the unitized tick formatter, and removed the
known failure decorator from that test, so we hopefully will see that
error drop out of the next build.

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.

JDH

···

On Sun, Aug 30, 2009 at 11:47 AM, John Hunter<jdh2358@...149...> wrote:

Hey this is strage now the baseline image is wrong (it has one line
and should have two). Earlier didn't the baseline have two and the
actual have one? Did someone upload the broken one line version as
the new baseline. I can fix the baseline with the new actual, but I
am curious how this baseline image got in there.

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

···

On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jdh2358@...149...> 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.

John Hunter 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

···

On Sun, Aug 30, 2009 at 12:57 PM, John Hunter<jdh2358@...149...> wrote: