(06/08/2022, 04:27 AM)Daniel Wrote:(06/08/2022, 03:24 AM)JmsNxn Wrote:(06/08/2022, 02:35 AM)Daniel Wrote:(06/08/2022, 01:54 AM)JmsNxn Wrote:(06/08/2022, 01:14 AM)Daniel Wrote: Very cool, given you are getting out to \( z^{100} \) is impressive.
Honestly, all the heavy lifting is done by pari-gp. Granted it's not as user friendly as mathematica, or matlab, but it's a far more powerful language. Especially when you want to iterate exponentials, very large values are much better handled in pari-gp.
See Schroeder Summations for how I derive the Taylors series for an iterated function.
Oh yes, the dreaded matrix coefficient approach. I apologize but I refuse to do that on principal. The majority of my code is recursive in nature, I come from a hard C programming background--only use recursion and basic tools. So much of my code never, and I repeat never uses matrices. I think this is very important just on principle. If you use Sheldon's fatou.gp for example. It's an absolutely beautiful program, and works unbelievably well. But it doesn't account for Taylor series within Taylor series. This is because it uses the matrix approach to grabbing taylor series (essentially, Sheldon has a fuck ton of finesse to it). I don't like that.
When I calculate, for example \(\text{Iexp(s,z,y)} = \exp^{\circ s}_{y^{1/y}}(z)\), I want it to be evaluated recursively, and solely through taylor series. This allows us to add polynomials as input, and it doesn't lag at all. It runs at a reasonable speed.
...
No, I don't use matrices, please clarify why you think so. The software is a proof of concept that total partitions are the combinatorial structure that comprises all iterated functions. I enumerate the total partitions, assigning an algebraic expression based on a recursive application of Faa Di Bruno's formula. The algebraic expressions are then assembled into the Taylors series of an iterated function.
Oh I apologize. I didn't clarify.
I didn't mean matrices in the mathematics. I'm well aware you are using Faa Di Bruno's method of constructing iterations. What I meant is the manner you are programming it (whether inadvertently or not) is using a matrix algorithm. It's storing matrix solutions as \(Ax = b\). I don't mean your mathematics is doing that. I mean the code is doing that.
You are solving arrays of solutions, which give you the Taylor values. But then, you are asking to the program to solve \(100\times100\) or however values, of linear solutions. By matrix I solely meant in the manner of programming. Not the mathematical idea. I'm well aware Faa Di Bruno has nothing to do with matrices. But the program you are calling is certainly matrix-y in nature.
I apologize, I have an odd way of talking about things... I'm not trying to insult your program. But it is based off array/nested array calculations, which is "matrixy-y" in my book, lol.
EDIT:
You are looking at a vector of taylor coefficients \(c_j\), and multiplying it by \(Ac_j\)--and this is how you've encoded \(F(z)\) next to \(f(F(z))=F(z+1)\). Albeit how you've done it is very good. Honestly, I always though Faa Di Bruno was too hard to be practical. Hats off to you. But the code is clearly matrix based, and based off of solving matrix equations in the taylor coefficients.
This is very different than how I code. That's what I meant. Everything is a forloopy/looping/recursive polynomial into a polynomial.
I hope this makes sense. I just meant, I hate matrix shit, largely because I have an irrational phobia. Not to disannounce your code. But your code is matrix based.

