search

bukka / php-fftw

PHP Wrapper for FFTW library
Other
3 stars 1 forks source link

Multi-dimensional Transforms #8

Open rspadim opened 10 years ago

rspadim commented 10 years ago

we have some function like: fftw_plan_dft_1d/fftw_plan_dft_2d/fftw_plan_dft_3d/fftw_plan_dft fftw_plan_dft_r2c_1d/fftw_plan_dft_r2c_2d/fftw_plan_dft_r2c_3d/fftw_plan_dft_r2c fftw_plan_r2r_1d/fftw_plan_r2r_2d/fftw_plan_r2r_3d/fftw_plan_r2r

i don't know if fftw_plan_dft could execute as fast as fftw_plan_dft_1d, fftw_plan_dft_2d, fftw_plan_dft_3d, must test fftw lib, but the point is...

should we implement fftw_plan_dft_1d, fftw_plan_dft_2d, fftw_plan_dft_3d, fftw_plan_dft, or we could implement just one function that select the "right" function to execute, based in what kind of array we received? for example:

1d) execute fftw_plan_dft_1d array(1d dimension values)

2d) execute fftw_plan_dft_2d array( array(1d dimension values), array(1d dimension values), array(1d dimension values), )

3d) execute fftw_plan_dft_3d array( array( array(3d dimension value), array(3d dimension value), ),array( array(3d dimension value), array(3d dimension value), ) )

etc... must check how fftw handle 3+d and if fftw_plan_dft_1d runs as fast as fftw_plan_dft(): http://www.fftw.org/fftw3_doc/Multi_002ddimensional-Transforms.html#Multi_002ddimensional-Transforms

bukka commented 10 years ago

Yeah we should implement all fftw functions. Testing should be done for each function (one file for each test) + you can add some generic test. The test should have naming like : fftw_plan_dft_3d_basic.phpt for basic tests. And then there can be more advanced tests. It's important to not put too much stuff to one file as it's quite difficult to find the error.

Generally about the testing for bindings: the main thing is test if bound functions using correct function from the lib. And also test if the function generates all errors when bad output provided. We don't need to do an extensive testing of the correctness for the lib function as it should responsibility of the lib...

rspadim commented 10 years ago

Yeah we should implement all fftw functions.

ok :) +1

The test should have naming like : fftw_plan_dft_3d_basic.phpt for basic tests

should i name it as 002-fftw_plan_dft_3d_basic.phpt , or the prefix isn't important? i don't know how phpt files are executed the 001 test file, test if extension exists, should we keep SKIP IF part in all tests?

It's important to not put too much stuff to one file as it's quite difficult to find the error.

ok, like 002 right? some doubts for example a test file that will create the plan, execute and destroy should i split it to 3 test files, one create, one execute, one destroy?

We don't need to do an extensive testing of the correctness for the lib function as it should responsibility of the lib...

yes, i agree we should get errors of wrapper not libs errors

but i'm considering this after the frist version of this ext: 1) if we upgrade the fftw3 lib, will we have errors at "php userspace"? should they port all math from old database to a new database, before upgrade? with some tests we could report these problems without receiving bug reports maybe we could create these files as "use-case-test-sin.phpt", "use-case-test-cos.phpt", etc, it will nice to docs at examples part (i'm considering 16 elements inside array), i'm considering just 4 signals, sin, cos, impulse, and triangle, with fft() and ifft(fft())

2)i don't know if fftw3 for arm/x86/x86_64/linux/windows report different values, with different values we couldn't call php-fftw portable between these plataforms, and report it at docs, since i don't have all plataforms to test, should be interesting receive bug reports when someone execute a phpt test

3) no problem about removing these test files :) it just help reducing the bug report (or not)

checking faq of fftw: there's some comments about Question 3.7. FFTW gives results different from my old FFT. Question 3.8. FFTW gives different results between runs

maybe the test case could show user about these situations, at 3.7 they report an error of "about 1e-15 or so in double precision,"

just to log here: about ifft(fft()), there's a FAQ (Question 3.10. Why does your inverse transform return a scaled result?) that we should consider in test files