DSPRelated.com
Forums

proper terminology for one bin of an fft/dft?

Started by Ron N. March 13, 2006

Eric Jacobsen wrote:

> > > >don't worry Ron, this is a religious war that flames up every few years here > >and i am definitely a partisan of a particular POV. (and everyone who > >disagrees burns as a heretic.)
I'm glad you have acknowledged that it is YOUR POV. You used to call it the DFT's POV and that was clearly wrong :) -jim ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Ron N. wrote:
> John Monro wrote: > > Rick Lyons wrote:
...
> > > "The DFT's second and third bins centers > > > (2*Fs/N and 3*Fs/N respectively) are separated > > > by 100 Hz."
...
> > Shouldn't that be "... (Fs/N and 2*Fs/N respectively)..."?
...
> More nomeclature ambiguity. Is the DC term of a DFT/FFT more > commonly refered to as the first bin or the zero-th bin?
Well the answer, from the following comments, seems obvious. There is no agreed common usage, and enough listeners can be confused by either and both usages. Perhaps pick a usage that fits your prose, and then state clearly, and repeatedly redundantly restate over and over again, how your usage maps ordinals to index's to (signed?) cycles per aperature as needed. "The frumpteenth bin found at index ichi-quatro which contains the correlation against a shifted complex frequency of -7 wiggles per doorway." IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
Jerry Avins wrote:
> John Monro wrote: > >> Jerry Avins wrote: >> >>> John Monro wrote: >>> >>> >>>> .... We are rationally debating an issue. ... >>> >>> >>> >>> >>>>> X[k] is the value of the "(k)th" or the "(k+1)th" bin? >>>> >>>> >>>> >>>> >>>> >>>> X[k] is the value of the "(k)th" bin in MATLAB. >>> >>> >>> >>> >>> If X[14] is the value of the 14th bin in Matlab, then X[1] is the >>> value if the first bin in Matlab. How about the more usual case where >>> N bins are given the labels 0 to N-1? >>> >> In that case then bin X[14]would be the "the fifteenth bin." (We use >> the same principle in numbering historical centuries and I don't think >> it causes any problems.) > > > But it does! People are still debating when the 20th century ended.
Yes, it sparked off endless bar-room discussions, but I don't think there was any debate among mathematically literate people (at least when they were sober.) :=)
> >>>> Actually, I was not trying to re-ignite a previous debate about >>>> indexing. I was saying that we should not seek to tamper with the >>>> English language to the extent of changing the meaning of 'first,' >>>> and of introducing the ugly and awkward 'zero-th' in its place. >>> >>> >>> >>> >>> I'm all for preserving the purity of language, with clarity >>> uppermost. Here, I'm torn. What should one call the item whose >>> ordinal number is zero when dealing with a collection of items >>> numbered from zero? >> >> >> >> The problem is that this is only one of many numbering systems that >> may be used, although admittedly a popular system. >> >> If we had been using some other form of number identification this >> discussion would not take place. For example if we had statistical >> data for years 1980 to 2005 we would not be mulling over what to call >> the 1980 data set. We would refer to it either by its identifying >> number (eg. 'the 1980 data set') or by its order (eg. 'the first data >> set.') It would be plainly ridiculous to seek to re-define the >> language to allow use to refer to the 1980 data set as 'the 1980th >> data set.' > > > Agreed. A problem with "zero bin" instead of "zeroth bin" is that one > isn't certain whether "zero" refers to the label or to the contents.
True. How about 'bin zero'then?
robert bristow-johnson wrote:
> in article 44226725$0$20113$afc38c87@news.optusnet.com.au, John Monro at > johnmonro@optusnet.com.au wrote on 03/23/2006 04:15: > > >>Jerry Avins wrote: >> >>>John Monro wrote: >>> >>> >>> >>>>.... We are rationally debating an issue. ... >>> >>> >>>>>X[k] is the value of the "(k)th" or the "(k+1)th" bin? >>>> >>>> >>>> >>>>X[k] is the value of the "(k)th" bin in MATLAB. >>> >>> >>>If X[14] is the value of the 14th bin in Matlab, then X[1] is the value >>>if the first bin in Matlab. How about the more usual case where N bins >>>are given the labels 0 to N-1? >>> >> >>In that case then bin X[14]would be the "the fifteenth bin." > > > gee, that's not confusing! >
Then why not just call it 'bin 14?'
> >>(We use the same principle in numbering historical centuries and I don't >>think it causes any problems.) > > > it's starting to cause problems. particularly when folks like the MathWorks > like to encode that historical numbering system into a modern tool (MATLAB) > and force everyone to use it. i have, at a different time in my life, spent > hours trying to track down an obscure bug in some code (usually a phase > vocoder) because some little place i forgot to add 1 to the index or > subtract 1 from it. >
Me too, whether using C or Matlab, but I don't think the enumeration mrthod was the problem in either case.
> > >>>It seems that zeroth is an appropriate short form for "the item whose label >>>is zero." If zeroth is used, then R.B-J.'s oneth and twoth also probably >>>serve as sufficient reminders of departure from the usual names. It is >>>still true that the Nth item is labeled N-1. Is that bad? >> >>The problems with Robert's 'oneth' and 'twoth' suggestion is: >>1. You then have to re-define the terms 'fourth' (and higher). > > > naw, we never really get that high in verbal discussion. it's just that > when i used "first" in class when i meant the DC bin, some confusion > results. > > >>2. If the idea catches on, and a published paper refers to, say, the >>'fourth' bin but does not mention any lower bins, we will not have >>enough clues to work out which convention the author is using. > > > at that level the author should be explicit and say "X[4]" or "X[3]" and > make it clear. >
Or 'bin 4' etc. Why not stick to that scheme and refer to 'bin 0?' when referring to the first bin?
> >>A general note: Maybe for clarity we should just avoid using ordinal >>numbering. Maybe we should just refer to the data's identification >>number rather than its position. For example, we could write: 'bin 0' >>or 'year 1980'instead of 'the first bin' or 'the first year's data.' >> >>By the way, I see no problem in referring to item (N-1) as the Nth item. >> >>Finally, how often is bin 0 the first bin? If bin 0 is defined to be >>the bin that holds the DC component, then bin 0 is usually in the middle >>of the unscrambled FFT output. > > > i know what you mean (it's called "fftshift()" in MATLAB), but as it > guzzinta or cumsouta the FFT, it's at bin 0.
Your use of the term 'bin 0' here is clear and unabmiguous. It is to be recommended!
> > take a look at this handwritten paper by Edsger Dykstra: > > http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF > > it's not just about the C programming language or the numbering of bins in > the DFT or iDFT. in our technical evolution, this historical convention > should evolve also. >
It is an interesting note, and I have a lot of respect for Dykstra, but I don't think society as a whole is about to change its enumberation conventions to suit the convenience of the computer scientists. (I dont't find his argument convincing on computer science grounds either.) Regards, John
in article 44236a39$0$7605$afc38c87@news.optusnet.com.au, John Monro at
johnmonro@optusnet.com.au wrote on 03/23/2006 22:40:

>>> (We use the same principle in numbering historical centuries and I don't >>> think it causes any problems.) >> >> >> it's starting to cause problems. particularly when folks like the MathWorks >> like to encode that historical numbering system into a modern tool (MATLAB) >> and force everyone to use it. i have, at a different time in my life, spent >> hours trying to track down an obscure bug in some code (usually a phase >> vocoder) because some little place i forgot to add 1 to the index or >> subtract 1 from it. >> > Me too, whether using C or Matlab, but I don't think the enumeration > method was the problem in either case.
of course it was the problem. i wanted to know the frequency of a component based upon the index of the bin of the maximum (there was that typical quadratic interpolation involved) and although i remembered to scale it with 1/N (N = the FFT size), i forgot to subtract 1 from the index in MATLAB (something i wouldn't be doing in C or C++ or any asm on the planet). that bug made the calculation of the phase offset you do in the phase vocoder wrong by just a teensy-weensy bit (which bothered the hell outa me). it was a simple little bug but very hard to see. the blame lies solely with the indexing convention that is hard-wired in MATLAB. my code reflected the math (all of the DSP texts call the DC component "X[0]" not "X[1]"). i refuse to accept blame for that. i started a long dispute with Cleve Moler about it on this and the MATLAB newsgroup after that and he utterly failed to meaningfully refute why MATLAB should not be extended to be able to have *any* integer indexing base (not just 1 or 0) as long as the default is what it uses at present (base = 1) for backward compatibility. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
John Monro wrote:

>> ... People are still debating when the 20th century ended. > > > Yes, it sparked off endless bar-room discussions, but I don't think > there was any debate among mathematically literate people (at least when > they were sober.) :=)
Even some who understood the math argued that for a 0.05% error, we should just go with the numbers. ...
>> Agreed. A problem with "zero bin" instead of "zeroth bin" is that one >> isn't certain whether "zero" refers to the label or to the contents. > > > True. How about 'bin zero'then?
That's good. I even use it sometimes. I ought to have recalled. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
On Wed, 22 Mar 2006 10:33:28 +1100, John Monro
<johnmonro@optusnet.com.au> wrote:

  (snipped)

>> Hi John, >> >> Yep. I should have written "(Fs/N and 2*Fs/N respectively)". >> Darn, sorry for the confusion. I usually refer to the >> 0-Hz bin (DC) as the "first bin". >> >> Thanks for catchin' my mistake John. >> [-Rick-] >> >> > >Rick, >It's not often I get the chance! I didn't think you had gone over to the >Dark Side, so thought I would point out the momentary lapse :-). > >Regards, >John
Hi John, may the Force be with you. I can imagine someone saying the "zeroth bin" in referring to the DFT bin centered at zero Hz. But then what would they call the next bin to the right? The "oneth bin"? And would they refer to the next bin to the right as the "twoth bin"? Sheece, that doesn't sound right. [-Rick-]
in article 4424b56f.266530468@news.sf.sbcglobal.net, Rick Lyons at
R.Lyons@_BOGUS_ieee.org wrote on 03/24/2006 22:18:

> On Wed, 22 Mar 2006 10:33:28 +1100, John Monro > <johnmonro@optusnet.com.au> wrote: > > (snipped) > >>> Yep. I should have written "(Fs/N and 2*Fs/N respectively)". >>> Darn, sorry for the confusion. I usually refer to the >>> 0-Hz bin (DC) as the "first bin". >>> >>> Thanks for catchin' my mistake John.
>> It's not often I get the chance! I didn't think you had gone over to the >> Dark Side, so thought I would point out the momentary lapse :-). >>
> Hi John, > may the Force be with you. > > I can imagine someone saying the "zeroth bin" > in referring to the DFT bin centered at zero Hz. > But then what would they call the next bin to > the right? The "oneth bin"? And would they > refer to the next bin to the right as the "twoth bin"? > Sheece, that doesn't sound right.
of course not. because i said it. right, Rick? well if you call it the "first bin", some (like John) will think X[0] and others will think X[1]. but if i (first) say "zeroeth bin" to refer to X[0], i think all of the students in that EE295 class knew what i meant when i said "oneth bin" or "twoth bin", especially after hearing me rant about stupid MATLAB hard-wired indexing that puts the DC component in X(1). but it was clear, when i said "kth bin" it was X[k]. so what did you mean by "kth bin", Rick? X[k-1]? geee, how natural. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
robert bristow-johnson wrote:
> in article 44236a39$0$7605$afc38c87@news.optusnet.com.au, John Monro at > johnmonro@optusnet.com.au wrote on 03/23/2006 22:40: > > >>>>(We use the same principle in numbering historical centuries and I don't >>>>think it causes any problems.) >>> >>> >>>it's starting to cause problems. particularly when folks like the MathWorks >>>like to encode that historical numbering system into a modern tool (MATLAB) >>>and force everyone to use it. i have, at a different time in my life, spent >>>hours trying to track down an obscure bug in some code (usually a phase >>>vocoder) because some little place i forgot to add 1 to the index or >>>subtract 1 from it. >>> >> >>Me too, whether using C or Matlab, but I don't think the enumeration >>method was the problem in either case. > > > of course it was the problem.
No it wasn't. In my case it was usually sloppy program planning. i wanted to know the frequency of a component
> based upon the index of the bin of the maximum (there was that typical > quadratic interpolation involved) and although i remembered to scale it with > 1/N (N = the FFT size), i forgot to subtract 1 from the index in MATLAB > (something i wouldn't be doing in C or C++ or any asm on the planet). that > bug made the calculation of the phase offset you do in the phase vocoder > wrong by just a teensy-weensy bit (which bothered the hell outa me). it was > a simple little bug but very hard to see.
This is obviously irritating, but mistakes like this occur in any language, regardless of the indexing convention. They are probably most likely when changing to one language after a period of programming in the other. I have found that the main source of my mistakes of this type, both in MATLAB and C, was using an incremented index-value instead of the pre-incremented value (or vice-versa). I can't say they were particularly related to the indexing convention used.
> > the blame lies solely with the indexing convention that is hard-wired in > MATLAB. my code reflected the math (all of the DSP texts call the DC > component "X[0]" not "X[1]"). i refuse to accept blame for that. i started > a long dispute with Cleve Moler about it on this and the MATLAB newsgroup > after that and he utterly failed to meaningfully refute why MATLAB should > not be extended to be able to have *any* integer indexing base (not just 1 > or 0) as long as the default is what it uses at present (base = 1) for > backward compatibility. >
User-definable indexing would be convenient. Mathworks would have to balance the value of this new feature against: 1. The direct cost of implementing it: (programming, testing and documentation.) 2. The opportunity cost; implementing that improvement rather than some other. 2. The loss of compatibility with older versions of MATLAB. 3. Slower execution in the code when running in the usual interpreted mode. I don't want to argue whether MATLAB's indexing is better than C's, as that was well covered previously and I don't think any of us changed our preferences, although I think we all came to appreciate the other person's point of view. Regards, John
Jerry Avins wrote:
> John Monro wrote: > >>> ... People are still debating when the 20th century ended. >> >> >> >> Yes, it sparked off endless bar-room discussions, but I don't think >> there was any debate among mathematically literate people (at least >> when they were sober.) :=) > > > Even some who understood the math argued that for a 0.05% error, we > should just go with the numbers. >
If we had celebrated the New Millennium June 30th then the error would be only +-0.025%. Actually, the really smart people partied on both Dec 31 2000 and Dec 31 1999.
> ... > >>> Agreed. A problem with "zero bin" instead of "zeroth bin" is that one >>> isn't certain whether "zero" refers to the label or to the contents. >> >> >> >> True. How about 'bin zero'then? > > > That's good. I even use it sometimes. I ought to have recalled. > > Jerry