headers
John C. Femiani | 1 Aug 01:15
Picon
Favicon

Re: fixed pt binary lib

Neal Becker wrote:
> I have the beginning of a fixed-pt binary lib.  Fixed-pt is popular in DSP applications.  It is integer
arithmetic, but keeping track of the binary pt.
>
> It is built on top of constrained_value.
>
> It is small, so I include it here:
Thanks,
I am eagerly waiting for somebody to do something like this.
Why did you choose to base it on constrained values?  Couldn't I have 
used a bounded int as a base_type parameter, making your fixed_pt class 
not dependent on constrained_value anymore?

Also, do your implementations for /= and *= actually round? You actually 
seem to be using the round policy for conversions, is that right? Have 
you looked at the numeric/conversion stuff? (I haven't grokked it yet).

>   //self operator %=(base_type x) { val %= x; return *this; } What 
> should this do?
I think perhaps it should behave like fmod (?)
--Johhn

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 13 comments |
headers
Michael Caisse | 1 Aug 01:49

Re: [1.36.0 beta] Beta release available on SourceForge

Beman Dawes wrote:

> The beta period will be approximately one week. Please post bug reports 
> here, but also let us hear about success stories too!
>   
> --Beman
>   
>   
Great work to all those involved. Thank you!

Just to be clear. Should issue be reported "here" on the ML, in trac or both?

michael

--

-- 

----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Beman Dawes | 1 Aug 02:07
Picon
Favicon
Gravatar

Re: [1.36.0 beta] Beta release available on SourceForge

Michael Caisse wrote:
> Beman Dawes wrote:
> 
>> The beta period will be approximately one week. Please post bug 
>> reports here, but also let us hear about success stories too!
>>   --Beman
>>     
> Great work to all those involved. Thank you!
> 
> Just to be clear. Should issue be reported "here" on the ML, in trac or 
> both?

Please report all issues to the mailing list, but if an issue is 
complex, accompanied by a patch file, or something likely to be deferred 
until the next release then also add a trac issue.

Thanks,

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Michael Marcin | 1 Aug 02:44
Picon

Re: fixed pt binary lib

John C. Femiani wrote:
> Neal Becker wrote:
> 
>>   //self operator %=(base_type x) { val %= x; return *this; } What 
>> should this do?
> I think perhaps it should behave like fmod (?)
> 
> 

I had a fixed-point library with the purpose that code written should be 
able to choose to use fixed-point or floating point math at compile time 
without having to rewrite the algorithms.

Instead of providing a % operator I provided an fmod function for parity 
with floating point types.

/// Computes the remainder of fixed-point division
/// @param x The numerator.
/// @param y The divisor.
/// @return  the value x - i * y, for some integer i such that, if y is
///          non-zero, the result has the same sign as x and magnitude
///          less than the magnitude of y.
template<std::size_t M, std::size_t F> inline
fixed<M,F> fmod( fixed<M,F> x, fixed<M,F> y )
{
    return as_fixed(x.raw() % y.raw());
}

/// shorthand for fmod( fixed, integer )
template<std::size_t M, std::size_t F, typename T > inline
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anthony Williams | 1 Aug 08:47
Picon

Re: 1.36 thread library

"vicente.botet" <vicente.botet <at> wanadoo.fr> writes:

> It should be great if the Thread library documentation included a
> History section and include the changes since 1.35 that we can already
> found in the Version 1.36.0 page
> (http://beta.boost.org/users/news/version_1_36_0)

Good idea.

> The  create_thread interface evolution is not present in the doc.
> Replace
>  thread* create_thread(const function0<void>& threadfunc);
> by
>  template<typename F> thread* create_thread(F threadfunc);

Oops.

> BTW, as you have enhanced the interface for the thread construction
>
>    template <class F,class A1,..., class An> thread(F f,A1 a1,..., An an);
>
> why not to apply the same schema to the create_thread function of the
> thread_group class?

There's a trac issue for that. I haven't got round to it yet.

> Just one minor sugestion: The guard on the create_thread function
> should be declared after the thread creation to limit the scope of the
> mutex lock.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Anthony Williams | 1 Aug 08:54
Picon

Re: fixed pt binary lib

"John C. Femiani" <john.femiani <at> asu.edu> writes:

> Neal Becker wrote:

>> I have the beginning of a fixed-pt binary lib.  Fixed-pt is popular
>> in DSP applications.  It is integer arithmetic, but keeping track
>> of the binary pt.

> Also, do your implementations for /= and *= actually round? You
> actually seem to be using the round policy for conversions, is that
> right? Have you looked at the numeric/conversion stuff? (I haven't
> grokked it yet).

The division throws away the lower "frac_bits" of the result:

  self operator/=(self const& x) { 
    base_type tmp = (base_type)val / (base_type)x.val;
    val = tmp << (frac_bits);
    return *this; }

I published a more fully-fledged fixed point type here a few months
ago. You can get it from my website (along with a link to the DDJ
article where I describe how it works):

http://www.justsoftwaresolutions.co.uk/news/optimizing-applications-with-fixed-point-arithmetic.html

It has a fixed number if integer and fractional bits (35.28). However,
this allows it to support sin, cos, exp and log by using lookup tables.

Anthony
(Continue reading)

Permalink | Reply | 11 comments |
headers
Daniel Frey | 1 Aug 09:21
Picon
Picon

Re: fixed pt binary lib

On Thu, 2008-07-31 at 14:20 -0500, Michael Marcin wrote:
> Daniel Frey wrote:
> > On Thu, 2008-07-31 at 12:16 -0500, Michael Marcin wrote:
> >>
> >> Be sure to check the size of your type with your compiler. Some embedded 
> >> and DSP compilers in the past made types that derive from operators 
> >> larger. Although I think that was partially due to a operators bug that 
> >> was fixed a long time ago.
> > 
> > AFAIK that's not a bug in the operators library, but an inefficiency in
> > the compiler's ABI (the EBO actually, which misses some optimization
> > opportunities for multiply inheritance from empty base classes).
> 
> I was referring to http://svn.boost.org/trac/boost/ticket/979 which bit 
> me on a project where we had a fixed-point 3 coordinate vector which had 
> operators which contained a fixed-point types which had operators.

That won't help in Neal's code unless he starts using the base class
chaining. Since empty_base only takes T into account (not U if
available), Neal's code would still contain the same base class (empty<
fixed_pt<int_bits,frac_bits,base_type,error_policy,round_policy> >)
multiple times, which might lead to some bloat.

