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 >> C standards. I asked about this very thing several months ago. >> >> 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 already pointed out. It would be better to have these constants predefined in the standard. -- Randy Yates % "I met someone who looks alot like you, Digital Signal Labs % she does the things you do, mailto://yates@ieee.org % but she is an IBM." http://www.digitalsignallabs.com % 'Yours Truly, 2095', *Time*, ELO
Goertzel Algorithm
Started by ●August 24, 2009
Reply by ●August 25, 20092009-08-25
Reply by ●August 25, 20092009-08-25
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 >>> C standards. I asked about this very thing several months ago. >>> >>> 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 > already pointed out. >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
Reply by ●August 25, 20092009-08-25
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
Reply by ●August 25, 20092009-08-25
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
Reply by ●August 25, 20092009-08-25
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
Reply by ●August 25, 20092009-08-25
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 >> C standards. I asked about this very thing several months ago. >> >> 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. �����������������������������������������������������������������������
Reply by ●August 25, 20092009-08-25
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 >>> C standards. I asked about this very thing several months ago. >>> >>> 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 > already pointed out. > > 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. �����������������������������������������������������������������������
Reply by ●August 25, 20092009-08-25
>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
Reply by ●August 25, 20092009-08-25
> 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.999999915And more precision by using (and still easy to remember) is 35500001 / 11300001 In reverse it gives: 0,999999975, much better :-) Christen
Reply by ●August 25, 20092009-08-25
On Aug 25, 1:00�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 :-) > > ChristenBut you are using 16 digits to get just 8!
