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

Fix frequency argument in sine and multi_sine #135

Closed
mgrub opened this issue May 27, 2020 · 4 comments · Fixed by #151
Closed

Fix frequency argument in sine and multi_sine #135

mgrub opened this issue May 27, 2020 · 4 comments · Fixed by #151

Comments

@mgrub
Copy link
Contributor

mgrub commented May 27, 2020

I just worked with the sine and multi_sine methods and the freq-argument gets used in different ways, than I would expect it:

In misc.testsignals.sine line 185 should be replaced by x = amp * np.sin(2 * np.pi * freq * time) (all multiplication). Alternativly, the freq parameter could be renamed to period.

In misc.testsignals.multi_sine line 213 should be replaced by x += amp * np.sin(2 * np.pi * freq * time) (scale sine by 2pi). Alternativly, the freq parameter could be renamed to angular_frequency.

To have a matching signature of both sine and multi_sine, I suggest to keep using the freq-argument, but adjust their use in the code as proposed.

Some references for the suggested changes can be found here:
https://de.wikipedia.org/wiki/Sinuston
https://en.wikipedia.org/wiki/Angular_frequency

@BjoernLudwigPTB
Copy link
Member

BjoernLudwigPTB commented May 27, 2020

I find your suggestions great . That's something we hadn't noticed yet! But this is again a breaking change, because the original calculations have to be changed, right? Should we add this to the "major release 2.0" milestone? By the way: shouldn't we rather call the sine function in misc.testsignals.multi_sine line 213 to avoid such a thing in the future?

@mgrub mgrub added this to the major release 2.0 milestone May 27, 2020
@mgrub
Copy link
Contributor Author

mgrub commented May 27, 2020

Yes, the original calculations have to be changed. But I am still not fully convinced, if this is a breaking change or a necessary fix (because we adjust the behaviour to what the docstring is already saying).

Yes, we should call sine from multisine.

@BjoernLudwigPTB
Copy link
Member

Yes, the original calculations have to be changed. But I am still not fully convinced, if this is a breaking change or a necessary fix (because we adjust the behaviour to what the docstring is already saying).

mhm 🤨 you are right, still this changes the behaviour of previously written code. I can see how this reflects the expected behaviour though, following your linked articels. So you suggest introducing the changes and releasing this as a fix?

@mgrub
Copy link
Contributor Author

mgrub commented May 29, 2020

Alright, I changed my mind. Let's consider this a breaking change and fix it with the 2.0.0 release.

@BjoernLudwigPTB BjoernLudwigPTB added this to To do in PyDynamic Roadmap via automation May 30, 2020
@BjoernLudwigPTB BjoernLudwigPTB linked a pull request Sep 18, 2020 that will close this issue
12 tasks
BjoernLudwigPTB added a commit that referenced this issue Nov 3, 2020
Harmonize sine signal generators
@BjoernLudwigPTB BjoernLudwigPTB moved this from To do to Reviewer approved in PyDynamic Roadmap Nov 10, 2020
PyDynamic Roadmap automation moved this from Reviewer approved to Done Nov 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

2 participants