From: Thomas Walker Lynch
Performing operations with recurrence functions requires integrating a call algebra in addition to integrating the machines. Often this is handled by considering the machines being composed to be subroutines, and the outer controller than explicitly calls them. The call algebra can then be dynamic depending on the input. Calls can be skipped due to being inside conditionals, or performed an arbitrary number of times in loops. Though simple control structures that are static are more math like, and are more likely to be more affected by optimizations (simplifications).
-- Here we circle back to the division by zero problem, though this time while extending functions. Let us begin with the two functions, and . Both have vectors, though the one for the exponential function is defined by a machine rather than by a value on a tape. -
- -- We cannot do function based arithmetic on these until we synchronize them. Suppose that for each call of the machine, there will be three calls to the machine. So we can make a new machine that is called once, each time is called, . -
- -- Now suppose we want to express the quotient of these two functions. -
- - - -- Evaluating this form in the first order at the point returns a . It is a strange thing, because if we make a plot values, against it is a smooth curve. Obviously there is a value for that lies on the curve. However, if we plug in the numbers, and do normal arithmetic, this is what happens at . -
- -- Suppose we move to a second order evaluation, and for places the computation does not work, we return the machine that isn't evaluating. That is similar to what we did to get , but the zeros in that expression came from a prior step first evaluation. Let us return the quotient machine. -
- -| Count () | -Quotient () | -1st Diff Ratio () | -|
|---|---|---|---|
| 0 | -31/15 | -1/3 | -- |
| 1 | -30/12 | -2/3 | -- |
| 2 | -28/9 | -4/3 | -- |
| 3 | -24/6 | -8/3 | -- |
| 4 | -16/3 | -16/3 | -- |
| 5 | -- | 32/3 | -- |
| 6 | -32/3 | -64/3 | -- |
| 7 | -96/6 | -128/3 | -- |
| 8 | -224/9 | -256/3 | -- |
| 9 | -480/12 | -512/3 | -- |
- The quotient machine, , is no more representative of the value we expected here, than was . However, as we have the whole program, we could pass it to a L'Hôpital evaluator and get a value back. But I am wondering if we can't design function extension form that extends to the value and beyond, as most apparently there is a value to extend to. +
+ Here we circle back to the division by zero problem, though this time while extending functions. Let us begin with the two functions, and . Both have vectors, though the one for the exponential function is defined by a machine rather than by a value on a tape. +
+ ++ We cannot do function based arithmetic on these until we synchronize them. Suppose that for each call of the machine, there will be three calls to the machine. So we can make a new machine that is called once, each time is called, . +
+ ++ Now suppose we want to express the quotient of these two functions. +
+ + + +
+
+
+ + Evaluating this form in the first order at the point returns a . It is a strange thing, because when we plot values, against there is an obvious correct value on the curve at . There is no special feature that would make it questionable. +
+ ++ Suppose we move to a second order evaluation, and for places the computation does not work, we return the machine that isn't evaluating. That is similar to what we did to get , but the zeros in that expression came from a prior step first order evaluation. Let us instead give the quotient composer two machines to compose, and have it return a value when reduction to the first order is possible, and return the full problem as posed to it when it can not be reduced. +
+ +| Count () | +Quotient () | +1st Diff Ratio () | +|
|---|---|---|---|
| 0 | +31/15 | +1/3 | ++ |
| 1 | +30/12 | +2/3 | ++ |
| 2 | +28/9 | +4/3 | ++ |
| 3 | +24/6 | +8/3 | ++ |
| 4 | +16/3 | +16/3 | ++ |
| 5 | ++ | 32/3 | ++ |
| 6 | +32/3 | +64/3 | ++ |
| 7 | +96/6 | +128/3 | ++ |
| 8 | +224/9 | +256/3 | ++ |
| 9 | +480/12 | +512/3 | ++ |
+ The quotient machine, , is no more representative of the value we expected here, than was . However, as we have the whole program, we could pass it to a L'Hôpital evaluator and get a value back. But I am wondering if we can't design function extension form that extends to the value and beyond without any hiccups, as most apparently there is a value to extend to.
I included the first difference along with the evaluation results in the table above. When building a first difference table an interesting thing happens at the singularity, the first difference and the function itself coincide, note calls 4 and 5. This makes sense because , which becomes , and the same happens to in the denominator, so the signs cancel. Note also , which becomes .
-Ostensibly it looks like we have happened upon a discrete version of L'Hôpital's rule, that we merely use the first difference quotient instead of the function quotient. But alas, the coincidence occurs at rather than at . For the second coincidence, we find as the 5th first finite difference. In neither case did we learn anything about the value of . +
Ostensibly it looks like we have happened upon a discrete version of L'Hôpital's rule, that we merely use the first difference quotient instead of the function quotient at the singularity. But alas, the coincidence occurs at rather than at . For the second coincidence, we find as the 5th first finite difference. In neither case did we learn anything about the value of .
- Perhaps if we were performing nonstandard analysis, and extending by increments of epsilon in the domain at each step, the nonstandard analysis naturalization function would find that the differential value can be used as the value at the singularity. But here we are discussing finite differences . However, we are not doing a local analysis here so as to derive a principle, but rather are trying to evaluate a function in the macro view. + Perhaps if we were performing nonstandard analysis, and extending by increments of epsilon in the domain at each step, the nonstandard analysis naturalization function would find that the differential value can be used as the value at the singularity. But here we are discussing finite differences . We are not doing a local analysis here so as to derive a principle, but rather are trying to evaluate a function in the macro view.
@@ -1634,7 +1637,7 @@
- The formula successfully computes the differences before . As the second order evaluation returned , we can use L'Hôpital evaluator to resolve this indeterminate form . Note this is during the creation of the vector, so it is part of the simplification step, rather than being part of the evaluation of the quotient. The result will thus be used in producing an extension machine that extends through the singularity, so the user will not see any exceptional higher order values while extending . + As the second order evaluation returned , we can use L'Hôpital evaluator to resolve this indeterminate form . Note this is during the creation of the vector, so it is part of the simplification step, rather than being part of the evaluation of the quotient. The result will thus be used in producing an extension machine that extends through the singularity, so the user will not see any exceptional higher order values while extending .
@@ -1647,9 +1650,7 @@
The resulting vector for the quotient is:
- +
@@ -1658,7 +1659,7 @@
- So the value of is transcendental, but all the machinery we were using, up until using L'Hôpital evaluator was closed over the rational field. That is why no matter how we tried to organize the difference tables, there was no way to find , or to find a table for extending through it. This situation occurred due to introducing the function. Had we remained with finite length tables, i.e. finite degree polynomials, we could have used deconvolution of the vectors, or synthetic division on the polynomials, to create the quotient. + So the value of is transcendental, but all the machinery we were using, up until using L'Hôpital evaluator, was closed over the rational field. That is why no matter how we tried to organize the difference tables, there was no way to find , or to find a table for extending through it. This situation occurred due to introducing the function. Had we remained with finite length tables, i.e. finite degree polynomials, we could have used deconvolution of the vectors, or synthetic division on the polynomials, to create the quotient.
@@ -1726,6 +1727,32 @@ +The fundamental claim of computational analysis is that all functions can be viewed as discrete entities. Take this simple function:
+ + + +It is said to be a continuous function over the real field. However, from a computational perspective, it is a string of 8 discrete symbols. A person might ask how to take a derivative, as that is an operation on continuous functions. The answer is to use a machine that manipulates the symbols; it will move the 3 down in front of the , decrement the power, and write 2. Those are all discrete operations.
+ +The point of this chapter is to state that computational analysis exists, rather than to present a comprehensive computational analysis system. The chapter presents function extensions and difference methods to tie in the Babbage machine and discrete methods, which have a very long history. There is also a brief mention of the connection to nonstandard analysis.
+ +Hans J. Boehm and Robert Cartwright's work of extending the precision of a computation on demand continued to mature. Boehm, while working at Google, authored a Java constructive reals library that powers the bundled Android calculator. When a person types, the system builds an Abstract Syntax Tree (AST) of the expression. The display interface determines how many digits fit on the screen and demands exactly that much precision from the root of the tree. The root function then recursively demands progressively higher precision from its operand functions until it achieves the strict error bounds required to guarantee every digit displayed on the screen is mathematically correct . +
+ +Wolfram Mathematica utilizes a true second order computation system by keeping expressions in their exact symbolic form for as long as possible. An expression like remains an AST of symbols. It then relies on an extensive library of algebraic rewrite rules to simplify the tree. However, unlike Boehm and Cartwright's method of pulling precision through back propagating extension calls, when a numeric result is required, it runs forward using significance arithmetic. Should there be insufficient precision as a result, it employs an adaptive retry loop . +
+ +Lynch's method is to first build the AST and then evaluate the code not for a result, but rather for accuracy and precision loss per step, as a function of the domain. Then the desired result accuracy is propagated back, thus setting the precision for each step. This approach was used on the AMD K5 processor transcendental microcode to guarantee the computations yielded full accuracy. It can also be used to set data bus widths in signal processors, and in applications where neither precision pull nor adaptive significance arithmetic can be employed . +
+ +None of these computation systems, that of Boehm and Cartwright, Mathematica, nor the Lynch error analysis approach, makes use of the IEEE 754 floating point arithmetic standard. Rather they all require the use of variable precision. In the case of Boehm and Cartwright's original system that was through serialization, but their later rational expressions used intermediate variable precision results. In the case of Mathematica it is explicit, though implemented in software. In the error analysis approach, the means for variable precision was specified as High Radix On Line Arithmetic . What would be useful is a hardware standard for variable precision to replace the IEEE 754. This has been proposed by John Gustafson with his posit number representation . +
+ +This section reviews finite difference methods as a means to implement function extensions. A person should notice that finite differences are one among many methods for extending functions, and they are not always the best choice. A common alternative when the extension is for increased precision in an approximation is the Newton Raphson method. In modern computing, rather than computing function extensions, it is more common to increment a value across a domain, completely repeating the evaluation at each step, for example when computing values to place on a plot. However, function extension and difference methods are of theoretical importance for analysis, particularly when applied to nonstandard analysis. These speak to the thesis of computational naturalism in the derivation of mathematics, rather than as a proposed method of implementing computational programs. The book is not finished; we have more theory to cover. +
@@ -2517,7 +2544,7 @@The combination of multiplexing and cell deletion leads to a hazard where one thread can delete a cell the head is on in another thread. We add a collision error continuation to our multiplexed Turing Machine interface because of this situation.
-The modifications to the Turing Machine leading to our TTCA machine were inconsequential, in that for order of complexity and existence proofs we may swap one machine for the other and the results will be the same.
diff --git a/document/singularity_plot.png b/document/singularity_plot.png new file mode 100644 index 0000000..f28eeeb Binary files /dev/null and b/document/singularity_plot.png differ