Vicente Botet wrote
Dmitriy, what is your opinion about this?
Best, Vicente
Sorry for the delay, I was busy at the weekend. At first thanks for your comments - I really not thought about some issues before reading it. Vicente Botet wrote
Your proposal must state clearly whether you want to implement binary or decimal fixed points.
I propose the binary fixed-point type. I will emphasize it in the proposal. Vicente Botet wrote
What would you add to the C++1y proposal?
I want to add some math functions, include ceil, floor, sqrt, sin, cos, exp, fabs, etc. Functions must work similar to standard C function with same name, but with fixed point numbers. I think it would be useful for end user. Vicente Botet wrote
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?
I think run-time range and resolution more comfortable and useful, but require more resources. Vicente Botet wrote
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?
Floating point arithmetic has a lot of problems, really. For example limited exponent range, loss of significance, unsafe standard operations. For exploring floating point problems I read http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems and http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html I think main advantage of the fixed-point numbers - customizable range and resolution, hence more efficient. Vicente Botet wrote
Why do you say that "undefined behavior after signed integer arithmetic overflow".
I mean that signed integer overflow causes undefined behavior. Vicente Botet wrote
Are you aware of the limitations of the C++11 proposal? Could it be used on embedded systems?
I think it depends on concrete embedded system and software developer. For example, templates are useful for making generic classes or functions. But they may increase the program size, which is critical for embedded systems applications. Furthermore, templates may increase the time of compilation. I know that some embedded developers avoid templates, namespaces, exceptions, virtual inheritance, etc. Vicente Botet wrote
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?
The range and resolution of the result calculate by(for addition and
subtraction):
nonnegative
You talk about the need to round for division. Do you know of other cases where rounding is needed?
Oh rounding needed in many cases. Rounding(or truncating) needed always when representation can't accumulate a number precisely. I said about division because division may have special result, with infinite fractional part. For example 1/3 = 0.333333333... Vicente Botet wrote
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?
In comments for your library you note about conversion policy when user can choose between implicitly/explicitly conversion. I will try to implement both variants. Vicente Botet wrote
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 mean size of the representation? I think, good way when user can set needed size. In this case allocators will be used. But also must be reasonable maximum size. What's your opinion? Vicente Botet wrote
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.
C++1y proposal require enum for rounding and overflow mode. I think it is enough. Vicente Botet wrote
What external resources have you read in addition to the C++1y proposal? have you read the Boost ML archives respect to this subject?
Yea, I read Boost ML, and external resources. I really liked this introduction to fixed-point arithmetic. http://www.digitalsignallabs.com/fp.pdf Vicente Botet wrote
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?
I think notation in the proposal clean and easy for understanding. What is your advice about this issue? Vicente Botet wrote
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?
Yes, I'm confident with the prototype. Honestly, it took some time for exploring it. Not very complex, but not simple. Just need time for understand. I would start from zero, but I will keep near the prototype. Vicente Botet wrote
Do you prefer to implement something well defined even with some limitations or explore the domain and see what could/should be done?
Ohh this is hard question. I would look for middle way. Michael Marcin-3 wrote
There is a typo: The range must be *grater* then the resolution
I don't understand your types.
cardinal<16> 0 <= n <= 65536
This seems to be a 16 bit unsigned type but requires 17 bits to store this range. It should probably be 0 <= n <= 65535.
integral<4> -16 <= n <= 16
Similar here this seem to be a 5 it signed integer but requires 6 bits to store this range. It should probably be -16 <= n <= 15.
nonnegative<8,-4> -256 < n < 256 in increments of 2^-4 = 1/16
I don't understand how a type nonnegative can store values in (-256,0).
negatable<16,-8> -65536 < n < 65536 in increments of 2^-8 = 1/ 256
This seems close to a fixed point type as I'm used to seeing it. Although again the ranges seem wrong.
I'm much more accustom to seeing fixed point number specified as
i.e. <16,8> instead of <16,-8>. Still this representation makes sense because it specifies both parameters in terms 2^x. It also supports something like <17,1> to give a 16 bit type that has the range [-131072, 131071] in increments of 2. Still it might be surprising to those familiar with the more common fixed-point notation.
Here is no mistake in the example. I paste here part of the C++1y proposal C++1y proposal wrote
Basic Types
The fixed-point library contains four class templates. They are cardinal and integral for integer arithmetic, and nonnegative and negatable for fractional arithmetic.
These types have a range specified by an integer. The range of an unsigned number n is 0 <= n < 2g where g is the range parameter. The range of an signed number n is 2g < n < 2g. Note that the range interval is half-open for unsigned numbers and open for signed numbers. For example, cardinal<8> has values n such that 0 <= n < 256 and integral<8> has values n such that -256 < n < 256.
The fractional types have a resolution specified by an integer. The resolution of a fractional number n is 2s, where s is the resolution parameter. For example, negatable<8,-4> has values n such that -256 < n < 256 in increments of 2-4 = 1/16.
Both range and resolution parameters may be either positive or negative. The number of significant bits is g-s. This specification enables representing both very small and very large values with few bits. In any event, the range must be greater than the resolution, that is g>s.
About the notation, what can I do for improve it and not break notation from the proposal? I will send new version of the proposal as soon as possible. P.S. Please, don't judge strictly my English, it really isn't very good. Sorry... I will try to write clearly and carefully. Sincerely, Dmitriy. -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-2013-tp4645089p4645863.html Sent from the Boost - Dev mailing list archive at Nabble.com.