No, it is correct. The integral is with respect to x, and the ordinary/partial derivatives are with respect to t. Written out fully, the derivative computation is
I'm not quite sure whether you're asking for an explanation or whether you're simply making the observation that this is often omitted from the discussion. Either way I think it's an interesting point, so I'll elaborate a bit on it.
As you say, there's no guarantee that even a convergent Taylor series[0] converges to the correct value in any interval around the point of expansion. Though the series is of course trivially[1] convergent at the point of expansion itself, since only the constant term doesn't vanish.
The typical example is f(x) = exp(-1/x²) for x ≠ 0; f(0) = 0. The derivatives are mildly annoying to compute, but they must look like f⁽ⁿ⁾(x) = exp(-1/x²)pₙ(1/x) for some polynomials pₙ. Since exponential growth dominates all polynomial growth, it must be the case that f(0) = f'(0) = f"(0) = ··· = 0. In other words, the Taylor series is 0 everywhere, but clearly f(x) ≠ 0 for x ≠ 0. So the series converges only at x = 0. At all other points it predicts the wrong value for f.
The straight-forward real-analytic approach to resolve this issue of goes through the full formulation of Taylor's theorem with an explicit remainder term[2]:
f(x) = Σⁿf⁽ᵏ⁾(a)(x-a)ᵏ/k! + Rₙ(x),
where Rₙ is the remainder term. To clarify, this is a _truncated_ Taylor expansion containing terms k=0,...,n.
There are several explicit expressions for the remainder term, but one that's useful is
Rₙ(x) = f⁽ⁿ⁺¹⁾(ξ)(x-a)ⁿ⁺¹/(n+1)!,
where ξ is not (a priori) fully known but guaranteed to exist in [min(a,x), max(a,x)]. (I.e the closed interval between a and x.)
Let's consider f(x) = cos(x) as an easy example. All derivatives look like ±sin(x) or ±cos(x). This lets us conclude that |f⁽ⁿ⁺¹⁾(ξ)| ≤ 1 for all ξ∈(-∞, ∞). So |Rₙ(x)| ≤ (x-a)ⁿ⁺¹/(n+1)! for all n. Since factorial growth dominates exponential growth, it follows that |Rₙ(x)| → 0 as n → ∞ regardless of which value of a we choose. In other words, we've proved that f(x) - Σⁿf⁽ᵏ⁾(a)(x-a)ᵏ/k! = Rₙ(x) → 0 as n → ∞ for all choices of a. So this is a proof that the value of the Taylor series around any point is in fact cos(x).
Similar proofs for sin(x), exp(x), etc are not much more difficult, and it's not hard to turn this into more general arguments for "good" cases. Trying to use the same machinery on the known counterexample exp(-1/x²) is obviously hopeless as we already know the Taylor series converges to the wrong value here, but it can be illustrative to try (it is an exercise in frustration).
A nicer, more intuitive setting for analysis of power series is complex analysis, which provides an easier and more general theory for when a function equals its Taylor series. This nicer setting is probably the reason the topic is mostly glossed over in introductory calculus/real analysis courses. However, it doesn't necessarily give detailed insight into real-analytic oddities like exp(-1/x²) [3].
[0]: For reference, the Taylor series of a function f around a is: Σf⁽ᵏ⁾(a)(x-a)ᵏ/k!. (I use lack of upper index to indicate an infinite series as opposed to a sum with finitely many terms.)
[1]: At x = a, the Taylor series expansion is f(a) = Σⁿf⁽ᵏ⁾(a)(a-a)ᵏ/k! = f(a) + f'(a)·0 + f"(a)·0² + ··· = f(a). All the terms containing (x-a) vanish.
[3]: Something very funky goes on with this function as x → 0 in the complex plane, but this is "masked" in the real case. In the complex case, this function is said to have an essential singularity at x = 0.
Yes, for instance ...101010 (the pattern 10 repeated infinitely) isn't an integer.
It's maybe easier to think of the argument as working on sequences: From a sequence (x_0, x_1, x_2, ...) with each x_n a binary digit (i.e. 0 or 1) you can always construct a real number x = Sum(x_n / 2^n, n = 0, 1, 2, ...).
The integer you'd want to construct from such a sequence would be Sum(x_n * 2^n, n = 0, 1, 2, ...), but this only works if there's some N such that x_n = 0 for all n > N. Otherwise you would have an "infinite integer" (whatever that means). Valid positive integers are all on the form Sum(x_n * 2^n, n = 0, 1, 2, ..., N), i.e. the binary expansion is finite.
The subtlety of the diagonal argument (why it works for reals but not for integers/rationals) is that while it always produces _some_ string of digits, only the real numbers are defined such that the string of digits is itself always a real number. In the integer/rational case, you can construct a number "outside" the set you started from. (In fact you always do if the original list really was of all integers/rationals. Given any enumeration of the rationals, the diagonal argument can actually be used constructively to produce an irrational number.)
I don't quite understand your main concern, but it seems others did and have answered. To elaborate on why Cantor's argument doesn't go through for the integers:
Assume you had a list of every integer. To begin with, you couldn't start flipping bits from the left since integers don't start from the left. You could however imagine them having a sequence of 0s extending infinitely to the left, e.g. 101 = ...00000101. If you did that, the diagonal argument is possible to perform only starting from the rightmost digit, and you do end up with some string of numbers.
The problem is this: If you do walk right-to-left flipping bits in such a list, the integer case has an "out". You do end up with a string of 0s and 1s, but by assumption it can't have 0s extending infinitely to the left because then it would have been on the list. In other words, the thing you end up with never has its "final" 1, and so what you end up with isn't an integer.
This is really the crux of the argument: Not every string of 0s and 1s actually represents an integer. However, put any string of 0s and 1s after the radix point ("decimal point") and that does represent a real number. So what you construct in the real version of the argument really is a real number not on the list (i.e. a contradiction).
It's instructive to do the same thought experiment with an imaginary list of rational numbers written out as decimals and see why the diagonal argument fails in that case too.
Now I described the above as a kind of procedure ("walk right-to-left") but that's really just for convenience. There isn't any actual iteration going on.
This does not – according to what I can see from the code and comments – implement the case of algebraic extensions. As someone only really familiar with the implementation of the transcendental case[1], my understanding is that the algebraic case is where the major difficulty lies.
Indeed. As someone who (in the past) struggled a lot with eating, fasting would not have been a solution - it was the entire problem!
This is the first cookbook I've read that seems to get the effort level vaguely right for a meal you still might be able to make after not eating or drinking anything for 40+ hours. In fact, the "literal depression cooking" meal is close to what most of my meals were, but I rarely even had cheese to add.
To be fair to the author (and I know this is by no means obvious context coming into the video), his channel blew up shortly before this video. His previous audience consisted of people in the Super Mario 64 speedrun/challenge community who would need less explanation.
The thoroughness of this video seems to me to be proof that he wanted to get these newer viewers up to speed. In fact it's basically a love letter to the uninformed viewer. The "complaining" at the start is just lightly poking fun at these newer people while also serving the double purpose of informing them about the explanations in his description boxes. Given the lasting popularity of this video, I don't think too many people took offense.
> Ah, matrices! Does * mean dot product, cross product, or the usually less useful matrix multiplication? Ooh, or maybe you should you use . for dot! How clever that would be!
Why the snark? The fact that you're free to make a bad choice does not imply that having a free choice must be bad. Obviously neither dot nor cross product should be *. It should be the Hadamard product or matrix multiplication. You can choose one convention for your code and be perfectly happy for it.
As a follow-up question: How do you feel about languages like Fortran and Matlab then? Is it actually a good thing that mathematics convenience features are relegated to a few math-oriented languages and kept away from all the others? (Or are the linear algebra types in these languages offensive as well?)
I do my current work (embedded) on an architecture with the following properties:
- 8-bit bytes
- 16-bit aligned accesses to 32-bit types
- 32-bit aligned accesses to 64-bit types.
- Struct alignment depends on the size of the struct (32-bit aligned for >= 64-bit structs)
It's a pretty common architecture in the automotive industry, though probably would be considered esoteric for other applications.
This is not the first platform I've encountered with "unnatural" alignment rules in the embedded space, and I'm sure it won't be the last. (The extra packing this allows is actually quite handy.)
> Normally, I would probably not make these member functions, but since The Witness is a more C++-ish codebase than my own, I thought it was more consistent with the style (and I don’t have a strong preference either way)
My interpretation of this is that normally he'd make plain C structs and functions that operate on them. So quite far from anything people would normally describe or think of as object oriented.
I work on a <500kB RAM embedded project currently (and similar constraints in previous ones), and I can pretty much mirror what you said. The current project is in the planning/early development phase, and it's like everybody forgot the multi-month entire-app refactors we had to do twice to save some small fraction of total RAM in the previous project. But when you're pushing for another release with another too-tight release schedule, suddenly RAM savings are not an immediate but a future problem.
For us the day will come where we atone for our sins and have to again put off feature updates for months of RAM optimization. But in the PC/server/mobile space, that day gets pushed off whenever people move on to better hardware. So why not continue to bloat your applications, really? There's little incentive to do otherwise. If clunky abstractions make your developers ever so slightly happier, what's the reason not to embrace them?
Most people have no idea how to detect basic non-blatant cheats. Even simple low-FoV aimbots sneak past the vast majority of players. Good enough cheats are virtually undetectable by just human inspection.
The few people you saw cheating were probably frustrated enough with the game they decided burn their accounts and ticked enough boxes in their cheat menus to let them go out with a bang. It may of course be that you are particularly good at spotting cheats and Halo Infinite is just blessed to be relatively cheater-free. (I've not played it.) But I'd expect 1-2 orders of magnitude more games to have cheaters than your estimate.
It's worth noting that ISO 26262 is mostly concerned with preventing faults due to system failure, e.g. spurious hardware faults, hardware degradation over time, etc. As an example, it doesn't have much to say about preventing a child from being misclassified as a bollard. It's a quite robust standard, and one most auto makers (certainly the European ones) have spent a lot of effort processing and following for quite some time now (in my limited experience).
There's a separate standard (ISO 21448) trying to address issues with safety of intent, i.e. maintaining safety when there's no actual fault in the system. (Like the misclassification example.) This one's newer, much less effort has been spent developing it, and even less has been spent trying to follow it. Frankly it doesn't have as much to say. (And how could it? Nobody knows how to solve general classification problems, and especially not with something running on some 20 W max control unit.) This part of the problem space is basically the wild west. Some auto makers do a good effort trying to create safe solutions. Others not so much.
In summary, some of the electronics solutions in the car can probably be trusted to do what they're meant to (e.g. airbags). Others (e.g. lane keeping assist, emergency braking) are still still mostly be safe but certainly warrant keeping your hands on the wheel. Anything approaching fully self driving is at best quite dubious at this point though.
Primarily a Windows user here (though not really by choice) and I guess I'll bite - what does it matter what people put on the Desktop? Are there any security implications of not keeping it tidy?
The rest of your points I fully agree with, but that one sticks out as weird to me.
Honestly I'm usually very wary of additions to C, as one of its greatest strengths (to me) is how rather straightforward it is as a language in terms of conceptual simplicity. There just aren't that many big concepts to understand in the language. (On the other hand there's _many_ footguns but that's another issue.)
That said, to me this seems like a great addition to the language. It's very single-purpose in its usage (so it doesn't seem to add much conceptual complexity to the language) and it replaces something genuinely painful (arcane linker hacks). I'm very much looking forward to using this as I often make single-executable programs in C. The only thing that's unfortunate is I'm sure it'll take decades before proprietary embedded toolchains add support for this.
Worth noting that the Devil's algorithm is not a sequence of turns you repeat over and over, but one that takes you through every possible cube state. You "abort" it partway through when you reach your desired state.
None of this is really worth obsessing over I think, but one point in favor of imperative is it tends to also be the tersest phrasing, which is convenient if you're also aiming for 50 characters max.