pulsewidth and bandwidth
in [DSP]
|
Prev: Floating point DSPs
Next: MATLAB indexing issue
From: dvsarwate on 16 Jul 2010 13:30 In this thread, Robert Bristow-Johnson wrote rb-j > > but it *did* differ by such a factor, no? what is the difference rb-j > > between these two lines: > > > > > dw = sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); > > > > > df = 2*pi*sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); to which I responded that dvs > > Well, if w.^2 were the same as f.^2, then the two lines dvs > > would give numbers differing by the "spurious factor" dvs > > 2*pi, and indeed, less mathwork (pun intended) would be dvs > > required if Jitendra had simply written df = 2*pi*dw. Jitendra Riyala then clarified jr > > The 2*pi is meant to show that the dw and df are also related to each jr > > other by the factor 2*pi (dw=2*pi*df) similar to w=2*pi*f. Nothing jr > > more. which does not really answer the question. There are two similar but slightly different computations going on, namely sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); The first gives dw and then the second number is multiplied by 2*pi to get df. But if dw = 2*pi*df, then is it really necessary to compute one more time the sums and the square roots and so on? Why not simply write df = dw/(2*pi) thereby saving a lot of machine cycles from an untimely death? In fact, with w = 2*pi*f, my uneducated unMATLABian guess is that sum(w.^2.*gf.^2) is (2*pi)^2 times sum(f.^2.*gf.^2), and so upon taking square roots, dw = sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))) is (2*pi) times sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))). Thus, multiplying sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2)))by 2*pi makes df = dw as I noted (and complained about) in the output produced by Jitendra's program. Jitendra also writes jr > > I occasionally visit comp.dsp and I see much negative view of Matlab jr > > which I find bit surprising. It's just a tool. Isn't it the the jr > > user's responsibility to check what they provide and what comes out? Yes indeed, and the negative view of MATLAB is because of the tendency of some (and especially new posters and students) to confuse between MATLAB and reality. If MATLAB gives some answer, then that is the right answer. And if you will forgive me for saying so, Jitendra, you too have fallen into the trap of accepting unquestioningly what MATLAB gives you since your program gave dw and df the same value sqrt(2), and you posted this result to comp.dsp without checking if it made any sense. --Dilip Sarwate
From: robert bristow-johnson on 16 Jul 2010 14:48 On Jul 16, 12:04 pm, Jitendra Rayala <jray...(a)hotmail.com> wrote: > On Jul 16, 4:52 am, dvsarwate <dvsarw...(a)gmail.com> wrote: > .... > > and I don't understand MATLAB, and so > > cannot figure out what is going on. All I am going by > > is the claim that df and dw happen to have the same > > value sqrt(2) which puzzles me. and it has *nothing to do with MATLAB. .... f = fs*[-(L-1)/2:L/2]/L; w = 2*pi*f; .... df = sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); dw = sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); .... given this, if gf is the same in both equations, dw has no choice other than to be 2*pi*df, as it should be. one is radians per unit time and the other is cycles per unit time. i don't know why Jitendra chose to put 2*pi in his df computation (and i'm not worried about it), but that is the only source to the confusion Dilip had regarding dw and df being the same when they shouldn't have been. > > The great god MATLAB has spoken, but I am a non-believer.... > > I occasionally visit comp.dsp and I see much negative view of Matlab > which I find bit surprising. It's just a tool. Isn't it the the > user's responsibility to check what they provide and what comes out? > If somebody does not like it, they can use some other tool if > available or may be start a company and develop another tool? i am not a MATLAB proponent nor detractor in general (i used it a lot earlier, now i sometimes use Octave because i am too cheap to buy MATLAB for a current computer), but i consider it inexcusable that the indexing scheme they have (where all arrays *must* have index origin of 1) is so inflexible, because even if sometimes having origin 1 is "right" (that is, congruent to what is common in the literature for some application), sometimes it is wrong (say for the FFT). a sophisticated and supposedly flexible language that purports to allow one to write equations just as they are on paper is lacking something quite fundamental when it does not accommodate negative or zero indices. i also think that this, combined with their ordering convention for polyval() and polyfit() is wrong. there are some other more minor kludges in MATLAB, but i am not worried about it. r b-j
From: Greg Heath on 16 Jul 2010 23:13 On Jul 16, 2:48 pm, robert bristow-johnson <r...(a)audioimagination.com> wrote: > On Jul 16, 12:04 pm, Jitendra Rayala <jray...(a)hotmail.com> wrote: > > > On Jul 16, 4:52 am, dvsarwate <dvsarw...(a)gmail.com> wrote: > > ... > > > and I don't understand MATLAB, and so > > > cannot figure out what is going on. All I am going by > > > is the claim that df and dw happen to have the same > > > value sqrt(2) which puzzles me. > > and it has *nothing to do with MATLAB. > > ... > f = fs*[-(L-1)/2:L/2]/L; Correction: f = (fs/L)*[-ceil((L-1)/2) : floor((L-1)/2)]; f = (fs/L)*[-floor(L/2) : floor((L-1)/2)]; f = (fs/L)*[-(L-1)/2 : (L-1)/2]; % N odd (no Nyquist) f = (fs/L)*[-L/2 : L/2-1]; % N even (negative Nyquist) Hope this helps. Greg > w = 2*pi*f; > > ... > > df = sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); > dw = sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); > > ... > > given this, if gf is the same in both equations, dw has no choice > other than to be 2*pi*df, as it should be. one is radians per unit > time and the other is cycles per unit time. i don't know why Jitendra > chose to put 2*pi in his df computation (and i'm not worried about > it), but that is the only source to the confusion Dilip had regarding > dw and df being the same when they shouldn't have been. > > > > The great god MATLAB has spoken, but I am a non-believer.... > > > I occasionally visit comp.dsp and I see much negative view of Matlab > > which I find bit surprising. It's just a tool. Isn't it the the > > user's responsibility to check what they provide and what comes out? > > If somebody does not like it, they can use some other tool if > > available or may be start a company and develop another tool? > > i am not a MATLAB proponent nor detractor in general (i used it a lot > earlier, now i sometimes use Octave because i am too cheap to buy > MATLAB for a current computer), but i consider it inexcusable that the > indexing scheme they have (where all arrays *must* have index origin > of 1) is so inflexible, because even if sometimes having origin 1 is > "right" (that is, congruent to what is common in the literature for > some application), sometimes it is wrong (say for the FFT). a > sophisticated and supposedly flexible language that purports to allow > one to write equations just as they are on paper is lacking something > quite fundamental when it does not accommodate negative or zero > indices. i also think that this, combined with their ordering > convention for polyval() and polyfit() is wrong. there are some other > more minor kludges in MATLAB, but i am not worried about it. > > r b-j
From: Jitendra Rayala on 17 Jul 2010 02:05 On Jul 16, 10:30 am, dvsarwate <dvsarw...(a)gmail.com> wrote: > which does not really answer the question. There are two similar > but slightly different computations going on, namely > > sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); > sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); > > The first gives dw and then the second number is multiplied by 2*pi > to get df. But if dw = 2*pi*df, then is it really necessary to > compute one more time the sums and the square roots and so on? Why > not simply write > > df = dw/(2*pi) > > thereby saving a lot of machine cycles from an untimely death? One could argue the other way and say that why not show the computation explicitly. It may make it easier for someone else. So with all due respect, these arguments of computing implicitly or preserving machine cycles I believe are not relevant to the discussion. The purpose of the script is to illustrate the computation of rms widths. A question about 2*pi was raised and I explained what I was trying to do. If somebody were to feel that the explanation is not enough, they can take the script, look at the Gabor width definitions, modify the script if they want to or need to, use it if they want to or not use it if they do not want to or do whatever they feel like. no? Isn't that the beauty of posting online? > Yes indeed, and the negative view of MATLAB is because of the > tendency of some (and especially new posters and students) to > confuse between MATLAB and reality. If MATLAB gives some > answer, then that is the right answer. But it still means that it is not the issue with Matlab but with users of that tool. If not used properly, it could happen with any tool. > And if you will forgive > me for saying so, Jitendra, you too have fallen into the > trap of accepting unquestioningly what MATLAB gives you > since your program gave dw and df the same value sqrt(2), > and you posted this result to comp.dsp without checking > if it made any sense. If I had just posted the results without the script then it would be different but since it is there for everyone to see, the assertion that the results are accepted unquestioningly is not only wrong but it is also not fair. Yes, there is scope for someone to interpret the results differently and I have already explained the reasons for doing it the way it is done in the script. As I already said above, one can take the definitions of the rms widths, match them with the script and play with it. That's the purpose of posting it. In this whole thread I have put in some time and effort to provide some good references that the OP can use to get some answers, script that they can play with etc. After all that, why would I post something if that is blatantly wrong? I have used Matlab/Octave extensively in wide range applications and I know a thing or two about them or in general on simulation. The importance of validating the results is not only restricted to simulation. Whether it is simulation, mathematical analysis or field experiments one should not take the results at face value and need to cross check with each other where ever possible. That's the way at least I work. Jitendra > > --Dilip Sarwate
From: Jitendra Rayala on 17 Jul 2010 02:12
On Jul 16, 11:48 am, robert bristow-johnson <r...(a)audioimagination.com> wrote: > On Jul 16, 12:04 pm, Jitendra Rayala <jray...(a)hotmail.com> wrote: > > > On Jul 16, 4:52 am, dvsarwate <dvsarw...(a)gmail.com> wrote: > > ... > > > and I don't understand MATLAB, and so > > > cannot figure out what is going on. All I am going by > > > is the claim that df and dw happen to have the same > > > value sqrt(2) which puzzles me. > > and it has *nothing to do with MATLAB. > > ... > f = fs*[-(L-1)/2:L/2]/L; > w = 2*pi*f; > > ... > > df = sqrt(sum(f.^2.*gf.^2)/(sum(gf.^2))); > dw = sqrt(sum(w.^2.*gf.^2)/(sum(gf.^2))); > > ... > > given this, if gf is the same in both equations, dw has no choice > other than to be 2*pi*df, as it should be. one is radians per unit > time and the other is cycles per unit time. i don't know why Jitendra > chose to put 2*pi in his df computation (and i'm not worried about > it), but that is the only source to the confusion Dilip had regarding > dw and df being the same when they shouldn't have been. > > > > The great god MATLAB has spoken, but I am a non-believer.... > > > I occasionally visit comp.dsp and I see much negative view of Matlab > > which I find bit surprising. It's just a tool. Isn't it the the > > user's responsibility to check what they provide and what comes out? > > If somebody does not like it, they can use some other tool if > > available or may be start a company and develop another tool? > > i am not a MATLAB proponent nor detractor in general (i used it a lot > earlier, now i sometimes use Octave because i am too cheap to buy > MATLAB for a current computer), but i consider it inexcusable that the > indexing scheme they have (where all arrays *must* have index origin > of 1) is so inflexible, because even if sometimes having origin 1 is > "right" (that is, congruent to what is common in the literature for > some application), sometimes it is wrong (say for the FFT). a > sophisticated and supposedly flexible language that purports to allow > one to write equations just as they are on paper is lacking something > quite fundamental when it does not accommodate negative or zero > indices. i also think that this, combined with their ordering > convention for polyval() and polyfit() is wrong. there are some other > more minor kludges in MATLAB, but i am not worried about it. > Personally I take the lack of flexible indexing as more of an inconvenience than annoying. It gets in the way when especially the Matlab implementation needs to be converted to fixed point models but I just treat it as another item in checklist to take care of. Otherwise I understand what you are saying. Jitendra > r b-j |