```On Mon, 24 Aug 2009 04:33:19 -0700 (PDT), Rune Allnor
<allnor@tele.ntnu.no> wrote:

>On 24 Aug, 13:16, "mahsad" <mahdi_...@yahoo.com> wrote:
>> Hello,
>> I am implementing DTMF detection using Goertzel Algorithm
>> this is my program on C54x;
>...
>> but this program doesn't detect freguency more than
>> 697 Hz,only 697 Hz & 1209 Hz can be detect.
>> why this happen.my Goertzel Algorithm is correct
>> but result doesn't correct!
>
>First of all, I hate reading other people's code.
>Never post that much code unless it's absolutely necessary
>(which means that somebody asked to see it).

You may not like it, but others that are trying to implement similar
functionality, or just starting out, probably would appreciate it
(even if it's not working).  It wasn't 'that much' code anyhow,
although all that test data probably wasn't needed.

```
```On Aug 25, 1:00&#2013266080;pm, "Christen Fihl"
<look_at_HSPascal.fihl....@nospam.plz> wrote:
> > For most embedded work, especially with fixed point, 355/113 is plenty
> > good. Note that 1/pi becomes 113/355, a doubled arithmetic sequence, easy
> > to remember. Pi*113/355 = 0.999999915
>
> And more precision by using (and still easy to remember) is 35500001 /
> 11300001
> In reverse it gives: 0,999999975, much better :-)
>
> Christen

But you are using 16 digits to get just 8!
```
```> For most embedded work, especially with fixed point, 355/113 is plenty
> good. Note that 1/pi becomes 113/355, a doubled arithmetic sequence, easy
> to remember. Pi*113/355 = 0.999999915

And more precision by using (and still easy to remember) is 35500001 /
11300001
In reverse it gives: 0,999999975, much better :-)

Christen

```
```>from my local install of MinGW:
>
>/MinGW/include/math.h:58:#define M_PI           3.14159265358979323846
>/MinGW/include/math.h:59:#define M_PI_2         1.57079632679489661923
>/MinGW/include/math.h:60:#define M_PI_4         0.78539816339744830962
>
>I will bet it's there more often than not, standard or no. There is -
>as you've noted - a defacto standard that preceded the ANSII
>interpretation.

Look again. Those defines are ifdef'd out unless you specifically enable
them. Most C compilers are like that now, because those things are
obviously sane, but some numbskull took them out of the standards.

Steve

```
```Randy Yates wrote:
> Les Cargill <lcargill@cfl.rr.com> writes:
>
>> Randy Yates wrote:
>>> Richard Dobson <richarddobson@blueyonder.co.uk> writes:
>>>
>>>> Randy Yates wrote:
>>>> ..
>>>>>>>  Omega=(2*3.1459*k)/N;
>>>>>> If you want PI, try use 3.14159
>>>>> Ha! Nice find, Christen!
>>>> That surprises me - perhaps that compiler does not define M_PI or the
>>>> equivalent? Odd in a compiler for a dsp. The whole reason for such
>>>> symbols after all is to avoid exactly that kind of typo.
>>> There may be a Boost library for this, but it's not in either the C++ or
>>>
>>> I think it ought to be a part of the standard for all C/C++
>>> implementations, not just DSPs.
>>
>> You can always have
>>
>> const double _PI = atan(1.0)*4.0;
>>
>> somewhere in the soup.
>
> That still requires the programmer to write code, and errors can be
> introduced in the process of writing code (yes, as simple as that is -
> the original definition wasn't all that complex either!), as Richard has
>
> It would be better to have these constants predefined in the standard.

Failing that, one could write a definitions file to be included by
reference.

Jerry
--
Engineering is the art of making what you want from things you can get.
&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
```
```Les Cargill wrote:
> Randy Yates wrote:
>> Richard Dobson <richarddobson@blueyonder.co.uk> writes:
>>
>>> Randy Yates wrote:
>>> ..
>>>>>>  Omega=(2*3.1459*k)/N;
>>>>> If you want PI, try use 3.14159
>>>> Ha! Nice find, Christen!
>>> That surprises me - perhaps that compiler does not define M_PI or the
>>> equivalent? Odd in a compiler for a dsp. The whole reason for such
>>> symbols after all is to avoid exactly that kind of typo.
>>
>> There may be a Boost library for this, but it's not in either the C++ or
>>
>> I think it ought to be a part of the standard for all C/C++
>> implementations, not just DSPs.
>
>
> You can always have
>
> const double _PI = atan(1.0)*4.0;
>
> somewhere in the soup.

For most embedded work, especially with fixed point, 355/113 is plenty
good. Note that 1/pi becomes 113/355, a doubled arithmetic sequence,
easy to remember. Pi*113/355 = 0.999999915

Jerry
--
Engineering is the art of making what you want from things you can get.
&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;&#2013266095;
```
```Les Cargill wrote:
..
>
> from my local install of MinGW:
>
> /MinGW/include/math.h:58:#define M_PI           3.14159265358979323846
> /MinGW/include/math.h:59:#define M_PI_2         1.57079632679489661923
> /MinGW/include/math.h:60:#define M_PI_4         0.78539816339744830962
>
> I will bet it's there more often than not, standard or no. There is -
> as you've noted - a defacto standard that preceded the ANSII
> interpretation.
>
> As to why standards committees do stuff like that... I don't know
> why any more than you do.

M_PI etc are not part of ANSI C(nor even C99 for that matter); but those
defs have been part of unix math.h for ever. Visual C++ is one of the
compilers that does  not support it; but all gcc compilers do. gcc is of
course its own "standard'.

The atan(1) route is good (assuming the atan routine is good); but
unless the optimizer is ~really~ pulling its weight, the result is still
kept in a memory address somewhere (in case someone needs its address),
rather than written as an inline constant value in the assembler. If
people are trying to save cycles, maybe even that matters (I suppose...).

Richard Dobson
```
```Rune Allnor wrote:
> On 25 Aug, 12:58, Les Cargill <lcarg...@cfl.rr.com> wrote:
>> Randy Yates wrote:
>
>>> That still requires the programmer to write code,
>> Ah, we can't have that! :)
>
> The fact remains that code that is never written is both
> faster and safer than code that somebody have to write and
> test,

But you still must test it.

> the compiler has to digest,

This still occurs....

> and the program has to
> execute.
>

...as does this...

I am not trying to be difficult - but waving
hands at vendor code ....

> Of course, a computational constant like pi has to be
> inserted in there somewhere, but as a guiding principle,
> the less the coder has to do (and get right), the better.
>

The delta of effort from that one, identity-based relationship
is almost nil. And ... you still have to test it :)

TAANSTAFL. And trust no-one.

I just wish you could have been there when we identified a
non-reentrancy in the C++ STL map code which cratered a rather
complex product. When the author was shown this, he said "but
I shouldn't have to test that."

The target was no less dead....

> Rune

--
Les Cargill
```
```On 25 Aug, 12:58, Les Cargill <lcarg...@cfl.rr.com> wrote:
> Randy Yates wrote:

> > That still requires the programmer to write code,
>
> Ah, we can't have that! :)

The fact remains that code that is never written is both
faster and safer than code that somebody have to write and
test, the compiler has to digest, and the program has to
execute.

Of course, a computational constant like pi has to be
inserted in there somewhere, but as a guiding principle,
the less the coder has to do (and get right), the better.

Rune
```
```Randy Yates wrote:
> Les Cargill <lcargill@cfl.rr.com> writes:
>
>> Randy Yates wrote:
>>> Richard Dobson <richarddobson@blueyonder.co.uk> writes:
>>>
>>>> Randy Yates wrote:
>>>> ..
>>>>>>>  Omega=(2*3.1459*k)/N;
>>>>>> If you want PI, try use 3.14159
>>>>> Ha! Nice find, Christen!
>>>> That surprises me - perhaps that compiler does not define M_PI or the
>>>> equivalent? Odd in a compiler for a dsp. The whole reason for such
>>>> symbols after all is to avoid exactly that kind of typo.
>>> There may be a Boost library for this, but it's not in either the C++ or
>>>
>>> I think it ought to be a part of the standard for all C/C++
>>> implementations, not just DSPs.
>>
>> You can always have
>>
>> const double _PI = atan(1.0)*4.0;
>>
>> somewhere in the soup.
>
> That still requires the programmer to write code,

Ah, we can't have that! :)

> and errors can be
> introduced in the process of writing code (yes, as simple as that is -
> the original definition wasn't all that complex either!), as Richard has
>

Yes, but you still have to vet the value in testing anyway. And I am
in no way convinced the #define version is inherently better.

I am simply trying to show the difference between one philosophy -
that it should be there - and my philosophy - it's not there? Make
something up.

I just don't hold that some object that came out of the tarball
from the vendor is any more privileged than anything else - I've
had to go fix too many nonreentrant library functions, outright
buggy libraries and other joys. I've spent far too many weekends
with FPGA designers being... abused by tools vendors, found
too many *really, really stupid* defects from stack libraries
written by poor huddled masses of H1B "slaves" who had no real
means of testing their work...

The buck stops here.

> It would be better to have these constants predefined in the standard.

from my local install of MinGW:

/MinGW/include/math.h:58:#define M_PI           3.14159265358979323846
/MinGW/include/math.h:59:#define M_PI_2         1.57079632679489661923
/MinGW/include/math.h:60:#define M_PI_4         0.78539816339744830962

I will bet it's there more often than not, standard or no. There is -
as you've noted - a defacto standard that preceded the ANSII
interpretation.

As to why standards committees do stuff like that... I don't know
why any more than you do.

--
Les Cargill
```