Boost logo

Boost :

Subject: Re: [boost] GSOC 2013
From: Dmitriy Gorbel (dmitriycpp_at_[hidden])
Date: 2013-04-28 18:23:50

Vicente Botet wrote
>>> As I said there are several notations and there is no real one that
>>> would make happy everyone. So I think that the library should take in
>>> account this point and provide some aliases (c++11)/type traits(c++98)
>>> for the most common notations.
>>> Choosing the default notation is critical and having a consensus on it
>>> would be difficult. Do you think that it is worth proposing several
>>> default notations and request the boost community to choose the default
>>> one?
>> Yes, of course, boost community should choose the default notation.
> I would start this as soon as possible as this could take some time. I
> would start a thread as well for the naming of the different classes.
> Having to provide several notations let me think that the use of at
> least a namespace fixed_point is mandatory to don't pollute the Boost
> namespace.

I started a thread at the ML and wait for community feedback.

Vicente Botet wrote
>> What is the best way to provide several notations?
> Template alias?

Just for now, if provide only 2 notations(notation from c++1y proposal and Q
I can just get absolute value from the resolution parameter.
For example, in this two notations types same:
negatable<8, -8> for c++1y proposal notation is equal to
negatable<8, 8> for Q notation
If users really want more than 2 notations,
I will have to solve this issue.

Vicente Botet wrote
> As you are for using enum for rounding/overflow policies, could you add
> the policies that you must implement and when these policies will be
> implemented?

In the last days I explored closely the prototype, and
the closer I get to the prototype the more I like it :)
I really like OOP design for rounding and overflow strategies.
Moreover, exists strateges comply with the requirements of the c++1y
proposal and provide even more features.

But c++1y proposal require enum for the strategies,
can my proposal slightly break c++1y proposal?

Vicente Botet wrote
> I don't see when you would develop the math functions on the planning.

That's already in the specification and timeline.

Vicente Botet wrote
> Please don't forget to apply to GSoC as soon as possible so that the
> Mentors starts to evaluate your proposal and how you react to possible
> improvements.

Link to my proposal on GSOC site

Christopher Kormanyos wrote
> 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.

I strongly agree with you.
The prototype now work similar to your suggestions.

Christopher Kormanyos wrote
> 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.

What if I will use Boost.multiprecision library
for numbers with representation larger then 64 bits?
Now I correct my proposal, I send new version to this ML
and GSOC site as soon as possible.


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at