Regards, Daniel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
John C. Femiani | 1 Aug 10:04
Picon
Favicon

Re: fixed pt binary lib

Anthony Williams wrote:
> "John C. Femiani" <john.femiani <at> asu.edu> writes:
>   
>> Also, do your implementations for /= and *= actually round? You
>> actually seem to be using the round policy for conversions, is that
>> right? Have you looked at the numeric/conversion stuff? (I haven't
>> grokked it yet).
>>     
>
> The division throws away the lower "frac_bits" of the result:
So why doesn't it use the rounding policy? I kind of expect it to be 
used anytime quantization occurs.

--John
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 3 comments |
headers
Matt Gruenke | 1 Aug 10:21

Re: fixed pt binary lib

Anthony Williams wrote:
> "John C. Femiani" <john.femiani <at> asu.edu> writes:
>   

>> Also, do your implementations for /= and *= actually round? You
>> actually seem to be using the round policy for conversions, is that
>> right? Have you looked at the numeric/conversion stuff? (I haven't
>> grokked it yet).
>>     
>
> The division throws away the lower "frac_bits" of the result:
>   

Speaking of division, while I'd expect /= to return the same type as the 
LHS operand, the way I've previously implemented fixed point division is 
to return:
    result_int_bits = (numer_int_bits + denom_frac_bits + 1)
    result_frac_bits = (numer_frac_bits + denom_int_bits - 1)

It's a little easier to understand the rationale, if you separately 
consider 1/x and x * y.  For 1/x, returning the following avoids 
overflow and is reversible (if the result happens to be exact):
    result_int_bits = input_frac_bits + 1
    result_frac_bits = denom_int_bits -1

The result of x * y is obviously:
    result_int_bits = x_int_bits + y_int_bits
    result_frac_bits = x_frac_bits + y_frac_bits

Then, x/y is simply viewed as multiplication by the inverse of y, but
(Continue reading)

Permalink | Reply | 6 comments |
headers
Anthony Williams | 1 Aug 10:52
Picon

Re: fixed pt binary lib

"John C. Femiani" <john.femiani <at> asu.edu> writes:

> Anthony Williams wrote:
>> "John C. Femiani" <john.femiani <at> asu.edu> writes:
>>   
>>> Also, do your implementations for /= and *= actually round? You
>>> actually seem to be using the round policy for conversions, is that
>>> right? Have you looked at the numeric/conversion stuff? (I haven't
>>> grokked it yet).
>>>     
>>
>> The division throws away the lower "frac_bits" of the result:
> So why doesn't it use the rounding policy? I kind of expect it to be
> used anytime quantization occurs.

I'll leave Neal to answer that (it's his code), but getting division
right is a pain.  If you followed the link to my code, you'll see that
correct division is not trivial.

Anthony
--

-- 
Anthony Williams            | Just Software Solutions Ltd
Custom Software Development | http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 2 comments |

Gmane