Talk:Convolution theorem

In the style of pi

Where do these 2pi's come from? As far as I know, it's just F(f * g) = F(f)F(g), F(fg) = F(f) * F(g)

I believe the 2pi's are applicable depending on which school of thought you come from. Mathematicians use fourier transforms with a 'frequency' term k. Engineers prefer to use the symbol omega for natural frequency, but call it k anyways. I'm not entirerly sure about this (which is why it's in discussion and not on the page) and I don't feel like looking it up. But check out the wikipedia page on Fourier transforms.

The 2pis probably come from what definition of the Fourier transform you choose to use. Wikipedia likes to put a 1/sqrt(2pi) in front of both the transform and the inverse transform whereas others choose to put a 1/2pi in front of the inverse transform alone. This is probably the same thing as the person above mentioned but I'm not sure. I believe that the latter is the form that leads to a convolution theorem with no 2pis.

Is there any chance of getting a derivation of the theorem on here so that we can see what's happening?

--Zapateria 14:43, 7 May 2006 (UTC)[reply]

Most authors try do be in how they choose their constants. So if the you chose to use a

1/sqrt{2\pi }

in the definitions of Fourier transform and inverse transform then often people like also to put the same factor infront of the definition of convolution to avoid the constant croping up in this theorem. 128.135.197.2 18:21, 17 July 2006 (UTC)[reply]

One possible derivation starts from an exponential Fourier series of an arbitrary periodic function with period

T

, and then by a limiting process finds the formula for the coefficients as

T\rightarrow \infty

and the function becomes aperiodic. The Fourier series expression then becomes the inverse transform, and the coefficients become the Fourier integral. If you use

t,\,\omega

as the "variables" then the coefficient in front of the inverse should turn out as

{\frac {1}{2\pi }}

and the coefficient in front of the direct transform should turn out as 1. This makes the convolution theorem turn out to be

{\mathcal {F}}\lbrace (f*g)(t)\rbrace =F(\omega )G(\omega )

This heuristic derivation would be more suited for the main article on the Fourier transform than for the article on the Convolution theorm. DivisionByZer0 19:29, 14 June 2007 (UTC)[reply]

Integration over $\mathbb {R} ^{n}$ ?

Why are the integrations shown here as being carried out over $\mathbb {R} ^{n}$ ? I see no indication of more than one dimension; so, shouldn't they just be over $\mathbb {R}$ ?

If I recall correctly the multidimensional FT should look something like $F(k)=\int _{\mathbb {R} ^{n}}f(\mathbf {x} )e^{-i(\mathbf {x} \cdot \mathbf {k} )}\,\mathbf {dx}$ DivisionByZer0 20:00, 14 June 2007 (UTC)[reply]

My mistake: I now see the inner products in the argument of the exponentials.

References

I added a reference since someone insisted on the article having it. I took one of the books on the reference list of the Fourier transform page that happens to be a classic. Any other textbook on Fourier-analysis would also do, they all contain the material.

I will delete the call for references a second time. The material is standard and unlikely to be controversial so adding detailed citations is unlikely to be helpful. —Preceding unsigned comment added by MathHisSci (talk • contribs) 23:43, 19 January 2010 (UTC)[reply]

"Diagonalization"?

Would it be accurate to say that, in a way the convolution theorem says that convolution is a diagonal operation in a Fourier basis? —Ben FrantzDale (talk) 22:15, 17 January 2008 (UTC)[reply]

Whilst I know what you're getting at, I'm not sure that "diagonal operation" is a commonly-used term (at least in this sense). I could well be wrong though. Oli Filth^(talk) 22:24, 17 January 2008 (UTC)[reply]

I'm glad you know what I'm getting at. I didn't think that was conventional lingo (hence the quotes). If there is a word for a generalization of the idea of a diagonal matrix, I would like to know it. —Ben FrantzDale (talk) 01:25, 18 January 2008 (UTC)[reply]

Only 24k matches for "diagonal operator". This is too few to be called "commonly-used" indeed. I suggest saying that "the convolution operator is diagonal with respect to the trigonometric system". --Javalenok (talk) 15:12, 15 November 2010 (UTC)[reply]

Late comment but it's a very relevant question (maybe the question from the operator theory point of view). Yes, that is exactly what is going on. Diagonalization can be be more generally interpreted as showing the operator at hand (in this case convolution with a given function, say g) is unitarily equivalent to a multiplication operator (multiplication by g^). The implementing unitary transform here is the Fourier transform, acting on the Hilbert space L²(R).

In fact, here we have simultaneous diagonalization of a commuting family of normal operators. This make the theorem a special instance of the spectral theorem. The Fourier transform does this by design. If you look at the family of operators given by convolution with some delta function δ_x. Convolution with δ_x takes f(y) to f(y-x). So this is a family of commuting unitary operators on L²(R). In the frequency domain, they become multiplication by e^2πiξ•x. You can view e^2πiξ•x as the "eigenvalues" (more precisely the spectrum) of convolution by δ_x. Now convolution with a general g(x) in L¹(R) is simply the integral of these unitary operators. So the same result holds.

This is true for any locally compact group by the very definition of the Fourier transform. When you take that group to be the circle, since its Pontryagin dual is Z, we really have a case of "diagonalization"; the spectrum of all the operators under discussion are discrete. You would be looking at multiplication of sequences. Even simpler, take the cyclic group Z_n (discrete Fourier transform), the whole discussion reduces to computing the eigenvalues of the cyclic shift on Cⁿ, which are the n-th roots of unity.Mct mht (talk) 22:53, 15 September 2012 (UTC)[reply]

This should be pointed out in the article. The Katznelson reference probably contains a relevant discussion. Mct mht (talk) 23:03, 15 September 2012 (UTC)[reply]

I tried to add that point [1] (see in the very end, before References). But, it was removed as "nonsense" after a while. It seems that we must not speak about diagonalization of the convolution (Toeplitz), its eigenvectros. The supreme powers want us to stay in the time domain. I have created a corresponding discussion in the math.stackexchange.org. --Javalenok (talk) 10:08, 25 July 2014 (UTC)[reply]

Difficult for laymen

I think this is a tough read for a non-mathematician. Can someone sum it a way an educated programmer, but non-math major, can understand it easily? —Preceding unsigned comment added by 65.114.107.194 (talk) 21:10, 17 February 2010 (UTC)[reply]

I agree that it should be made more readable for people without a math background. As a physicist, I'm stuck because I don't understand the symbolic notation in the proof sector. It would be nice if L¹ and ||g₁|| were explained. Femkemilene (talk) 14:34, 16 August 2016 (UTC)[reply]

Deleted References to GNU C-Graph

The following is re-posted, here, on advice from PamD noted at the end of this section.

Long before I wrote the proposed article "GNU C-Graph", I included references under the articles Convolution theorem and Convolution for the benefit of students and their professors teaching and learning about convolution. These references were removed by MrOllie and Hu12. Notwithstanding my belief that GNU C-Graph meets the WP:Notability criteria, Mark viking pointed out "external links aren't required to be WP notable, just relevant".

Most reasonable people would agree that removing the reference to the only software that easily demonstrates the convolution theorem would be a disservice to the public. The text of the references reads:

Under Convolution#External_links:

GNU C-Graph, a free software package for visualizing the convolution theorem, and displaying signals with their spectral plots.

Under Convolution_theorem#Additional_resources:

GNU C-Graph, a free software package for demonstrating the convolution theorem, and displaying signals with their spectral plots.

No doubt some WP:AGF administrator will recognise the educational value and reinstate the references for the benefit of the public.Visionat (talk) 14:16, 24 April 2013 (UTC)[reply]

Visionat, the places for these discussions are Talk:Convolution theorem and Talk:Convolution, not your own talk page. Those pages are also where you should have suggested the addition of links to the software you have written, bearing in mind WP:COI: to avoid any interpretation that you are promoting your own software, you should suggest the addition of the links on the talk page and allow independent editors (not necessarily administrators) to decide whether the links are an asset to the articles. If you look at WP:COIU, you will see that an editor with a possible conflict of interest may "make edits where there is clear consensus on the talk page (though it is better to let someone else do it)". That's the way to go. It's nothing personal, so your talk page is not the place for the discussion. I hope that helps. PamD

I have no objection, in principle, but when I follow the external link, I expect to see examples of output and information about what it will take to get up and running. What are the O/S requirements?, do I need a compiler?, etc. Instead it expects me to just start blindly downloading files into my PC. Beggars can't be choosers, but nobody is begging for this software. So it needs better advocacy, in my opinion, FWIW. --Bob K (talk) 15:51, 24 April 2013 (UTC)[reply]

Bob K, try it you might like it. I've been meaning to upload the user manual and additional material for sometime now to gnu.org/software/c-graph. I've simply had far too much to do. People do seem to be "begging" for the software, though. I hear the download statistics are pretty impressive!! Will post once I get hold of the recent figures. You can see examples of output in my sandbox. Great that you have no objections to the references!!!:)

