Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fourier Transform, explained in one sentence (2014)

blog.revolutionanalytics.com

Post reply on HN
Print view View original

141–150 of 171 posts

Re: The Fourier Transform, explained in one sentence (2014)

#141

Post by soheil »

jasode wrote: post #88
prof-dr-ir wrote: post #69

Does "blog post learning" ever really work? I have taught these kind of undergraduate subjects and, in the context of a course , the Fourier transform never struck me as something very complicated. First, it feels completely natural to write down a Fourier decomposition for periodic functions; the inverse transform to determine the coefficient is just (real or complex) calculus; and all that is left is to convince th…

>I have taught these kind of undergraduate subjects and, in the context of a course, the Fourier transform never struck me as something very complicated. It's great that it was "never complicated" for you. In contrast, the author (David Smith) of this blog post admits that he initially struggled with the Fourier Transform -- and wants to share some insights he gained after he understood it. He has already graduated w…

> It's great that it was "never complicated" for you.

Please stop making it sound like the commenter was bragging. That's just having bad faith in HN users.

The comment was about how the context and prior understanding of the underlying topics is a necessary prerequisite for understanding complex topics built on those and how blog learning is a necessarily contrived method of teaching.

It does not mean it won't work for some. If you happen to have the prior understanding of the prerequisites then it'd be a way to learn some additional insight, but you shouldn't assume the Venn diagram for that audience is much larger than a small % of the readers.

Re: The Fourier Transform, explained in one sentence (2014)

#142

Post by l- »

l- wrote: post #118
rectang wrote: post #68

Earlier quoted context omitted.

Indeed. The title of that 3Blue1Brown video is, “What is Euler’s Formula actually saying?” That “easy to remember” formula had been presented to me countless times. It only made sense once I stopped thinking about it in terms of repeated multiplication.

The repeated "many folding", which would be better visualized as tendition, exponentiation ("tendaddition") pattern also breaks with fractions & at the most basic negative numbers: https://www.youtube.com/watch?v=mvmuCPvRoWQ&t=922s Also: https://news.ycombinator.com/item?id=28524792 "log base" would be better named untendaddition similarly division - does not necessary "separate" - untendition & unaddition - does not…

Further, the pattern matched "grouping" definitions (https://news.ycombinator.com/item?id=25278021) names have a better correspondence to the Greek scheme: diation, triation, tetration... while the "Group theory" definitions scheme lending to various geometries (hypercomplex: complex::hyperbolic, split-complex::elliptic, dual::parabolic) would match some other naming scheme.

Re: The Fourier Transform, explained in one sentence (2014)

#143

Post by tel »

lathyrus_long wrote: post #134
teolandon wrote: post #103

Earlier quoted context omitted.

This is good, but I think it's cyclical (heh). We want to compare our signal with a "pure tone". What's a pure tone? A sine wave. Why is a sine wave a pure tone? Because when we compare it with a pure tone, it's identical.

That's a question of why Fourier transforms are important though, not just how they're defined and computed. The next-level answer is presumably that sinusoids (or complex exponentials in general) are the eigenfunctions of general linear time-invariant systems, i.e. that if the input to an LTI system is exp(j*w*t), then its output will be A*exp(j*w*t) for some complex constant A. Some other comments here already allu…

Hahah, I do try not to dive into eigenfunctions when talking about this, but it is so compelling. Love seeing that exposition :)

Re: The Fourier Transform, explained in one sentence (2014)

#144

Post by stevebmark »

tel wrote: post #16

Honestly, it's not so bad. It's easy to pick any such attempt apart. This is close to my favorite pithy way of explaining it, too, which is to break it down component-wise using the idea of filter banks. It's not a single sentence, but here's what I tend to say: Any signal—like sounds or electrical signals, or even images—can be thought of as having a certain amount of 'energy' at any choice of frequency. This makes…

As someone who still doesn't understand the Fourier Transform, this explanation doesn't help, nor does the article's. As a complete noob, your explanation shows off what you know but doesn't help newcomers learn it.

Re: The Fourier Transform, explained in one sentence (2014)

#146

Post by spfzero »

teolandon wrote: post #103
tel wrote: post #16

Honestly, it's not so bad. It's easy to pick any such attempt apart. This is close to my favorite pithy way of explaining it, too, which is to break it down component-wise using the idea of filter banks. It's not a single sentence, but here's what I tend to say: Any signal—like sounds or electrical signals, or even images—can be thought of as having a certain amount of 'energy' at any choice of frequency. This makes…

This is good, but I think it's cyclical (heh). We want to compare our signal with a "pure tone". What's a pure tone? A sine wave. Why is a sine wave a pure tone? Because when we compare it with a pure tone, it's identical.

