Hi Henryk,
the pow() function is the only reason for linking with -lm and it is
only used in one place with a limit range of parameters.
scalefactor[ch][sb] = pow(2.0, (frame->scale_factor[ch][sb] + 1));
So what is the range of scale_factor[ch][sb]. From a quick testing a saw
that it ranges from 0 - 15. Is this always true? If yes, then I would
use a pre-calculated array for 2^x.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel
> we don't need -lm anymore, but there is still the math.h include and
> this is because of the fabs() function. Any ideas?
the abs functions are usually done with a macro
#define fabs(x) ((x)<0?(-x):(x))
but we could define our own similar macro if you want to stop using math.h
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Brad,
> that's a good idea to break the need for libm and for another
> int->float->int conversion
we don't need -lm anymore, but there is still the math.h include and
this is because of the fabs() function. Any ideas?
> > scalefactor[ch][sb] = pow(2.0, (frame->scale_factor[ch][sb] + 1));
> >
> > So what is the range of scale_factor[ch][sb]. From a quick testing a saw
> > that it ranges from 0 - 15. Is this always true? If yes, then I would
> > use a pre-calculated array for 2^x.
>
> or like
>
> scalefactor[ch][sb] = 4 << frame->scale_factor[ch][sb];
>
> the compiler doesn't know about the limited range of scale_factor so it
> may actually generate a loop here.
It must be
scalefactor[ch][sb] = 2 << frame->scale_factor[ch][sb];
However bitshifting is the right way to solve this and I don't see any
problems for the compiler. We shift the integer value 2.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Henryk,
> > the pow() function is the only reason for linking with -lm and it is
> > only used in one place with a limit range of parameters.
>
> Oh yes, that occurence of pow(2.0, x) is in older code I forgot about.
> (And before -lm was necessary for cos(), too)
>
> > So what is the range of scale_factor[ch][sb]. From a quick testing a
> > saw that it ranges from 0 - 15. Is this always true?
>
> Yes, scale_factor is a 4 bit integer (Table 12.13 of A2DP) and there
> should be no way of getting it bigger. If there was this would be a bug.
>
> > If yes, then I would use a pre-calculated array for 2^x.
>
> Isn't 1<<x good enough for that?
stupid me. Of course power of two is done by bitshifting. I committed
the following to the CVS:
2 << frame->scale_factor[ch][sb]
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
guys
that's a good idea to break the need for libm and for another
int->float->int conversion
> scalefactor[ch][sb] = pow(2.0, (frame->scale_factor[ch][sb] + 1));
>
> So what is the range of scale_factor[ch][sb]. From a quick testing a saw
> that it ranges from 0 - 15. Is this always true? If yes, then I would
> use a pre-calculated array for 2^x.
or like
scalefactor[ch][sb] = 4 << frame->scale_factor[ch][sb];
the compiler doesn't know about the limited range of scale_factor so it
may actually generate a loop here.
brad
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Moin,
Am Sun, 28 Nov 2004 00:51:46 +0100 schrieb Marcel Holtmann:
> the pow() function is the only reason for linking with -lm and it is
> only used in one place with a limit range of parameters.
Oh yes, that occurence of pow(2.0, x) is in older code I forgot about.
(And before -lm was necessary for cos(), too)
> So what is the range of scale_factor[ch][sb]. From a quick testing a
> saw that it ranges from 0 - 15. Is this always true?
Yes, scale_factor is a 4 bit integer (Table 12.13 of A2DP) and there
should be no way of getting it bigger. If there was this would be a bug.
> If yes, then I would use a pre-calculated array for 2^x.
Isn't 1<<x good enough for that?
--
Henryk Pl?tz
Gr??e aus Berlin
~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~
~ Help Microsoft fight software piracy: Give Linux to a friend today! ~