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 notation) 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 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/dmitriy/1 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. Sincerely, Dmitriy. -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-2013-tp4645089p4646263.html Sent from the Boost - Dev mailing list archive at Nabble.com.