
Boost : 
Subject: Re: [boost] GSOC 2013
From: Dmitriy Gorbel (dmitriycpp_at_[hidden])
Date: 20130423 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
> fixedpoint 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 Marcin3 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
> fixedpoint 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 metaprogramming is not easy. Would you be more comfortable to
> implement a runtime 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.openstd.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 fixedpoint 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 fixedpoints numbers is
> usually bounded and limited to the machine word.
> The C++1y proposal arithmetic is open, and build fixedpoint 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 fixedpoint numbers use them for
> embedded systems, and they are requesting a closed arithmetic (see other
> fixedpoint threads on this ML) as no dynamic memory should be used by
> the fixedpoint 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 Marcin3 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 fixedpoint 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/GSOC2013tp4645089p4645894.html Sent from the Boost  Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk