change the critical section for tetration/inverses from linear approximation to something more analytical (mostly done!)

[Patashu]

two things to do:

1. handle negative heights. https://en.wikipedia.org/wiki/Tetration#Linear_approximation_for_real_heights has a test case to try.

2. I also haven't tested fractional heights > 1 yet, because I didn't have a worked example for it. BUT, I think it is okay, because http://mrob.com/pub/math/hyper4.html#real-hyper4 talks about it being defined in the same way I do (add one to the height and pow payload to the fraction). But MROB then goes on to define it in a different way that has higher accuracy for 'small' values (greater than 1, less than 1e1e308) which we could use for such cases if it's easy to implement (but it looks not easy lol)

(we could also try the quadratic approximation. https://en.wikipedia.org/wiki/Tetration#Higher_order_approximations_for_real_heights I'm not sure if it actually gives better accuracy or just makes it differentiable, though. And now that I see MROB's version above, I might actually just use that and skip even trying this?)

[Patashu]

now that iteratelog has real height, it should probably get the mirror image of any improvements made here.

It also exposes how rough the linear approximation for tetration for real heights is, by demonstrating the patchiness of its inverse. Being off by 0.1 often just changes the result by 0.1 each time, while having huge, dramatic jumps each time you cross past a new integer number of iterations. A good extension of tetration to infinite heights should have a converse iteratedlog that covers the range of results smoothly and continuously as you shift across the fractional heights, IMO.

[Patashu]

So it seems the literature on this stuff is stronger than the last time I looked at it.

So the basic rroblem we want to solve is iterating a function a fractional amount of times. https://en.wikipedia.org/wiki/Iterated_function#Fractional_iterates_and_flows,_and_negative_iterate

(Related concepts are fractional calculus https://en.wikipedia.org/wiki/Fractional_calculus and fractional hyperoperators.)

Naively, there's more than one way to do this - as long as the original constraints of the underlying operator are satisfied then we could define the actual values to be whatever we wanted. So we usually want additional properties on top of it - like being differential, continuous and/or analytical.

What would be ideal is if there is only one 'natural' / 'best' way to extend iterated function in general, and that approaches based on similar principles gave the same result as it, further strengthening this proposition.

To this end, a very interesting paper exists:

http://tetration.org/IF.pdf 'the existence and uniqueness of the Taylor series of iterated functions'

Which has this great snippet:

'Fractional iteration[8] can be defined using either Bell[1] and Carleman[3] infinite matrices, taking advantage of the fact that the composition of functions can be performed by matrix multiplication. Once a matrix has been diago- nalized, fractional iterates are found by raising the matrix to the appropriate power.'

Pretty promising!

The Citizendium page on Tetration is much more filled out than the one on Wikipedia: http://en.citizendium.org/wiki/Tetration

And here's some exact analytical continuations for slog/tetration, some of which link to exact values, actual implementations, etc:

https://math.eretrandre.org/tetrationforum/showthread.php?tid=1100 links to https://mathoverflow.net/questions/259278/an-explicit-series-representation-for-the-analytic-tetration-with-complex-height and https://gist.githubusercontent.com/VladimirReshetnikov/06d12ab50893850520477a0d99b0278e/raw/3400d283691e59a7a5b366417d0588ea9ec87027/Tetration.nb . It also mentions 'Kneser's solution, a PARI/GP program for which was posted on this forum.' though doesn't link it. Also linked is fatou.gp: http://math.eretrandre.org/tetrationforum/showthread.php?tid=1017 . Schröder's functional equation and Abel's solution are also mentioned a lot, though I'm not sure what they are. We also have http://go.helms-net.de/math/tetdocs/ContinuousfunctionalIteration.pdf and http://mathoverflow.net/q/259467/9550 linked.

We also have:

http://skysrv.pha.jhu.edu/~neyrinck/extessay.pdf https://web.archive.org/web/20090201164836/http://tetration.itgo.com/paper.html two papers on analytical continuations/approximations for tetration and slog and weak pentation

I also looked up fractional hyperoperators for fun, here's some additional stuff about that:

https://www.reddit.com/r/math/comments/1l5952/noninteger_hyperoperations/ https://math.stackexchange.com/questions/1350025/hyperoperation-sequence-with-non-integer-values-of-n http://andydude.github.io/tetration/archives/tetration2/hyper.html https://www.hindawi.com/journals/mpe/2016/4356371/ https://math.eretrandre.org/tetrationforum/showthread.php?tid=876 https://www.physicsforums.com/threads/generalization-of-hyperoperations-fractional-operations.485870/ fractional hyperoperators - real, continuous, negative, complex
0.5 is 'halfation, 1.5 is 'sesquation'. 1.5 has the Arithmetic-Geometric mean or Gauss mean ( http://mathworld.wolfram.com/Arithmetic-GeometricMean.html )

Dream goal would be: hyper(x, h, y), invhyperL(h, y, result), invhyperR(x, h, result), invhyperH(x, y, result) defined for all complex values including 0 and all complex infinities. This would be a superset of all operators except for

1. some special ones (gamma and lambertw come to mind)

2. non-continuous ones (abs/sign, round etc, cmp etc, clamp etc)

[Patashu]

Ok, aside from still using the linear approximation, I've improved this area a LOT.

[Patashu]

Okay, here's something actually actionable - approximating the analytical section for slog and tetration separately by linear interpolating to the nearest base and nearest 0.1 value. When I feel in the mood to do a bunch of dirty work, I'll give this a try.

1:36 AM] SpectralFlame: heya, I've got Mathematica... whatcha need me to run?
[8:19 AM] Patashu: Hey SpectralFlame, so I want to improve the accuracy of tetrate/slog to continuous heights in break_eternity.js, right now I'm using the linear approximation which is as quick but as lazy as it gets, ideally I would like to use the analytical approximation but one it's slow, two all implementations of it are in languages I can't really translate into js. So what I'd like to do is get a grid of exact values of slog for the critical section - from bases 1 to 10 in increments of 1 (starting actually at 1 plus epsilon actually since 1 is invalid), from values 0.0 to 1.0 in increments of 0.1, for 110 values of total. Then whenever I need to calculate slog to a base between 0 and 1, I can linearly interpolate on this rectangular grid to find an approximation of the nearest value, and if the base is above 10 I'll just fall back to the old linear approximation. The code is in this paper here: http://tetration.itgo.com/pdf/TetrationSuperlog_Pages_22-27.pdf
[3:15 PM] SpectralFlame: Alright, I ran the code in that link and produced a list of base,value,slog_base(value) separated by newlines. It's the 15th approximation, which seemed to look pretty smooth and converged. I'm not really sure how much you can "trust" the base 1+epsilon values though since they seemed to be a bit weird. Lemme know if you need me to run it again or anything!
Attachment file type: document
SLog_values.txt
3.52 KB
[3:16 PM] Patashu: ooh, yummy! let me graph these to make sure they look how I expect...
[3:22 PM] Patashu: and yeah I think I'll use linear approximation outside of the 2-10 base range I guess I'll clamp base if it's outside the 2-10 range actually, base 2 is more accurate than linear approximation for 1-2, and base 10 is more accurate than linear approximation for 10+
[3:24 PM] Patashu: Yeah this looks accurate, tyvm!
[3:25 PM] SpectralFlame: great, glad I could help!
[3:53 PM] Patashu: hmmmm, I'm starting to think I also need the numbers but for tetrate(base, z) instead of slog(base, z). because, for example, if I get tetrate(base 10, height 1.5) I need to determine 'what number could I output that, if slogged to base 10, returned 1.5' which requires knowing 'what number slogged to base 10 returns 0.5' then tetrating that once, which is the inverse operation of the slog thing
[3:54 PM] Patashu: does that makes sense? I think it makes sense - because calculating slog10 is just log10ing until you're on the critical section (0-1) then applying your Super Duper Slog Critical Section approximation, so if you know the inverse of the critical section values, then you can just handle the integer part by 10^ing an integer number of times as normal
[4:22 PM] SpectralFlame: here's the same values for base,value,base^^value according to the code from that link. I... think that makes sense? I can't say I have a good intuition for this stuff though, like 5^^0.3 is... huh?
Attachment file type: document
Tetrate_values.txt
3.18 KB
[4:22 PM] Patashu: Yeah continuous height tetration is funny because it stops corresponding to anything physical
[4:23 PM] Patashu: The basic idea is, similar to how real height exponentiation continues to satisfy the exponentiation laws and be analytical (continuous and infinitely differentiable), we want a similar thing
[4:24 PM] Patashu: We can define it as basically anything and have it be continuous and satisfy the laws, but it's believed there's only one true tetration that is also analytical, though iirc it is not yet proven
[4:25 PM] Patashu: And ty! Hopefully I can make something useful with these numbers
[4:25 PM] SpectralFlame: Good luck! 😁
[4:26 PM] Patashu: I suspect it'll end up not inverting in general (the linear interpolation step will introduce slight errors, if I had the value of the function for all numbers it still would be obviously) but I'm happy to take that sacrifice for more mathematically meaningful results otherwise

Here are the files:

https://www.dropbox.com/s/b64l6p3alrk634d/Tetrate_values.txt?dl=0

https://www.dropbox.com/s/biyauons6sxlovs/SLog_values.txt?dl=0

[Patashu]

finally giving this a real shot today.

using some other worked numbers to sanity check myself, helpfully they go to -1.1 and 1.1 (should have asked for this sooner since it really helps me guess check my math, lmao): https://www.researchgate.net/figure/Tetration-F-its-derivative-and-its-inverse-at-the-real-axis_tbl1_242323767

Basically I'm figuring out my tetrate turns the top into e^0.1 when it should be turned into e^^0.1, which is a value in this table! Similarly, slog uses e^0.1 in its critical section but should use e^^0.1 instead.

tetrate: 'Instead of ++height and the top becomes the fraction, the top becomes a table lookup.'

slog: 'so we go in and do slog_e(1.11211143309340) and I should get 0.1 back out (or very close).
first, since it's above 1, I do log_e once. the value is now 1+slog_e(0.10626040042410934235).
looking at the critical section, interpolating between index 0.1 and 0.2, we should spit out -0.9001415804266892.
1-0.900 is 0.1. Wow! We have a workable solution.'

[Patashu]

OKAY! Got everything working except weird edge cases! (for tetration in particular: bases <= 1.5 and negative heights in general. haven't poked at slog edge cases yet) This is exciting.

List of unsolved edge cases:

• Can we do better than the linear approximation for 0 tetrated to real heights? Or for anything between 0 and e^(1/e), for that matter. Is it correct for 0^^2 to be 1, 0^^3 to be 0, etc? Or should this whole subject be 'here be NaNs' on all non-integer heights because it's all complex numbers under the hood?
• Would love to have critical section slog/tetr for base 1.5, so that the approximation for smol bases is more accurate.
• I would also love to have it for some very large bases (11, 100, 1e10, 1e100, 1e300, 1e1000, ee10) since those seem to be better approximated by the linear approximation than by just using base 10's values. For now I've gone back to the linear approximation for bases > 10. (note: it'd be especially cool if I could derive the critical section for other bases knowing the ones I do, but I think it's not so easy)
• haven't done much testing of iterated exp/iterated log where height is real AND payload is not 1. not especially confident on how this should even work
• I think negative height tetration is already correctly handled. But I'd love to poke and prod at the edge cases and decide for sure (EDIT: I feel pretty happy with this)
• also check negative bases (EDIT: I think the only thing we'd have to do is make all fractional heights NaN automatically, but not sure, hard for me to reason about atm)
• also check very big bases and very small bases (EDIT: both seem fine)
• also check weird edge cases in slog (base < 1.5, base < 1.44, base == 1, base < 0.06, base == 0, base < 0, very small base, very large base, any of the above with a very small, very large, 0, 1 or negative payload) (probably nothing fine but have not checked yet) (EDIT: all bases above 1 seem to work fine. 0 < base < 1 is extremely weird and needs a better understanding to solve it. I think negative bases shouldn't work at all. Big bases seem to work fine.) (TODO: I'd like to know values of tetrate for base 0<b<1 and height -1>h>-2, and slog for base 0<b<1 and arg inf>a>1)
• even when the result of tetrate/slog should be complex, it would be interesting to be able to compute just the real part somehow.

[Patashu]

Oh neat, I found a javascript implemented complex tetration calculator:

http://myweb.astate.edu/wpaulsen/tetcalc/tetcalc.html

It doesn't let me pick an arbitrary base (and the reason why is because it has a bunch of pre-calculated values that it doesn't also have the code to calculate). So this is not even something I can dump into my solution, but it lets me get a second opinion on the bases we have in common, and so far so good!

It also informs me that e.g. 0.25^^real height is probably NaN (complex number), and by inference same for 0^^real height. I may or may not actually do that, not sure.

[Patashu]

documenting a slight inaccuracy in real height iteratedexp/layeradd10/layeradd:

ground truth:

Decimal.pow(10, Decimal.pow(10, 9.9)).toString()
'1.7491284084036844e7943282347'

new Decimal(10).iteratedexp(1.9999999999999, 9.9).toString()
'1.9281592428106278e8278628008'
new Decimal(10).iteratedexp(2, 9.9).toString()
'1.7491284084036844e7943282347'
new Decimal(10).iteratedexp(2.0000000000001, 9.9).toString()
'2.511305123738677e8278628008'
new Decimal(9.9).layeradd(1.9999999999999, 10).toString()
'1.9281592428106278e8278628008'
new Decimal(9.9).layeradd(2, 10).toString()
'2.2002405737485753e8278628008'
new Decimal(9.9).layeradd(2.0000001, 10).toString()
'3.2270327105385297e8278685426'
Decimal.layeradd10(9.9, 1.999999999999999).toString()
'2.1966440161326095e8278628008'
Decimal.layeradd10(9.9, 2).toString()
'1.7491284084036844e7943282347'
Decimal.layeradd10(9.9, 2.00000000000001).toString()
'2.230469563186759e8278628008'

so, the only ones that are right are 10.iteratedexp(2, 9.9) and 9.9.layeradd10(2). but like I said, am I just chasing shadows? if I'm using a critical section for slog that isn't innately 100% accurate on its linear approximation, then I'm not actually very far off (just that the slight inaccuracy gets exponentialified). If this is something that'd vanish if my slog critical section is more accurate, then I'm not super worried about it.

also of note is this test, which varies the other numbers and shows that the ones that get it wrong are 9.9.layeradd(2, 10), 9.9.layeradd(2, 9.9999999), 9.9000001.layeradd(2, 10), 9.899999.layeradd(2, 10) while everything else is right:

new Decimal(10).iteratedexp(2, 9.9).toString()
'1.7491284084036844e7943282347'
new Decimal(10).iteratedexp(2, 9.9000001).toString()
'1.7839114417828195e7943284176'
new Decimal(10).iteratedexp(2, 9.8999999).toString()
'1.7165570477705672e7943280518'
new Decimal(10.000000001).iteratedexp(2, 9.9).toString()
'2.8290467816350198e7943282355'
new Decimal(9.9999999).iteratedexp(2, 9.9).toString()
'2.294470548309746e7943281526'
new Decimal(9.9).layeradd(2, 10).toString()
'2.2002405737485753e8278628008'
new Decimal(9.9).layeradd(2, 9.9999999).toString()
'1.3738353430015828e8278626814'
new Decimal(9.9).layeradd(2, 10.000000001).toString()
'2.829258009414767e7943282355'
new Decimal(9.9000001).layeradd(2, 10).toString()
'1.3353880653740453e8278629580'
new Decimal(9.899999).layeradd(2, 10).toString()
'3.3654589393259977e8278612290'
Decimal.layeradd10(9.9, 2).toString()
'1.7491284084036844e7943282347'
Decimal.layeradd10(9.90000001, 2).toString()
'1.3920071687276492e7943282530'
Decimal.layeradd10(9.89999999, 2).toString()
'2.197724778692615e7943282164'

tetrate and slog itself is continuous, e.g.

Decimal.tetrate(9, 1.99999999).toString()
'387420270.7840655'
Decimal.tetrate(9, 2).toString()
'387420488.99999946'
Decimal.tetrate(9, 2.00000001).toString()
'387420790.82742584'
Decimal.tetrate(9.000000001, 2.5).toString()
'1.0288255544662661e189'
Decimal.tetrate(9, 2.5).toString()
'1.0288253426669234e189'
Decimal.tetrate(8.9999999999, 2.5).toString()
'1.028825320756786e189'

Decimal.slog(10.5, 10.5).toString()
'1'
Decimal.slog(10.5000000001, 10.5).toString()
'1.0000000000017226'
Decimal.slog(10.49999999999, 10.5).toString()
'0.9999999999995951'
Decimal.slog(10.5, 10.5000000000001).toString()
'0.999999999999996'
Decimal.slog(10.5, 10.499999999).toString()
'1.0000000000172253'

tl;dr I think this is just because slog and tetrate are no longer exact inverses of each other, and if in the future we added more precision the problem would go away

[Patashu]

ok, this is my TODO list is now:

1. get more critical section grid values (in particular: 1.45, 1.5, 1.75, 11, 100, 1000, 1e10, 1e30, 1e100, 1e300 and 1e1000 and beyond if possible to compute)
2. understand the tetr/slog critical section better for 0 < base < 1 and base < 0; decide if we want to return NaN for any complex value or approximate just the real part (bases to get: 1.44, 1.1, 1, 0.9, 0.5, 0.1, 0, -0.1, -0.5, -0.9, -1, -1.1, -1.5, -1.9, -2, -2.1 AND we now need height -1>h>-2 for tetrate and arg inf>a>1 for slog to help understand it)
3. I could stuff part of http://myweb.astate.edu/wpaulsen/tetcalc/tetcalc.html into break_eternity.js to get exact values for some critical sections and stuff like that. (This likely solves 4, at least for bases 2/e/10/any other base we can pre-compute values for)
4. think about if there's any way the 'slight inaccuracy in real height iteratedexp' can be fixed, because tetrate/slog no longer are 100% accurate inverses of each other (see previous post)

[Patashu]

OH before I forget, a 5. is that I want to explore if instead of linear interpolation on the tetration critical section, it should be exponential interpolation (e.g. linear on the exponent in layer 1 representation). it might be more accurate for the intermediate heights like .85 and .95, and it might let me clean up/refactor some code for handling <2 and >10 bases

[Patashu]

Another random note to myself (6): I could use the tetration calculator to make the critical sections for 2, e and 10 have more values in them (e.g. 20 or 100). But then when interpolating between bases, it needs to be smart enough to know that different arrays have different sizes. But I think it's possible. But it's probably not worth it unless I also make the slog critical sections bigger. But I could use the tetration calculator to guess-and-check inverses painstakingly. But I probably won't.

I could also, as an even crazier idea (7), make the slog critical section an inverse of my tetration critical section, whatever it is. It would be inaccurate for actual slog, but it'd be accurate for my approximation of tetration. And I could automatically generate values using my code. I think first I'd have to decide if I want to change the linear approximation to exponential or not first, though.

[Patashu]

#108 --> several issues were raised and fixed

todo list progress: 1-3 are still open, 4 might be fixed but needs double checking, 5 is closed, 6 is open, 7 is closed (superceded by slog iteration algorithm)

I'll also throw in an (8) implement continuous pentation and non-integer hyperoperators. I think someone over in https://math.eretrandre.org/tetrationforum/forumdisplay.php?fid=8 has continuous pentation defined, maybe it could be used to define a critical section for pentation? As for non-integer hyperoperators, I think math has not advanced far enough for us to know how this stuff works yet.

[Patashu]

New tetration idea - in the critical section, we can take frac to a power > 1, and this should make it grow slower at first and quicker later, and better match the curve.
If I do this, I should add more points to ground_reality unit test (both bases and heights), and as I'm increasing the power constantly try to tighten the accuracy, to make sure no point gets worse as I'm doing this.

[Patashu]

https://www.sligocki.com/2022/06/25/ext-up-notation.html

Continuous tetration spotted in the wild, at https://wiki.bbchallenge.org/wiki/BB(6)#CryptidsBus