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

Skip to content

changed default values of Axes.specgram() #9221

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

Conversation

andreh7
Copy link

@andreh7 andreh7 commented Sep 25, 2017

as proposed in #9100 (comment)

PR Summary

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 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

Copy link
Member

@dstansby dstansby left a comment

Choose a reason for hiding this comment

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

👍

@jklymak
Copy link
Member

jklymak commented Sep 25, 2017

I still think this is the wrong way to go, and that axes.specgram should pass None arguments through to mlab.specgram so the defaults in mlab.specgram are used. Otherwise, the two are in danger of becoming inconsistent.

To properly format the plot, the output from mlab.specgram should be used, not the input. Given that the plotting function only uses Fs, and Fs is easily retrievable from the output (= 2 * freq[-1]) this is easily done.

@dstansby
Copy link
Member

(FWIW I think eventually mlab.specgram should disappear and be replaced by https://docs.scipy.org/doc/scipy-0.17.0/reference/generated/scipy.signal.spectrogram.html since Matplotlib is really a plotting library and not a spectral analysis library)

@anntzer
Copy link
Contributor

anntzer commented Nov 28, 2017

pyplot would need to be regenerated too (or #9173 merged :-)). And I agree that the whole thing should be deprecated anyways.

@jklymak
Copy link
Member

jklymak commented Apr 24, 2018

I'm going to close this, because its sat for quite a while and I don't think the proposed behaviour is correct. Feel free to re-open if I am mistaken.

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.

4 participants