P.S. The proposal. proposal_Dmitriy_Gorbel.pdf http://boost.2283326.n4.nabble.com/file/n4646027/proposal_Dmitriy_Gorbel.pdf I think this is final version, or close to final.
I have a major suggestion. You do not have to accept my suggestion, since I am only an observer of this project. I strongly suggest limiting the scope of the GSoC fixed-point project to a specific number of digits, such as those that can fit into int8_t, int16_t, int32_t, and int64_t. This can be done with one template and one decimal split. It would allow for fixed-point representations all the way from Q0.63 through Q31.32, up to Q63.0. I recommend this because it will make the project feasible when it comes to any computations of elementary transcendental functions. Consider, for example, our implementation of Boost's floating-point multiprecision back end. This back end is also severely limited to approx. less than 1,000 decimal digits. We can extend it later, but we are happy to have something now, even with its limitations. The same holds true for fixed-point. I think people need a good, well-tested fixed-point class supporting a rich set of transcendental functions much more than they need high-precision fixed-point. I will be very difficult to develop algorithms for sin, cos, log, exp, for an unlimited number of digits extending all the way to the realm of multiprecision. In fact, it would be a remarkable feat to do it in one summer. On the other hand, you could plug fixed-point into multiprecision for digit counts exceeding, say, 64. So it is really up to you guys how you want to deal with this.
I don't see when you would develop the math functions on the planning.
You really do need to include elementary functions, such as a all of those or at least a subset of those in <cmath>. Sincerely, Chris.