Re: [boost] GSOC 2013

Subject: Re: [boost] GSOC 2013
From: Dmitriy Gorbel (dmitriycpp_at_[hidden])
Date: 2013-04-23 09:14:12

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.