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.