Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

axes limits (in old "round_numbers" mode) affected by floating point issues #5767

Closed
anntzer opened this issue Dec 30, 2015 · 4 comments
Closed
Milestone

Comments

@anntzer
Copy link
Contributor

anntzer commented Dec 30, 2015

Compare

In [1]: plt.plot([0, .2]); plt.ylim()
Out[1]: (0.0, 0.20000000000000001)

In [2]: plt.plot([-.1, .2]); plt.ylim()
Out[2]: (-0.10000000000000001, 0.25)

Note how the upper ylim changes from 0.2 to 0.25. This behavior is even tested (indirectly) by test_axes:test_vline_limit. I intend to change this behavior in my work on #5738/#5755 so that the upper limit is actually 0.2 in both cases (basically relying on matplotlib.ticker.Base, which has been written exactly to handle this).

Thoughts?

@mdboom
Copy link
Member

mdboom commented Dec 30, 2015

Yes -- I think fixing anything that comes from floating-point representation inaccuracies like this is fair game.

@anntzer
Copy link
Contributor Author

anntzer commented Dec 30, 2015

OK, I think I got this fixed but of course this breaks a ton of image comparison tests (because axes limits got tighter) and I had never managed to run the test suite successfully locally (even setting local_freetype=False in setup.cfg doesn't help, most image comparisons always fail). Is there a way to have e.g. travis regenerate the test images and download them? (Of course I will check visually that they make sense).

@mdboom
Copy link
Member

mdboom commented Dec 30, 2015

Is there a way to have e.g. travis regenerate the test images and download them?

There was, but that's currently not working because I lost access to the AWS account they went to. I'm working on it, but it will be a few days...

Maybe we could work on why the tests are failing for you? I assume you've read this and installed all the dependencies etc? What platform are you on?

EDIT: I'm happy to meet you on gitter.im to work through getting the test suite to work for you...

anntzer added a commit to anntzer/matplotlib that referenced this issue Dec 31, 2015
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Note that this requires working around a bug in numpy's implementation
of divmod (numpy/numpy#6127).

Many test images have changed!

See matplotlib#5767.
anntzer added a commit to anntzer/matplotlib that referenced this issue Dec 31, 2015
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Note that this requires working around a bug in numpy's implementation
of divmod (numpy/numpy#6127).

Many test images have changed!

See matplotlib#5767.

Probably also wraps up work on matplotlib#5738, but tests are missing.
anntzer added a commit to anntzer/matplotlib that referenced this issue Dec 31, 2015
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Note that this requires working around a bug in numpy's implementation
of divmod (numpy/numpy#6127).

Many test images have changed!

See matplotlib#5767.

Probably also wraps up work on matplotlib#5738, but tests are missing.
anntzer added a commit to anntzer/matplotlib that referenced this issue Dec 31, 2015
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Note that this requires working around a bug in numpy's implementation
of divmod (numpy/numpy#6127).

Many test images have changed!

See matplotlib#5767.

Also some more progress on matplotlib#5738.
anntzer added a commit to anntzer/matplotlib that referenced this issue Jan 1, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
anntzer added a commit to anntzer/matplotlib that referenced this issue Jan 1, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
anntzer added a commit to anntzer/matplotlib that referenced this issue Jan 2, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
anntzer added a commit to anntzer/matplotlib that referenced this issue Feb 15, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
jenshnielsen pushed a commit to jenshnielsen/matplotlib that referenced this issue Mar 20, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
jenshnielsen pushed a commit to jenshnielsen/matplotlib that referenced this issue Mar 20, 2016
plt.plot([-.1, .2]) used to pick (in round numbers mode) [-.1, .25] as
ylims due to floating point inaccuracies; change it to pick [-.1, .2]
(up to floating point inaccuracies).

Support for the (unused and deprecated-in-comment) "trim" keyword
argument has been dropped as the way ticks are picked has changed.

Many test images have changed!

Implementation notes:
- A bug in numpy's implementation of divmod (numpy/numpy#6127) is worked
around.
- The implementation of scale_range has also been cleaned.

See matplotlib#5767, matplotlib#5738.
@anntzer
Copy link
Contributor Author

anntzer commented May 11, 2016

Closed by #6192.

@anntzer anntzer closed this as completed May 11, 2016
@QuLogic QuLogic added this to the 2.0 (style change major release) milestone May 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants