Posts by bluebadger112

northernviper4 said:? XD

🤣 That wasn't really your fault 😁 Yep, QS is actually an algorithm where the asymptotic complexity is worse than the optimal one—but in practice, it's faster. If I recall correctly, its worst-case complexity is O(n^2), which isn't great. But the expected complexity is n*ln(n).

Gregory Smith21 said:It could be too much data for the machine—it really just comes down to how you write the code and what kind of processor you're running.

Yeah, that’s definitely true—but you can always pick a constant so small that the computer can't even handle it, meaning it just sees it as zero. Honestly, you could fill the entire universe with the fastest parallel processors and memory imaginable, and still choose a constant that's just too tiny. 😁

What I find interesting, though, is the idea of optimal algorithms. Take a meaningful problem that belongs to a non-empty class of algorithms designed to solve it—there's always going to be an algorithm in that group with the best complexity, basically the one that's asymptotically the fastest. For instance, when sorting $n$ items, we know the best complexity for that class is $O(n \log n)$; researchers actually built several algorithms with that complexity and mathematically proved nothing can be "faster."

Then you have these algorithmically solvable problems where finding an optimal algorithm is questionable—maybe even theoretically impossible—even though we know one must exist! And for some problems, we don't even know what the best possible complexity would be, which is its own kind of headache.

When we actually know what the optimal complexity is, the goal shifts to shrinking that constant inside the Big O notation—and people spend a ton of energy trying to do exactly that and publishing their results.
It’s also pretty wild that there are problems solved by non-optimal algorithms that actually turn out to be faster on average in real-world practice than the "optimal" ones. Sorting is one of those cases.

The core question will always be: Can we do better?

EDIT: I used the word trivial earlier, but now I'm wondering if every meaningful problem actually has an optimal algorithmic solution. 🤔 Sure, for a given input, it does, but that doesn't feel like a complete answer to me. 🤔 Man, you really dug deep into this one. ☕

Gregory Smith21 said:If you plug in numbers with more decimal places—up to a certain point—you get a much sharper graph and way more precise results.

Computers are honestly indispensable here. Sure, we could manually calculate an interval like [1,5] by using a step size of, say, 0.2—but if you actually want precision, you’d need that same interval with a step size closer to 1*10^-6. Doing that by hand would take forever. With a computer, you knock it out in a second and end up with a much sharper graph.

The more points you use to evaluate a function, the smoother that graph looks—pretty much a given.
You can only evaluate it using a finite number of points, really. The accuracy of how close the Euler polygon gets to the actual solution depends entirely on the length of the interval. Specifically, if $l$ is the interval length, $f$ is locally Lipschitz in the second variable, $v$ is the Euler polygon, and $u$ is the true solution—you get a uniform estimate $|u - v| < cM(l)$, where $M$ is some strictly increasing function, $c > 0$, and $v$ depends on $c$. Basically, that means choosing the Euler polygon depends on picking a specific positive constant upfront. So, the larger the interval, the worse the estimate gets—meaning you have less of a guarantee that the Euler polygon stays close to the real deal. Sure, you could just pick a tiny enough $c$, but then the sub-intervals needed to define $v = v(c)$ might end up being way too many for a computer to handle.

Everything in a computer is just an approximation—unless we're talking about symbolic repositories, of course. At the end of the day, representing a real number on a machine is really just storing its approximate value.

Proving that Euler polygons actually converge uniformly toward the solution—which is basically the heart of the Peano theorem proof—is no small feat. That said, Euler polygons aren't exactly the best tool for approximating over wide intervals; the error margin depends heavily on the interval width, and apparently, some other methods get bogged down by that issue too, though I don't know much about them.

Gregory Smith21 said:Yeah, totally—every programming language has those core math operations built in. You can basically stitch those basic functions together to tackle complex stuff like differential equations. Since you don't have dedicated operators for integrating or deriving, you just have to combine the basics—like add, sub, div, and Mul eax—to get where you need to go.

All that matters is that the program includes a conditional function—you just define whether you're deriving functions via a lookup table or the standard way—and then let the cmp handle the comparison.

Most people just stick to high-level languages because they're way easier—I mean, solving an equation like that takes dozens of lines in Assembly, whereas in something like Java, it’s much more concise. It really just comes down to how much time you have to spare.

You could always whip it up in a hex editor—assuming you actually know what you're doing and have a serious masochism streak. 😬

Assembly is really more for writing drivers and kernel development—which happens to be exactly where my interests lie.

I'm not sure we were quite on the same page there—I wasn't actually talking about an algorithm that derives or integrates functions. I meant one that returns functions where the derivatives possess a specific property—in this case, $u' = f(u)$ for a given input function $f$. Such an algorithm doesn't need to perform any differentiation or integration, nor does it need to check if the result satisfies the required property (since the algorithm's own correctness proof handles that part). Of course, in practice, an algorithm like this won't return the exact solution—there's just too much data involved, and you run into the classic issue of trying to evaluate a function at infinite points on a computer, which is impossible. But, if you set a specific tolerance, it will find a function that stays within that distance from the true solution (uniformly). If you want to dive deeper, look into the derivation of Peano's theorem; understanding that is pretty much a prerequisite for implementing and proving the correctness of an algorithm like this. Otherwise, there are numerical algorithms out there that can solve practically any partial differential equation, provided you're okay with a tiny bit of error.

Gregory Smith21 said:You’re mistaken—and honestly, a little harsh. I know my stuff—everything from tackling n-th order differential equations to coding in Assembly, but hey, that's beside the point.

Can you actually write an Assembly program that solves a basic first-order differential equation? You know, where the input f(x, y) is continuous and the output is the set of all solutions for something like u' = f(x, u).

That was refreshing ☕

Look, being a little dim isn't the issue—it's being ugly that really stings 🧐

Boat

What do you guys call this thing?

Shirley Quote

Total 🙂

Barrels 🐔

I'm basil 🙂 we had to swap out the glasses every few months—otherwise they’d just start falling out

E: I don't have the link handy, but it was in an issue of National Geographic from last year

A scientific journal actually claims that glass expands over time.

Honestly, this topic is pretty dull—it's time to move on.

LFK, LFK, LFK 🐔

-oo 🙂

-1 ☕

rapidtrucker78 said:Louis, just give me a penalty instead of messing all over my post. 🐔
I can handle that. 🙂

What was even in the original? 🍿

AFK? 🙂

JR LFK? 🙂

Whenever I think about that Hellfire amulet, my whole life flashes before my eyes ☕

p.s. Finally figured out what F and K actually stand for 🙂

LFK, LFK, LFK 🎉 🙂