Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Deprecate redundant log-scale transform classes. #12832

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

Merged
merged 1 commit into from
Mar 3, 2019

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Nov 18, 2018

PR Summary

Having a bunch of separate log Transform classes is mentioned as an optimization, but that optimization wasn't even there anymore. Restore it, while keeping everything in a single log Transform class.

PR Checklist

  • Has Pytest style unit tests
  • Code is Flake 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@anntzer anntzer added this to the v3.1 milestone Nov 18, 2018
@jklymak
Copy link
Member

jklymak commented Nov 18, 2018

Looks like this barely changed a few images, but overall 👍 on the change. Surprising these aren't used anywhere....

@anntzer
Copy link
Contributor Author

anntzer commented Nov 18, 2018

The tiny change in baseline images appears to come from floating point errors between log10()/log2() and log()/log(10)/log()/log(2).
To be honest I'm kind of tempted to just kill the "optimization" as I doubt it's anywhere close to being a performance-limiting factor. Thoughts?

with np.errstate(divide="ignore", invalid="ignore"):
log = {np.e: np.log, 2: np.log2, 10: np.log10}.get(self.base)
if log: # If possible, do everything in a single call to Numpy.
out = log(a)
Copy link
Member

@jklymak jklymak Nov 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the optimization you are referring to? I guess I think this is a good idea since it covers 99.9% of the cases, and would instead suggest changing the images or increasing the tolerance. But I'm not an expert on how expensive the un-optimized code is...

@anntzer anntzer force-pushed the fewer-log-transforms branch from 060b128 to 8747e87 Compare November 19, 2018 21:20
@anntzer
Copy link
Contributor Author

anntzer commented Nov 19, 2018

Decided to just bump the tolerances, which were already set to 0.02 on some architectures anyways.

@anntzer anntzer force-pushed the fewer-log-transforms branch 2 times, most recently from 467f536 to 7a90d25 Compare January 2, 2019 10:22
@anntzer
Copy link
Contributor Author

anntzer commented Mar 3, 2019

rebased

@anntzer anntzer force-pushed the fewer-log-transforms branch from 2df7888 to d19fd81 Compare March 3, 2019 11:22
@timhoffm timhoffm merged commit 8137b4c into matplotlib:master Mar 3, 2019
meeseeksmachine pushed a commit to meeseeksmachine/matplotlib that referenced this pull request Mar 3, 2019
@anntzer anntzer deleted the fewer-log-transforms branch March 3, 2019 20:17
timhoffm added a commit that referenced this pull request Mar 3, 2019
…832-on-v3.1.x

Backport PR #12832 on branch v3.1.x (Deprecate redundant log-scale transform classes.)
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

Successfully merging this pull request may close these issues.

3 participants