Boost logo

Boost :

Subject: Re: [boost] GSOC 2013
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-04-19 20:15:39

Le 18/04/13 15:39, Dmitriy Gorbel a écrit :
> I want to provide my proposal to the Boost community.
> Please, lets discuss it! I will be grateful for your reviews and advices.
> How can I improve it?
> I appreciate any feedback you may have.
> proposal_Dmitriy_Gorbel.pdf
> <>
Hi, I have read carefully your proposal and I have some suggestion to
improve it and a lot of questions for you. I don't pretend that you must
have an answer to all these question now, but your answers will help us
to see if you are really aware of the problems and to improve the scope
of your proposal. Some of your answers should be part of your proposal.

I would suggest you to "quote" any text that is taken exactly from
external resources as e.g wikipedia.

Your proposal must state clearly whether you want to implement binary or
decimal fixed points.

What would you add to the C++1y proposal?

Why the range and resolution must be static? Which advantages would have
a run-time range and/or resolution? On which context each approach is

What kind of problems have floating point types? Are you aware of the
problems fixed point numbers have respect to floating point numbers?

How fixed-point number solves the problems fixed-point numbers have?

Why do you say that "undefined behavior after signed integer arithmetic

Are you aware of the limitations of the C++11 proposal? Could it be used
on embedded systems?

What would be the result of

There are clearly several possibilities. Should your library provide the
user with the capacity to choose? If yes, how? if not why?

You talk about the need to round for division. Do you know of other
cases where rounding is needed?

Would the conversion of fixed points with different range and resolution
be implicitly/explicitly convertibles? And respect to C++ built-in
types? Would you provide some kind of cast between numbers?

What would be the size associated to a fixed-point type? Should it be
defined by the library or should the library let the user give some
hints to use the storage for the user.
Should the classes constructor have allocators for arbitrary large
fixed-point types?

Do you think that it is enough to use just an enum to define the
rounding policies or it would be better to let the user to define its
The same question for overflow.

What external resources have you read in addition to the C++1y proposal?
have you read the Boost ML archives respect to this subject?

There are several notations for fixed point numbers that don't use range
and precission. There are people that use to use these notations. How
your library will let them to use their preferred notation?

Hoping all these questions would not discourage you. The domain is not
too big but large enough. You should know it and choose what you think
is better to implement first and what is implementable under the time frame.

Are you confident with the implementation of the prototype in the
sandbox? Do you find it is too complex? if yes, why? would you start
from the prototype on the sandbox or would you start from zero?

Do you prefer to implement something well defined even with some
limitations or explore the domain and see what could/should be done?


P.S. Please check the syntax and grammar of the text.

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