Show me the numbers

>This is something I had tough to consider, but you're right, at high SNR
>computations errors may have some impact!

I meant "I hadn't tough to consider"
---------------------------------------
Posted through http://www.DSPRelated.com

Cedron <103185@DSPRelated> wrote:

>They seem to indicate that there is a precision limitation when using the
>double data type for DFT calculations somewhere approaching 200 bins. 
>This was unexpected to me.

Easily could be.  You can try to use the "double double" type in C++.
Or apply normalizing within internal stages of the DFT (easiest
to do this in an FFT, actually).


S.

spope33@speedymail.org (Steve Pope) writes:

> Cedron <103185@DSPRelated> wrote:
>
>>They seem to indicate that there is a precision limitation when using the
>>double data type for DFT calculations somewhere approaching 200 bins. 
>>This was unexpected to me.
>
> Easily could be.  You can try to use the "double double" type in C++.
> Or apply normalizing within internal stages of the DFT (easiest
> to do this in an FFT, actually).

Or, if one is motivated, one could also try using the Gnu
Multi-Precision (GMP) library, which allows you to extend to arbitrary
precision.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

Cedron wrote:

> Honestly, my derivations are not that complicated.  

I followed your entire derivation.  It is not that
complicated.  The method by which you separated factors
that depend on bin number but not on alpha, from factors dependent
on alpha is nice.

I think a person who is very facile with the entire universe
of trig identities may be able to compose a briefer derivation,
but that person isn't me.

A couple times you use the word "adjust" when you meant a
substitution.  To some people the term "adjust" might connote that
you're introducing an approximation, when you are not.  
I would drop the term.

I also think that comments like "this equation is not particularl
useful", when in fact it's a necessary part of the derivation,
are also misleading.  

Also the equations by which you define R1 are written back
to front.  (That one is minor perhaps.)

Steve

>Cedron wrote:
>
>> Honestly, my derivations are not that complicated.  
>
>I followed your entire derivation.  It is not that
>complicated.  The method by which you separated factors
>that depend on bin number but not on alpha, from factors dependent
>on alpha is nice.

Thank you.

>
>I think a person who is very facile with the entire universe
>of trig identities may be able to compose a briefer derivation,
>but that person isn't me.
>

If you stack (773-9,8, and 10) in matrix form, then multiply by the W
vector, the derivation becomes greatly simplified, but it begs the
question: "How did you know how to define W?"

To extend the equation to a larger number of bins build the stack as high
as you like, then construct a W that zeroes the right hand side.

>A couple times you use the word "adjust" when you meant a
>substitution.  To some people the term "adjust" might connote that
>you're introducing an approximation, when you are not.  
>I would drop the term.
>
Excellent suggestion, will do.

>I also think that comments like "this equation is not particularl
>useful", when in fact it's a necessary part of the derivation,
>are also misleading.  

Agreed.  What I really meant was "utilitarian".  Thanks.

>
>Also the equations by which you define R1 are written back
>to front.  (That one is minor perhaps.)

Not sure what you mean by this.  Could you elaborate?

>
>Steve

Thanks for the feedback, it's very much appreciated.

Ced
---------------------------------------
Posted through http://www.DSPRelated.com

Cedron <103185@DSPRelated> wrote:

>>Also the equations by which you define R1 are written back
>>to front.  (That one is minor perhaps.)

>Not sure what you mean by this.  Could you elaborate?

773-11 and -12 are definitional of R1.

This could be introduced by

"Let R1 = exp(-i * beta[n])".

followed by the substitutions.

This is no big deal, lots of authors do similar things 


Steve

On Saturday, May 30, 2015 at 7:45:35 AM UTC-7, Cedron wrote:
> [...snip...]
> 
> >There really
> >is little place for "exact solutions" in DSP applications. Perhaps a
> >symbolic math group could be more interested. More of interest in DSP
> applications
> >are the details of implementation cost and the effects of noise and
> >interference. 
> 
> Don't you think it's good when practice rests on solid theory?

