Vicente Botet wrote
This is not on your proposal. What would be the result type of these operations? Do you know efficient algorithms for these operations for fixed-point numbers? Do you think you will have enough time. Could you categorize the features of your library with MUST/SHOULD/COULD so that we have an idea of the priorities.
Michael Marcin-3 wrote
The trig functions are difficult to implement generically in my experience. Most of the fixed point implementations rely on lookup tables with CORDIC algorithms. The lookup tables would have to be calculated with metaprogramming when you allow for essentially arbitrary fixed-point layouts.
Some functions(like modf, floor, fabs) really aren't difficult to implement. But some functions aren't easy to implement. I need some time to explore the algorithms and make the design. I know that MacLaurin series can be used in trig functions. I don't familiar with CORDIC algorithms yet, I just need some time. List of functions: ceil, floor, sqrt, sin, cos, exp, fabs, fmod, modf, exp. I think all of this functions must be implemented. I open to discuss this list, we can add more functions and then rate them by priority. Vicente Botet wrote
Template meta-programming is not easy. Would you be more comfortable to implement a run-time solution before the static one?
Sorry, but maybe I understood you wrong. I should implement library without templates, and then with templates? Why? I think it's not necessary. Or you suggest me refuse from the templates? Vicente Botet wrote
Humm, I'm not sure this is undefined behavior. Could you point me where in the standard you have find this?
I refer to working draft of the Standard, ok? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf Working Draft, Standard for Programming Language C++, page 98 wrote
As with any other arithmetic overflow, if the result does not fit in the space provided, the behavior is undefined.
Vicente Botet wrote
Are you aware of the limitations of the C++11 proposal? Could you answer this question independently of embedded systems?
Vicente Botet wrote
Great. Does it means that you could explore some of the limitations of the C++1y proposal and try to solve some of them?
We discuss all limitations and problems here :) I will try to solve limitations, as many as possible. Main issue independently of embedded systems - make the notation friendly for most users. Main issue - make the library useful for embedded systems. Vicente Botet wrote
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. Humm, this argument doesn't convince me. At least for fixed-point with no more precision than the word machine. I would expect in these cases code close to integer arithmetic which would not increase the program size.
I was thinking much more on the precision of the fixed point numbers. In embedded systems the precission of the fixed-points numbers is usually bounded and limited to the machine word. The C++1y proposal arithmetic is open, and build fixed-point types that can be bigger and bigger. How the user of an embedded system can manage with this explotion? Should the library provide closed arithmetic for these cases so that T+T->T ?
Yes, this is necessary feature, especially for embedded systems. Library must provide closed arithmetic for these cases. I saw that's implemented in your library. I will focus in this issue. Vicente Botet wrote
I don't see any major reason to don't use templates and namespaces in such systems. Do you?
I hope the library will be useful for embedded systems - it's main goal. Vicente Botet wrote
IMO, a lot off the people interested in fixed-point numbers use them for embedded systems, and they are requesting a closed arithmetic (see other fixed-point threads on this ML) as no dynamic memory should be used by the fixed-point numbers, so the precision must be bounded. I don't think they will accept a fixed point library that don't allows them to work with closed arithmetic.
Michael Marcin-3 wrote
Yep that would include me and my use cases.
I think I must implement both cases, where user can choose closed arithmetic, when precision must be bounded, or opened arithmetic when range must be extended. I will work with this problem closer. 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. Does this mean that the library must evolve when a user request a different kind of rounding?
Yes. 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? I agree the notation is clear (at least for me). There are however other users that use to use other notations. If the library doesn't provide a solution to this notational problem, they will either noyt use your library or try to make use change of notation. How to manage with this problem?
I think I must provide two(or more?) notations. User should choose from them. Vicente Botet wrote
Humm, starting from zero could help you to understand the basics of the problem domain. But I don't think you will have enough time to finish the library by the end of the summer. If you pas 3/4 of your time to go until the current state of my prototype the boost community will not get a major improvements to the fixed-point library at the end of the summer. Note that starting from my prototype is not a MUST of the proposal and would be ready to mentor it even if you start from zero IF I'm confident you would be able to do it. What do you think?
I anyway will use your prototype. I will try to prove that I'm worthy to develop the library. *Summary* I understood that library must be useful for embedded systems. It's important. Also library must be customizable. User can choose a notation, closed or opened arithmetic, and a rounding policies. Here is a lot of work :) Thanks for your feedback. Sincerely, Dmitriy. -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-2013-tp4645089p4645894.html Sent from the Boost - Dev mailing list archive at Nabble.com.