Posts by Sandra Green4

bluebadger112 said:I suppose you're right that evaluating a function at more points results in a denser representation of its graph. That seems to be the case.
However, one can only evaluate it at a finite number of points. The accuracy of how closely an Euler polygon approximates the actual solution depends heavily on the length of the interval. Specifically, if $l$ represents the interval length, $f$ is locally Lipschitz with respect to the second variable, $v$ is the Euler polygon, and $u$ is the solution to the initial value problem, then we have a uniform estimate $|u - v| < cM(l)$, where $M$ is a known strictly increasing function, $c > 0$, and $v$ depends on $c$—meaning the selection of the Euler polygon is contingent upon a pre-established positive constant. Consequently, as the interval grows larger, the estimate becomes less reliable; the guarantee of proximity between the Euler polygon and the true solution diminishes. Now, while one could theoretically choose a sufficiently small $c$, doing so might result in an interval distribution for defining $v = v(c)$ that contains far too many segments for a computer to handle efficiently.

It might indeed involve too much data for a computer, though I guess it really just depends on how the program is structured and what kind of processor is being used.

Whether we are dealing with a 32-bit or 64-bit architecture makes a significant difference. Individual mathematical operations are limited by the register capacity of a specific processor. Even during a very basic addition, we encounter these constraints. With 32-bit systems, a single register holds a maximum of 32 bits, which essentially means a maximum input of 4 ASCII characters per register. For 64-bit, it would be 8 ASCII characters.

With 32-bit, the maximum arithmetic processing you can perform involves a four-digit number per operation.

For example,

mov eax, [num1]
sub eax, '0'

mov ebx, [num2]
sub ebx, '0'

In this scenario, the maximum values for num1 and num2 would be 9999. Anything beyond that leads to a buffer overflow, causing the program to crash.

I imagine this issue could be resolved by "splitting" any number larger than four digits and processing them individually.

The situation regarding division and Mul eax is quite similar.

Mul eax, num1

Where the product is split into two segments: Edx serves as the 32-bit high-order segment and eax acts as the 32-bit low-order segment. If the maximum for each register is 9999, exceeding that will trigger a buffer overflow.

If we were to use a constant $c$ that is, say, 0.000000000000000001, we wouldn't calculate it directly as 0...1; rather, we might treat it as 1 and then format it as 0...1 when printing. Such a process requires additional functions because we cannot compute it all at once in a single step due to the massive discrepancy between the number of ASCII characters and the capacity of the processor registers.

In any mathematical software—whether it's something like GeoGebra or WolframAlpha—the underlying processes remain the same. For every complex operation, variables are segmented into smaller parts, which are then processed either serially or in parallel, segment by segment, until the final product is reached.

bluebadger112 said:Everything is essentially an approximation within a computer, unless one is working with certain symbolic repositories. I suppose the way a real number is represented in a computer system is actually just its approximate value.

The proof showing that Euler polygons truly converge uniformly toward the solution—which happens to be the core component of the Peano theorem proof—is quite non-trivial, I believe. On the other hand, Euler polygons might not be the most practical choice for approximations over broad intervals, since the proximity estimate to the exact solution seems to depend on the width of the interval itself; I think there are other methods that handle this better, though I am likely not familiar enough with them to say for sure.

As we input numbers with more decimal places into the function, up to a certain point, the graph becomes more clearly defined and the results become more precise.

In this regard, the computer is absolutely indispensable. One could manually calculate a specific interval, such as [1,5], provided we use a step size of, say, 0.2, but for a significantly more accurate result, it would probably be best to calculate that same interval using a step size of perhaps 1*10^-6. If we were attempting to do that by hand, it would likely take an incredibly long time. With a computer, however, you can resolve this in an instant and obtain a much more well-defined graph.

bluebadger112 said:Hmm, I suppose we might not have been fully on the same page here. I wasn't actually referring to an algorithm that performs differentiation or integration of functions, but rather one that returns functions whose derivatives possess a specific property—in this case, $u' = f(u)$ for a given input function $f$. Such an algorithm doesn't necessarily need to differentiate, integrate, or even verify if $u$ meets the required criteria, provided that the correctness of the algorithm itself guarantees that result. Of course, in a practical sense, such an algorithm generally won't return the exact solution due to the inherent limitations of finite data, which leads to a significant number of hurdles (most notably the impossibility of evaluating a function at an infinite number of points via computer), but for any pre-defined distance, it will find a function that stays within that margin of the true solution (uniformly). If this subject interests you, perhaps looking into the derivation of Peano's theorem might be helpful, as understanding that concept is probably a minimum requirement for implementing and proving the correctness of such an algorithm. Beyond that, there are numerical algorithms capable of solving practically any partial differential equation, albeit with a small degree of error.

It seems to me that finding an exact solution through computer computation is often impossible for certain things, so approximation becomes the necessary route. Even simpler concepts than differential equations require approximation, such as calculating the square root of 2, for instance.

Through programming, one can calculate these types of differential equations, though they remain bounded within a specified interval. For example, using the Euler method, you define your variables and increase them by increments, which should ultimately yield an approximate solution.

For most practical applications, I guess an approximation is more than sufficient.

bluebadger112 said:Do you know how to write an Assembly program that solves a standard first-order differential equation? You know, where the input f(t, u) is continuous, and the output is the set of all solutions in t, such that u' = f(t, u).

That sounds quite interesting ☕

Yes, I suppose that is certainly possible. In any programming language, you are provided with basic mathematical operations, and by combining those fundamental functions, one could theoretically solve complex functions, including differential equations. Since there aren't built-in operators specifically for integration or differentiation, I guess you would have to combine those core arithmetic functions—like add, sub, div, and Mul eax—to eventually reach that goal.

I believe the critical part is ensuring the program includes a conditional function where you define which functions to differentiate via a lookup table, or perhaps just through standard comparisons using cmp.

Most people would probably choose to do this in a higher-level programming language because it seems much simpler. To solve an equation like that, you might end up writing countless lines of code in Assembly, whereas in something like Java, you would likely need significantly fewer. Still, I suppose it is really just a matter of time and effort.

One could even attempt to build it directly in a hex editor, provided they truly know what they are doing and happen to be a bit of a masochist. 😬

Personally, I feel that Assembly is more suited for writing drivers and kernel development, which is where my own interests primarily lie.