'Solid" in engineering is based on relevance to the use case, not on the symbology of the theory.

...
> >
> >How can the other algorithms be so different when, as you say, they
> >approximate yours?
> 
> Are not 'x' and 'sin( x )' quite different?  Yet the former approximates
> the latter in the neighborhood of zero quite well.

If they approximate well then they are the same regardless of the symbology. This is a point you have made about other trig function representations of your derivation. It applies here too.

> 
> This is not an inapplicable example.  It is one of the approximation used
> several times when you derive Jacobsen's estimator from my equation.

The results show that this is a good example that it is the values in the region of interest that are important, not differences in symbology.


...
> >
> >So far, not everyone who can understand typical DSP literature agrees
> with
> >your content.
> >
> >Dale B. Dalrymple
> 
> So far, but at least now people seem to be looking at it more closely. 
> I'm not sure what you mean by agreement.  It's hard to argue with the math
> itself.  How I describe it, or how useful it is, are different matters.

I was referring to your strange remarks about sincs and windows. 

> 
> Thanks for your input.
> 
> Ced

Dale B. Dalrymple

[...snip...]
>
>it wasn't just the "n" vs. "k" or the X_n vs. X[k] notation that 
>bothered me.  i thought that the math was much thicker than it needed to
>be.

I'm sorry about the "n" vs. "k", although legitimate it is not
conventional.  Since it is my intent to communicate clearly, making the
change is justified.

X_n is a sequence, X[n] is a function.  Since we are dealing with the
discrete case I think sequence notation is much more appropriate.  I pick
up where the dirac delta choo-choo leaves off, that is at the discrete
summation definition of the DFT, not the limit of the continuous FT
applied to the impulse train.  I like using Z instead of X, I think it is
clearer and conventionally stands for complex values.  "X and x" are more
ambiguous when reading than "Z and S", especially with old fart status and
reading glasses.

I'm not sure what you mean by "thicker than it needed to be".  Does that
mean you would like to see more intermediary steps?  I can't reduce the
complexity any, the math is what it is, I'm just describing it.  

>
>i also think that the theoretical usefulness is limited because you're 
>considering only the rectangular window with the block of samples going 
>into the DFT.

The same derivation for the bin value formulas can be made including a
window function.  It will add some terms to the gooblygook, but it should
be doable.  I haven't done it because I don't think window functions
really add any value.  Julien may have changed my mind on that about the
Gaussian window, but the results weren't as good as promised (not by him,
by the article he referenced).

Whether the resulting bin value functions (with window function included)
are as readily invertible, I simply don't know.  You are welcome to try
it.  

>
>-- 
>
>r b-j                  rbj@audioimagination.com
>
>"Imagination is more important than knowledge."

Thanks for you input.

Ced
---------------------------------------
Posted through http://www.DSPRelated.com

On Saturday, May 30, 2015 at 4:54:59 AM UTC-7, Randy Yates wrote:
...
>  How do you classify an
> algorithm that gives you "exact" results when no noise is present and a
> good estimate when it is? 
...
> Randy Yates
> Digital Signal Labs
> http://www.digitalsignallabs.com

"Robust" comes to mind.

Dale B. Dalrymple

>Cedron <103185@DSPRelated> wrote:
>
>>>Also the equations by which you define R1 are written back
>>>to front.  (That one is minor perhaps.)
>
>>Not sure what you mean by this.  Could you elaborate?
>
>773-11 and -12 are definitional of R1.
>
>This could be introduced by
>
>"Let R1 = exp(-i * beta[n])".
>
>followed by the substitutions.
>
>This is no big deal, lots of authors do similar things 
>
>
>Steve

Thanks, Steve.

R_n is defined in (773-4).  I suppose a specific R_1 like you suggested
would be useful nearer its usage.  I don't want to change the equation
numbering now so I will adjust the text to refer to (4).

Ced
---------------------------------------
Posted through http://www.DSPRelated.com