A pure sine wave has only one frequency, that's why it is analogous to a "pure tone". It's not a circular definition; they key part is the "pure", which means no dilution by other frequencies, which admittedly is not obvious.

Re: The Fourier Transform, explained in one sentence (2014)

#147

Post by spfzero »

Misdicorl wrote: post #67

IME explanations of the Fourier transform focus far too much on the specific mechanics of it without motivating the reason. I find people often don't even realize the time space and frequency space functions are the same function! I dive in like so "There are many different ways to write down the number 5. Tally marks, the sigil 5, 4+1, 2.5 times 2, 10/2. Each of them is more or less useful in different circumstances…

I like this explanation. It would be good to include a little bit about why we even care to do frequency-domain analysis, and what a "transform" is.

Re: The Fourier Transform, explained in one sentence (2014)

#148

Post by sebzim4500 »

dlandau wrote: post #30
sebzim4500 wrote: post #14

This reminds me of an old joke in the Haskell community, where people who struggled to understand Monads would finally get it after a while, and would assume that whatever the last sentence they heard was the only necessary one for the explanation.

That was my experience studying statistical physics in Uni. For "some reason" the fourth book I read was the "only one" written in a way that made sense. No relation to the order I read them in, just written better.

Yeah statistical physics is another example where suddenly things just kind of 'click'.

Re: The Fourier Transform, explained in one sentence (2014)

#149

Post by spfzero »

sebzim4500 wrote: post #14

This reminds me of an old joke in the Haskell community, where people who struggled to understand Monads would finally get it after a while, and would assume that whatever the last sentence they heard was the only necessary one for the explanation.

This for sure. "I didn't understand the first 5 explanations but I did understand the sixth one, so that's the best one." Needs to be said that without the first 5, the sixth probably wouldn't have caught.

Re: The Fourier Transform, explained in one sentence (2014)

#150

Post by bradrn »

hackinthebochs wrote: post #107
trenchgun wrote: post #75

Earlier quoted context omitted.

Not exactly. Computational context in this sense is like, is this computation of the type that can either fail or succeed? (Maybe monad). Or is this computation of the type that can produce multiple values of the same type? (List monad). Or maybe this computation can produce value of one type or another (Either monad). Or a computation that can interacti with inputs and outputs (IO monad). So these are computations i…

Let me rephrase it in words that I have more intuitive grasp of and see if the translation holds. A monad is a way to pick out the specific constraints of interest and define a class of computations that satisfy those constraints, and how computations within this class compose. Are the constraints limited to return values or can there be other kinds of constraints?

Not really… unless you have a different definition of the word ‘constraint’ than I do. Personally, I don’t see ‘constraints’ as having anything to do with monads: in fact, I see the ultimate goal of monads as allowing you to relax various constraints a language imposes on your code — things like ‘execution proceeds from one line to the next’, or in Haskell ‘expressions have no side-effects’.

It might be more helpful to think about this in terms of actual code samples. Consider a data type which can represent a computation which can fail. This data type has two possible states: ‘Failed’, and ‘Success(return_value)’ (where the ‘return_value’ field can be anything). Now, let’s say you have one result which might have failed, and you want to pass it to another fallible computation, which we can represent as a function from an input to a fallible output. How do you do it? Well, you might define a function something like this (in vaguely Rust-like pseudocode):

    fn andThen(value, nextComputation) {
        match value {
            Success(return_value) => return nextComputation(returnValue);
            Failed => return Failed;
        }
    }
That is, continue on with the next computation if you have a result, and short-circuit otherwise.

Now let’s consider a different case: what if your computation is instead nondeterministic, and can return multiple results? In this case, you might instead have a nondeterministic value — let’s represent it as a list — which you got from one computation, and you need to supply it as input to another nondeterministic computation. Then you’ll need to write something like:

    fn andThen_nondet(value, nextComputation) {
        mut result = [];
        foreach (v in value) {
            result.concat(nextComputation(v));
        }
        return result;
    }
Or a third case — promises for asynchronous values! Which in most languages have an ‘andThen’ method too, allowing you to take one asynchronous value and pass that value to an asynchronous computation. I’ll skip an example for this one since it’s so well-known, but obviously this ‘andThen’ method has roughly the same structure as the others I’ve shown.

Monads, therefore, are nothing special — they’re just data types with an ‘andThen’ method to let you sequence them. The method always has the same form: inspect the input to temporarily separate any returned value(s) from their context, then call the next computation to wrap those value(s) back up in the required context. This gets neatly summarised in the Haskell type signature:

    (>>=) :: Monad m => m a -> (a -> m b) -> m b
Post reply on HN