-Visionat (talk) 20:27, 24 April 2013 (UTC)[reply]

First of all, downloading isn't the same as liking what they find and using it to improve their lives. They have to D/L it just to see what the heck it is.

Anyhow, I read what you are working on in your sandbox, and frankly I'm not convinced of its significance. In my own words what it says is that the IDFT(DFT*DFT) operation is an incomprehensible black box (for some), but if you see it work with a bunch of different input functions, you will at least trust it to work on your own data in the future. And there is something to be said for that. My pocket calculator is a black box (to me), but it seems to work, which is all I really need to know. So I will concede that as a useful concept for some, who might appreciate the external link. But other things still bother me.

One, as I said before, is the lack of up front information about what one is actually getting himself into if he starts downloading files. And I don't understand why such a simple application, with over 30 years of history, isn't just a done deal. Why does it need a development team and mailing lists? And if it's so important, why is it still in FORTRAN? What I would actually expect these days is that one could run the experiments/demonstrations right on the website.

Frankly, the whole thing (website and sandbox) seems like a school project to me... using C-Graph as a convenient subject to practice the skills of online promotion and documentation (marketing?). It's the same idea as a science fair project, where the object is not new science but rather repeating some old science for the sake of learning how to explain it and present the results. The student is graded on the process, not the science. Your packaging looks pretty good, but the product inside is a one-trick pony written in a primitive language. I'm not trying to get in an argument or deflate any egos. Just giving my honest impressions. If I somehow missed the whole point, I apologize.

