Re: [boost] GSOC 2013

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
> <http://boost.2283326.n4.nabble.com/file/n4645577/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 
preferable?

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

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

What would be the result of
   nonnegative<8,-4>+nonnegative<8,-4>?

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 
strategy?
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?

Best,
Vicente

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