DFT: Scaling behaviour

[adegomme]

When cuFFT was merged, it was noted in the discussion that it was not supporting forward/backward scaling, and some tests were adapted to remove BACKWARD_SCALE parameter and apply scaling during result checking only.

Discussion originally here:
Originally posted by @lhuot in #284 (comment)

But this was not done everywhere, as cuFFT does not support real_real storage. Thus these tests have kept using BACKWARD_SCALE and expect the backend to perform the scaling, or fail verification.

I'm currently adding support for ArmPl/FFTW, and the behaviour here is the same as in cuFFT, scaling is left to handle by the user after computations (rationale here https://www.fftw.org/faq/section3.html#whyscaled ).
But it also supports split calls (real_real), and then I'm in the zone where I can't fix tests without breaking the others. So I would like to reopen the discussion to try to end up with a more unified solution:

• Either all tests ignore scaling, and backends not supporting it warn (like cuFFT), so we remove BACKWARD_SCALE references from compule_in(out_of_)place_real_real.hpp (but this means this goes untested and result actually vary depending on the backend (which is already the case))
• Either we force all backends to perform the scaling every time (performance wise it may not be a good idea). I started doing this but we have to be careful to actually do the full journey through the dimensions/strides/offsets which is normally done by the library.
• Or we find a way where the backends report if they are willing to do the scaling or not, and tests adapt ? but this may change external API or add a query.

[lhuot]

Or we find a way where the backends report if they are willing to do the scaling or not, and tests adapt ? but this may change external API or add a query.

How about using the forward/backward scale in all the tests, backend that do not support it natively (from the vendor library implementation) throw an exception at commit, that is caught in the test and trigger an adjustment in the test: additional commit with scale set to +/-1 and adjustment done for verification similarly to what is done for cuFFT currently?

Tagging @Rbiessy

[adegomme]

That would be a good way of handling this, indeed. And it's simple enough to test quickly.
If it's acceptable for end users to fail and iterate like this, I will go this way (I don't see why not, there are already unimplemented exceptions in most backends).

[Rbiessy]

I think @lhuot's suggestion makes sense.

But this was not done everywhere, as cuFFT does not support real_real storage. Thus these tests have kept using BACKWARD_SCALE and expect the backend to perform the scaling, or fail verification.

My memory of the issue is fuzzy. The tests already have the mechanism to mark a test as skipped when an unimplemented exception occurs so I wonder why there are no tests with a custom FORWARD_SCALE now. I think this would be a good addition.