Between that paper (I've only read the first 1/3 of it so far) and your reply at the bottom of the first page, I was able to follow along, at least to get as far as V(x)~ * S2 * P~ = V(e^x-1)~ *P~ = V(e^x)~

Jay -

you stopped at it because it was the last one you could decode or the first one, which not?
Well, in case of the latter:
I say
V(x)~ * B = V(e^x) // tetration to the base e

But if
B = S2 * P~
then

V(x)~ * (S2 * P~) = V(e^x) // tetration to the base e

using associativity, we have also

(V(x)~ * S2) * P~ = V(e^x) ~

Now, the multiplication of a powerseries-row-vector with the transposed binomial-matrix adds 1 to its parameter, so we may write

I have prepared a little script which can be used with Pari-tty (just copy&paste it into the syntax-notepad, when paritty has been started and process it line by line). Using paritty (as GUI encapsulating Pari/GP) makes sense, because this allows to see the involved matrices permanently on the screen and how the summation processes work.
One needs also the matrix-definition-files, which provide functions and matrix-constants. I'll attach them - without editing them, however. They can be read in by Pari/GP at the beginning - in fact, the following Pari-tty-script uses this. Rememeber that using Pari-tty you need Pari/Gp 2.2.11, since the low-level communication protocol has a bit changed in the newer versions (you may download this version from my paritty-webspace as well (). Put these files in the standard-directory of your paritty-syntax-folder as created with the paritty-installation. (see http://go.helms-net.de/sw/paritty )

Here is the paritty-script for the "basics-demo".
Gottfried
---------------------

\\ this demo can best be seen, if the window is splitted
\\ horizontally, use the split-window-symbol in the top-tool-bar.
\\ Don't maximize this window, since we show some child windows
\\ at the left side of the desktop
\\
\\ to follow the demo, it's best to send the following lines separately:
\\ position the cursor in that line and click the CAL-button or press
\\ the F2-key
\\
\\ =============================================================

n=20 \\ set dimension for matrices first

\\ get matrix-definitions, -constants and -functions
\r % _matrixinit.gp
\\ here the %-sign is a paritty-meta-tag, which inserts the current path befor the file name.
\\ You may omit it, if the pari/GP-default "path" is set appropriately
\\ The path is set(to my needs) in _matrixinit.gp. You must adapt the first line
\\ in this file first!

%box >chk V(1)~ * S2 \\ column-summing
%box >chk 1.0*V(1)~ * S2 \\ column-summing, float numeric
\\ gives e^1-1 in the second column, and its powers
\\ in the following columns, so we have a powerseries-vector
\\ as an output, the same form as input.
%box >chk2 V(exp(1)-1)~ \\ compare; however in this we didn't care for
\\ quality of approximation

\\ the simple partial summing does not well converge with
\\ geometric series:
%box >chk1 DR*1.0*Mat(V(-2))

\\ for these cases I employ Euler-summation.
%box >chk1 ESum(1.0)*Mat(V(-2)) \\ Euler-sum of order 1 (direct sum) = DR
%box >chk1 ESum(2.0)*Mat(V(-2)) \\ Euler-sum of order 2 (classic Euler sum order 1)
%box >chk1 ESum(3.0)*Mat(V(-2)) \\ Euler-sum of order 3 (classic Euler sum order 2)
%box >chk1 ESum(4.0)*Mat(V(-2)) \\ Euler-sum of order 4 (classic Euler sum order 3)
\\ note, that higher orders give not the fastest approximation. The order must
\\ be appropriate for the order of growth-rate of geometric series

\\ check (output in standard window)
tmp = exp(1)-1
tmp = exp(tmp) - 1 \\ should be the same as in the chk1-box, 2nd column
tmp^2 \\ should be the same as in 3rd column; but Euler-sum had too small order
\\ so approximation above was not optimal. try a better "Euler-order"

\\ as the inverse of S2, which performs (iterable V(x)->V(exp(x)-1) it
\\ should iterable perform x->log(1+x)

\\ since I use the partial-sum display via Euler-sum, the V(x)-parameter
\\ must be supplied in diagonal-format
\\ using dV(1) should thus give V(log(1+1))=V(log(2))
%box >chk1 ESum(1.45)*dV(1)*S1 \\ this looks good,
\\ the consecutive powers are obvious

\\ The same can be done using eigensystem, I don't show it here.
\\ The problem of convergence and appropriateness of order of
\\ Euler-summation gets ubiquituous, once one uses more difficult
\\ parameters. Unfortunately - to aquire better approximations
\\ one needs more terms, aka bigger matrices - but with
\\ dim>20 we need more digits (at least 400 or 800), and dim>32
\\ seem to be impossible to compute using pari/gp builtin-routine.
\\ I implemented an own version of an eigensystem-solver, but with
\\ not much improvement.
\\ Also, the "empirical" approach for finding numerically the eigensystem
\\ has its systematic flaw because it cannot reflect the fact of
\\ finite truncation of the theoretical infinite matrix.
\\ That was the reason, why I searched for an analytical description
\\ (which I found, based on a hypothese about the eigenvalues)
\\ I can show this another time/another script -