My bottom line regarding the inclusion of the external link is that a lot more people will find it useless and a waste of their time than the ones who will ultimately appreciate it.

--Bob K (talk) 12:40, 25 April 2013 (UTC)[reply]

It would be really overdoing things to include convolutions with more input functions in the sandbox article, but I plan a gallery-like page in the info still to be uploaded to gnu.org.
Development of the convolution theme includes other mathematical concepts. Far from being a "one-trick pony" you ought to know that the mathematics of the delta function, alone, lends itself to further visualization of subject matter routinely taught in dsp and related courses. Besides the ability to code, Development only needs imagination.
As the article indicates, I too made the mistake that Fortran was a dinosaur. Fortran is under active development, surpassing the performance of C in certain areas. I also code in C, Lisp, Scheme, and will be writing some code for C-Graph in Python - but modern Fortran remains a good choice for the core code.
There are websites that offer the demonstration of convolution, but none that encompass verification of the convolution theorem with ease, or that offer the range of features GNU C-Graph does. The download statistics verify C-Graph's growing popularity.
The meritless claim of "online promotion and documentation (marketing?)" has been recited elsewhere and is transparent in its intent.
Yes, you did miss the point. I won't comment on the other "significant" additional resources and external links listed in the articles on Convolution and Convolution theorem, except that they hardly present "new science", which is not a requirement for a reference.
No, it's not possible to deflate my ego. I'm accustomed to these types of responses - and use them as building blocks.

Enough said. The reason more information on C-Graph is not already at GNU is because I find myself having to spend too much time dealing "blocks" in various forms. Wikipedians visiting this talk page have the text for the references should they choose to use them. Happy editing!

Avoiding more convoluted conversation.:) -Visionat (talk) 14:11, 25 April 2013 (UTC)[reply]

I wish you the best. And I'm actually happy to hear that I missed the point, because you seem to be working hard at it and doing a good job on some aspects. But if I missed the point, others will too (apparently already have), so I expect that is something you will be analyzing and working on in the future. Have fun. --Bob K (talk) 19:14, 25 April 2013 (UTC)[reply]

Notations

It's my first time posting in the 'talk" section. Please forgive me if this is not the right place to ask or suggest something. Although I agree that notations don't matter much and depends on the writer but I think it'll be better if we use ξ instead of f. Generally, f,g,h denote functions but here f is real and g,h are functions. As far as I have seen, almost everyone uses ξ even the main wiki page of Fourier transform uses ξ. Paramakalia (talk) 16:21, 28 February 2023 (UTC)[reply]

I would be for the change. Thenub314 (talk) 22:03, 6 March 2023 (UTC)[reply]

I would be happy to replace g,h with u,v or r,s. --Bob K (talk) 20:42, 10 January 2024 (UTC)[reply]

Point-wise?

All the talk about "point-wise multiplication" seems completely superfluous to me, even the use of the occasional dot symbol for it. In the end, the usual interpretation of what happens when two functions are multiplied seems to apply, and it is perfectly adequate and readable to put the two symbols next to each other, with no operator symbol in between. The article isn't even very consistent with regards to this. 5.158.192.11 (talk) 07:20, 29 August 2024 (UTC)[reply]