-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
Orthogonal normalization #175
Comments
Hello, I will add an option to change configuration.normalize to support orthogonal normalization (need to be careful with the real transforms there). Another thing is as there are too many ways to scale the numbers, maybe just making full support for callbacks is a good idea? Best regards, |
Hi Dmitrii, thanks for your response. The callbacks would definitely solve the problem with scaling. However I still have the feeling that when you want to do only the normalization, it would be much easier just to specify the forward/inverse scale or use the solution I proposed instead of studying and writing own callbacks. I don't mind writing callbacks myself, but I think there will be people having problems understanding them eventhough all they wanted was to run a normalized transformation. I'm curious about your thoughts on this matter. Thanks! David |
Hello, This is a valid point, I will try to add this before the next release. Best regards, |
Perfect, thank you very much! |
Hi,
I was wandering if it would be possible to extend the normalization options to include orthogonal normalization for both DFT and DTT. The behaviour should be like:
I would suggest adding an enum to specify the type of the normalization:
In the
VkFFTConfiguration
structure I would suggest either to change thenormalization
member datatype toVkFFTNormalize
datatype or just stick to the originalpfUINT
:Both of the solutions work without warnings. See the code example.
Thanks.
David
The text was updated successfully, but these errors were encountered: