91–100 of 171 posts
Earlier quoted context omitted.
This is very much called out in the Monad Burrito Tutorial Fallacy[1]. [1]: https://byorgey.wordpress.com/2009/01/12/abstraction-intuiti...
One of the best explanations of monads I saw was actually using Python.
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…
> If, like me, you struggled to understand the Fourier Transformation when you first learned about it
No where does the author imply that he is teaching the Fourier Transform to someone who has never heard of it.
I agree with your overall point. Blog posts are not going to teach you difficult mathematics unless they are the length of college textbooks. But a blog post like this is great for reinforcement. If, like me, you are an ECE (Electrical and Computer Engineer) who has written software for the last 15 years, an explanation like the one in the post makes a lot of neurons reconnect.
Earlier quoted context omitted.
A monad is a computational context, where the nature of that context is determined by two things: the shape of the data structure corresponding to it, and the definition of (>>=) which handles sequencing of two computations in that context. Anything more specific than that should be handled case-by-case until you build an intuition for how any given monad will behave.
Is computational context another way of saying scope?
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…
I don't think they meant "not complicated to learn", but "never complicated to teach, once its time had arrived in the natural progression of the course".
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.
In that spirit, my pet "a monad is a monoid in the category of endofunctors, duh"-style one-line explanation of the Fourier transform is that it's just the decomposition in the common (Hilbert) eigenbasis for all translation operators. It makes it surprisingly clear (to some) why it is a both natural and important construction.
I think the best semi-intuitive, non rigorous explanation I've seen of the Fourier transform is still one that first explained signal correlation in the time domain and then described the transform as basically performing correlation on the signal for all the possible sines at different frequencies. Essentially you're just testing for the presence of individual sine waves (of different frequencies) within the signal.…
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 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.
After watching3Blue1Brown's video, I get it. So I can share with you what confused me:
It's this part of the sentence: "average a bunch of points along that path". I know what averaging it, but I don't know what averaging "along a path" means. Also I was (wrongly) expecting the output of this function to be a real number - I just expect "energy" to be a number. Instead, here what we're doing is averaging complex numbers so the output is a complex number. What a complex energy means is left as an exercise to the reader.
Here's my suggestion for a sentence that would have worked better for me:
"To find the energy at a particular frequency, spin your signal around a circle at that frequency, and find the center of mass of the plot."
Presumably then we have to take the distance from the origin to get an amount of energy.