Re: [boost] GSOC 2013

Subject: Re: [boost] GSOC 2013
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2013-04-25 15:18:18

>> 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.