search

BoostGSoC21 / math

Boost.org math module
http://boost.org/libs/math
Boost Software License 1.0
0 stars 1 forks source link

GSoC writeup report #27

Closed ckormanyos closed 3 years ago

ckormanyos commented 3 years ago

This issue tracks any needed discussions regarding GSoC21 writeup/report.

@Lagrang3 and @cosurgi

Lagrang3 commented 3 years ago

Hi @ckormanyos. The report will not be included in boostorg/math, I think is not a good idea to write it in this repository. If we do so, then the report would have to be discarded by hand during merging. Is is ok with you if we write the report on a dedicated repository?

ckormanyos commented 3 years ago

Is is ok with you if we write the report on a dedicated repository?

Sure Eduardo. Hi @Lagrang3 of course the report can be wherever you prefer. A separate repo is a great idea.

Basically the existence of the report and some small amount of sensible content is key in this particular issue.

Lagrang3 commented 3 years ago

Here it is https://github.com/BoostGSoC21/math-fft-report

ckormanyos commented 3 years ago

Here it is https://github.com/BoostGSoC21/math-fft-report

That seems like a good location. If anyone complains, we can talk again. Maybe some others might even use a similar idea.

Lagrang3 commented 3 years ago

@ckormanyos, @cosurgi: first draft version is out

ckormanyos commented 3 years ago

first draft version

Hello @Lagrang3 this is a great draft Eduardo. I really like the content which includes both theoretical aspects as well as interface details.

Just a few really minor suggestions...

In the preliminary chapter Implementation, I would encourage you to be rather terse and short instead of long and detailed, favoring brevity. I might suggest to rename that chapter to Implementation Details or Design Details accordingly, and keep it rather terse and fast-paced.

For the benchmarks, I would suggest one or at most two FFT forms available in all three backend types (BSL, FFTW, GLS) and show how these compare with each other. We can stress that the BSL version is at this stage very rudimentary and has not been subjected to dedicated optimization efforts or development activities of that kind.

The appoendix on Abstract Ring is in my opinion optional. Honestly, I am weak on that theory and, although I need such theory, this might not be the best place to spend time on its discourse. I consider a brief paragraph or two OK, but please I recommend save your time on that particular discourse.

Nice Work!

@cosurgi

cosurgi commented 3 years ago

This draft looks really good! I will take time to read it carefully and report back.

Lagrang3 commented 3 years ago

@cosurgi, @ckormanyos:I produced some benchmarks for real and std::complex<double> transforms using the three backends with enforcing the various algorithms by choosing different sizes (powers of 2, powers of 10 and prime numbers), shown in the draft in the page with the six plots. Would you like me to include other benchmarks? Suggestions? If we choose other complex types we have to leave out the GSL backend.

One comparison I have in mind is the real vs complex for our BSL backend, to see whether there's actually a factor of 2 in performance. And maybe do a benchmark of Number Theoretical Transform for different powers of 2 up to 10^6 to see how it scales.

Lagrang3 commented 3 years ago

I've just published a complete version of the report. It is not necessarily the final. See here.

Lagrang3 commented 3 years ago

@ckormanyos, @cosurgi: by the way. This week I was cleaning up the code a bit, adding or extending the examples and all this work is found is PR #28. However, the MSCV tests are failing. Can you help me figure out the problem so that we can merge these changes?

ckormanyos commented 3 years ago

just published a complete version of the report

It is a fantastic report that summarizes your truly excellent work in GSoC '21. You can be very proud of these ground-breaking steps toward FFT in Boost. Good job, Eduardo!

@Lagrang3

the MSCV tests are failing. Can you help me figure out the problem

I will take a look and report what I find...

Cc: @cosurgi

Lagrang3 commented 3 years ago

@ckormanyos. Thanks

cosurgi commented 3 years ago

I fully agree with @ckormanyos , this report is so good, that when reading it I only found a couple of typos:

page 4, 3.3. missing 't': "Very of(t)en" page 5, 3.4. missing 'e' "On(e) reason" page 6, missing 'n' "once w is know(n) there are"

And only one remark on page 7 : "cpp_complex_50, cpp_complex_quad and mpc_complex_50" are just examples of handled cpp_complex types (based on cpp_bin_float real type), we also handle mpc_complex family based on mpfr real type.

Great work @Lagrang3 !

Lagrang3 commented 3 years ago

@cosurgi: can I write it like this: ? "bsl_dft can handle, for instance besides the previously mentioned complex types, also the family of boost::multiprecision::cpp_complex and boost::multiprecision::mpc_complex based on cpp_bin_float and mpfr real types respectively; eg. cpp_complex_50, cpp_complex_quad and mpc_complex_50."

cosurgi commented 3 years ago

yes, it is perfect.

cosurgi commented 3 years ago

Small correction: the full name for mpfr is mpfr_float_backend.

Lagrang3 commented 3 years ago

Done. Thanks. Hi uploaded a new version, with the text corrections suggested by Janek. Also in table 2. I added a column with the relative speedup of real vs complex algorithms, and in figure 2 I fixed the values of the time, they where in units of ns, instead of ms as the label shows.