Final report for GSoC '21

[sinandredemption]

Hello @ckormanyos and @cosurgi

In this PR I will be writing the final report for GSoC '21. Please feel free to tell me in case an informal PR like this might not be the best way to write a report.

I would request your feedback along the way, since this is my first time drafting a formal report (I've had a lot of first-times during GSoC '21...). Also, since English is not my first language, I would request you to feel free to be picky with my choice of words/sentences.

[ckormanyos]

Hi @sinandredemption this is good. We will follow the progress on report here and review along the way.

[ckormanyos]

Hi @sinandredemption it might be easier to make progress on this than imagined. In the first paragraph, I really like the description. Subsequently header listings show code artifacts. This is good and states very well the problem to be solved. But in addition to that (or instead of that), I would be happier with a few simple paragraphs that explain what the main classes do, what design choices are, how they fit into number and finally, briefly how to use them. I would rather have a few good informative paragraphs instead of code re-listing.

For instance, you can indicate that there are the necessary constructors and the minimal set of required backend eval_* functions as well as complete support for numeric_limits, how these fit into number. Then a bit about design, testing is done with Boost-style jam-file and GHA, etc. Rapid pace, simple. Highlighting the top level design.

This whole thing can move right along quite quickly.

[sinandredemption]

Thank you @ckormanyos for your extremely helpful and valuable advice

Since GSoC report would require direct listing of the code I've contributed, I wonder what would in your opinion be the best way to go about this. Here are a few ideas (although I am not sure if any of these will be acceptable):

• Categorize my commits and list them one-by-one in the report with a few comments for each category
• Simply link to the relevant lines from develop branch in the mentioned categorize
• Link just one URL listing all of my commits (probably not the best option)

[ckormanyos]

GSoC report would require direct listing of the code I've contributed, I wonder what would in your opinion be the best way to go about this. Here are a few ideas (although I am not sure if any of these will be acceptable):

Good question @sinandredemption. At Boost we are a rather large org with a very large code base. So qhat we do is create a complete User for each individual year of GSoC. You have been part of this.

After that in order to link to your code you successively link to:

• the BoostGSoC21 GitHub member,
• the individual multiprecision fork,
• your most active running PR and/or branch (even if closed) which would be your gsoc2021_quad_float branch

It is lucidly clear within your branch within your separate user in the fork what changes there are. If you decide to write a few supplemental sentences describing this, then that's OK too.

In all my years of mentoring, I have never had problems with those kinds of links or delivery of the coding result.

Cc: @cosurgi

[ckormanyos]

Hi @sinandredemption I really like the way your report is coming into shape.

I might actually suggest using the actual (albeit late-decided) names of the backend classes (i.e., cpp_double_fp_backend and cpp_quad_fp_backend) within the title.

In the section on testing, you might mention that testing also uses a subset of the standard Boost.Multiprecision tests including arithmetic tests and tests of elementary transcendental functions. Although the entire test suite is not yet finished, a strong subset of the Boost-style CI is implemented within the standard jamfile and GitHubActions flow. Branch protection and a nightly build keeps branches and the develop branch cleanly running.

On future work we have the existing issues to work through. These include various refinements to constructors and some actual numerical inconsistencies and/or errors. We need to incorporate the full CI testing and some test exceptions for edge cases were, purposely, neglected during the coding phase. These need to be fully taken into account and gotten to pass.

@sinandredemption and @cosurgi

[cosurgi]

Is this one https://github.com/BoostGSoC21/multiprecision/blob/78a01080bca5b9cfb9553899c5528172cd6770e3/report/report.md the latest version of the report, to look at?

[sinandredemption]

Is this one https://github.com/BoostGSoC21/multiprecision/blob/78a01080bca5b9cfb9553899c5528172cd6770e3/report/report.md the latest version of the report, to look at?

Yes, though I'm writing it live, so expect updates every couple of hours.

[sinandredemption]

@ckormanyos @cosurgi I believe that this looks something like the final report. Please do write your feedback at will, and I will try to incorporate changes ASAP, since the deadline is in less than 24 hours.

What a fantastic GSoC it has been!

[ckormanyos]

write your feedback at will,

Awesome @sinandredemption !

My feedback is that it's great. Good job. Good report on a fantastic GSoC from your side.

Could you please find a way to merge or somehow get the report onto the develop branch of our fork? For some reason CI is not working onj this branch. So I do not really want us to merge unless we fugure out why CI is not working.

Cc: @cosurgi

[sinandredemption]

For some reason CI is not working onj this branch.

My bad, I have been cancelling all the jobs manually so as not waste resources. Once @cosurgi gives a nod, I'll rerun the jobs and merge :)

[cosurgi]

Yes, please let the CI go green and merge it :) The report is really good! :)

[ckormanyos]

CI go green and merge it

Done thant you Fahad and Janek.

Cc: @sinandredemption and @cosurgi