Re: [boost] GSOC 2013

Subject: Re: [boost] GSOC 2013
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2013-04-23 00:46:20

>> 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.
> 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.

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.

>>
>> 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.
>
> Template meta-programming is not easy. Would you be more comfortable to
> implement a run-time solution before the static one?

This would certainly be a deal breaker for most (all?) embedded use cases.

>> User can create new variable and set any capacity. I think it is enough.
> 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.

Yep that would include me and my use cases.