An exception

I have found one case where the TLC algorithm does not give the 'expected' result. By 'expected' I mean the value given by

The exception occurs when operator ⊡ is equal to PLUS, i.e. the ALU(9,1) case, and γ = 1. The expected result is

However, the TLC algorithm yields something different, for example:

The algorithm yields rational values, which are close to the expected 1/α value.

It's conjectured that, for the ALU(9,1) with γ = 1 case, the actual value given by the algorithm is given by

where b is a parameter in the TLC algorithm (see post of 18th December 2021). Hence, 

It is evident that the larger the value of b, the closer the algorithm's value is to the expected 1/α value. A value of b = 888 was used for the above.

The rational value and that produced by the algorithm agree to large numbers of digits. For example, for the α = 2 example (i.e. 219780/439561), the rational value and the algorithm's value agree to at least 5000 digits; this may reflect the fact that the value is a repeating decimal (period 525).

Finally, we look at the effect that parameter b has on the calculation of  π:

There's a little blip at b = 888; this gives 265 correct decimal places. That's actually two more correct digits than given in the 25th September 2021 post; that result took b = 1023.

Hence there appears to be an optimum value of b - at least for the π calculation.  The TTL implementation allows the user to set b to any particular value.

As mentioned in a previous post, the actual values produced by the TTL implementation may differ from that produced by the above expressions for P and Q, due to the fact that the TTL implementation necessarily uses limited bit widths.

First discovery

Previously, it was mentioned that setting ALPHA = 1, GAMMA = 1, BETA = 10 and omitting the d = d * b operation (OP#1) (as for the calculation of e), and using the exclusive or operation, yields

1.543080634815243778477905620757061682601529112365863704737402...

which happens to be cosh(1).

Hence we state the interesting identity:

where ⊕ means exclusive or, and we replace 1 ⊕ 1 = 0 with 1 (to avoid dividing by zero).

The product in the denominator gives 1, 3, 6, 30, 120, 840, 5040... which is A265376 in the The On-Line Encyclopedia of Integer Sequences (OEIS), Published electronically at http://oeis.org. The proof that the above identity is true is straightforward: even terms of the denominator equal (2n-1)! + (2n)! and odd terms equal (2n-1)!. The former sum to 1/e and the latter to sinh(1), and we recall cosh(1) = 1/e + sinh(1).

And there's plenty more of this type of thing, for example (i.e. setting ALPHA = 4, GAMMA = 4, BETA = 10) gives the following:

Although there might seem to be a preponderance for the exclusive or operation to yield values writable in terms of hyperbolic functions, this is not always the case, for example:

Beautiful methods of reckoning

After a bit of thought, I've managed to come up with two expressions that define exactly what it is that the TLC algorithm (described earlier) computes.

For a given ALPHA, BETA and GAMMA, the algorithm computes one of the following two quantities. P if the d = d * b operation (OP#1) is included, and Q if it is omitted.

In the above, the ⊡ symbol means an arithmetic/logical operator; for the TLC project it's one of those implemented by the 74181 arithmetic logic unit, as listed in the previous post. To avoid division by zero, instances for which γk ⊡ α = 0 are replaced with unity.

(Numerical experiments suggest that the above expressions work for all the arithmetic/logical operations supported by the 74181 as listed in the previous post. An obvious (unanswered) question is this: what other operations does the algorithm work for?)

So, for example, for the π calculation operator ⊡ is A MINUS B (i.e. ALU row 6, column 2). And we set ALPHA = 1, BETA = 20 and GAMMA = 2, and thus compute the quantity given by

where operation OP#1 is included (i.e. in this mode the upper of the two equations is computed (P)). 

Omitting OP#1 (i.e. the lower of the two equations is computed (Q)), gives

where erf (x) is the error function. The first 2504 digits of the value produced by the TLC algorithm are correct. (This constant is mentioned in Finch, Mathematical Constants: 94 (Encyclopedia of Mathematics and its Applications), p. 423.)

Note: the TTL implementation of the TLC algorithm represents the algorithm's different variables using various limited numbers of bits - for example the d = d * b operation (OP#1) uses a 6 bit times 10 bit multiplier to yield a 15 bit result (bit 16 is ignored). This means that the actual value produced by the TTL implementation may differ from that produced by the above expressions for P and Q. This is not always the case, however - the algorithm produces 266 correct digits of π, with or without the TTL implementation's finite bit widths (with parameter b = 888).

On the other hand, ALU(9,1) (i.e. PLUS operation), with ALPHA = 1, BETA = 10, GAMMA = 1, and OP#1 enabled, yields

0.9989875126560917988525143... = 2960/2963 (no limitation on bit width)

and 

1.2202931302994487041321361... (TTL implementation).

As discussed in a later post (26th November), neither of these values agrees with the 'expected' result (unity).

Something interesting

The value g = GAMMA * b ± ALPHA is obtained using the three bit times ten bit multiplier (to give the GAMMA * b), and three 74181 arithmetic logic units to make the addition or subtraction.

But, the 74181 ALUs can do more than addition or subtraction...

Here, I've labelled up the rows and columns: discounting duplicates, there are some 38 different arithmetic/logic operations that are possible. The addition of six switches allows any of these different operations to be used:

Hence the thing calculates g = ALU(row,col,A,B), where row and col are the row and column as per the table above, and A = GAMMA * b and B = ALPHA.

So, we have g = ALU(6,2,A,B) = A MINUS B = GAMMA * b - ALPHA; if we set ALPHA = 1 and GAMMA = 2 (with BETA = 20) we get 3.14159265358979323846264338...

But how about something more exotic?

g = ALU(6,0,A,B) = A ⊕ B = GAMMA * b ⊕ ALPHA, where ⊕ is the exclusive or operation.

Setting ALPHA = 1, GAMMA = 1, BETA = 10 and omitting the d = d * b operation (OP#1) (as for the calculation of e), we get

1.543080634815243778477905620757061682601529112365863704737402...

which happens to be cosh(1). The first 2,236 digits of this result are correct. Discovering that this value is cosh(1) wasn't difficult: I just searched for '1.543080634815' on Google!

And there's a lot more of this type of thing...

...another example: ALPHA = 1, BETA = 5, GAMMA = 1, with ALU(1,2) = A | B = GAMMA * b | ALPHA, where | is logical or; operation (OP#1) (again, as for the calculation of e), we get

0.331224981744493362805940652824580844936569932976054216288429...

This equals I₁(1) + I₀(1) - 3/2 , where I₁ and I₀  are modified Bessel functions of the first kind. The result from the algorithm is correct to more than 2000 digits.

Showing that the above is indeed the sum of a couple of Bessel functions requires substantially more effort than typing a number into Google. More on this later.

Interestingly, it seems that perhaps all the 38 possible ALU configurations yield 'proper' values, some more 'interesting' than others; I'd naively assumed that the logic operations would not produce anything meaningful, but this appears not to be the case at all.

I'll end this post with another bizarre example:

ALPHA = 15, BETA = 10, GAMMA = 1, with ALU(11,0) = A & B = GAMMA * b & ALPHA, where & is logical and; operation (OP#1) (again, as for the calculation of e), we get

1.718281828461073178906616813933686139831054397588246567510596...

It looks like e - 1 = 1.71828..., but it isn't (the numbers differ at the eleventh decimal place).

Rather, the value appears to be equal to

2246953104077 / 1307674367999 

where, even more interestingly, the denominator equals (15! -1). The computed value (1.71828...) and the rational value agree to 672 digits.