What comes next? - Representing larger numbers than break_eternity.js in a meaningful way

[Patashu]

What comes next? - Representing larger numbers than break_eternity.js in a meaningful way

[1231234md5]

so you can make break_reality to 10^^^1000 by making layer (break_reality) Decimal.

[1231234md5]

so you can make break_reality to 10^^^1000 by making layer (break_reality) Decimal.

much smaller than your 10{1.79e308}10,which exceeds OmegaNum(10{1000}10)

[1231234md5]

had a break_reality.js idea: basically the format builds off of break_eternity.js. we go from (sign, layer, mag) to (sign, arrows, layer, mag). when arrows is 1, behaviour is the same as break_eternity.js. (and I don't think arrows of 0 or lower is supported, and non-integer arrows/layer definitely still isn't) at some point while climbing break_eternity.js represnetation (maybe at layer 10, 9e15 or 10e10), arrows goes from 1 to 2 and we normalize. normalization should be similar to break_eternity.js, in that you can always tell if one number is larger than the other quickly by comparing its numbers in order. internal representation is sign*(10(^){arrows times}){layer times}mag. for example, layer 5 and arrows 1 is sign10^10^10^10^10^mag. and layer 5 and arrows 2 is sign10^^10^^10^^10^^10^^mag. I know e.g. that 10^10^10^10^10 is the same as 10^^5. But I'm not sure how much it changes by if the mag is less than or greater than 10 (would need to figure out some identities) This would let you get all the way up to 10^{1.8e308 arrows}10 (or f_1.8e308(n) in the fast growing hierarchy, or 3 -> 3 -> 1.8e308 in chained arrow notation. I think it doesn't even come close to 3 -> 3 -> 3 -> 2 ~= f_w(f_w(27)). As with previous libraries, just stuffing the the library in in its own fields doesn't get you that much more new ground, you'd have to decide on a new more compact larger number representation instead.) Hard part is, of course, the usual - normalizing and comparison, being able to prove that the system is mathematically sound, being able to provide good enough approximations of higher-than-exponentiation operators especially for real base and exponent, and finding meaningful functions to call on such massive numbers. It sounds fun, but I don't know if I'll sit down and do it. I'm also not a googology expert, so I'm not sure if there's a better internal representation to use here (like the fast growing hierarchy for example). And I DEFINITELY don't know what comes 'after' this.

Other notes:

In break_eternity.js, it's smooth and continuous (every slightly bigger value is representable, there are no 'gaps'). It would be nice if break_reality.js had the same property - that is, once arrows is at 2 or higher, the combination of layers and mag smoothly represents every value between the next value of arrows. I haven't put any thought into if this is true, or if it's not how hard it'd be to hack in. What I suspect is that arrows/layer will be smooth, but at arrows >= 2 layer/mag is no longer smooth unless we make mag start meaning a different thing. (Like, optimally it'd be able to represent the fractional part of layer from .00 to .99, right? Like in break_eternity.js range. But the thing is that at arrows >= 2, the mag is by far an extremely unimportant part of the calculation compared to the layers and especially compared to the arrows. So maybe we just ignore mag after that point (except for whether it's positive or negative?) and have layers be able to vary fractionally?)

we can make break_equality.js by extending to (sign,layer,mag,arrows,depth),whis is sign*10{10{...{10{(10(^){arrows times}){layer times}mag}10}10}...}10(depth pairs of brackets).
but can it be extended again?

[Patashu]

Writing down some thoughts on the matter since I dreamed about it.

Ok, so the main problem with the hypothetical break_reality.js is that I would want a way to smoothly and continuously measure the growth of numbers across the representable range.

For break_infinity, this is log, and it works great.

For break_eternity, this is slog, and it now works as well as its tetration implementation, which is pretty good in most cases and if I wanted to make it perfect for most cases Iknow what I'd try to do next.

For break_reality, this would be... let's call it reality_log. It'd be a number from 0 to 1e308, and it'd be equal to 'arrows, plus a fractional component .0->.99 that consists of how close all the previous fields make us to the next arrows'. Or in other words, we'd have to estimate with arbitrary precision continuous hyperoperators, since that is what it would mean to have a number be 10.5 arrows or whatever.

And the problem with this is that I think the relevant body of math has not advanced far enough to rigorously define what continuous hyperoperators are for arbitrary arguments. If I am wrong, then great, this library could be defined with some meaning. Perhaps in the future it will be possible.

And then for this hypothetical break_equality that would come next, you'd need 'equality_log', which would be straight up a measurement of a fractional continuous iteration of 'plugging hyperoperator into itself', which seems even more absurdly far away from the cutting edge in mathematics from defining with any rigor.

break_reality takes you from f_n to f_w, break_equality takes you from f_w to f_w+1. After this we have an even bigger problem - if we just keep going from f_w+1 to f_w+2, +3 and so on with each successive number library, we're adding basically nothing. So either we have the 'array of numbers' and go to f_w+1000 with 1000 numbers, or we go from f_w to f_2w by defining the next field (no idea what you'd even call it at this point) which defines how many times we iterate... +1ness... over the... I don't even know. Googology breaks my brain past f_w+1, I kind of get it but not well enough to reason about it. And this 'break_celestiality' would need a 'celestial_log' and we are going hopelessly far away from our dreams of ever defining this with any sort of sense. (And hell if I know what .toString would even look like at this point, lmao.)

[Patashu]

putting this here since it's meaningful here too.

articles on fractional hyperoperators:

https://www.hindawi.com/journals/mpe/2016/4356371/ Fractional Mathematical Operators and Their Computational Approximation
https://math.stackexchange.com/questions/1269643/continuum-between-addition-multiplication-and-exponentiation Continuum between addition, multiplication and exponentiation?
https://math.stackexchange.com/questions/107245/continuum-between-linear-and-logarithmic continuum between linear and logarithmic
http://tetration.org/Ackermann/index.html http://tetration.org/Dynamics/index.html tetration.org - Continuous Ackermann Function and Continuous Iteration
https://math.stackexchange.com/questions/1227761/example-x-y-and-z-values-for-x-uparrow-alpha-y-z-where-alpha-in-bbb/1241979#1241979 On non-integer rank Hyperoperations
https://arxiv.org/abs/2106.03935 A Family of Bounded and Analytic Hyper-Operators

[XnoobSpeakable]

break_reality takes you from f_n to f_w, break_equality takes you from f_w to f_w+1.

wait isn't break_reality and break_equality just OmegaNum and ExpantaNum?

[Patashu]

Yeah, but that doesn't mean I can't take my own crack at it. (Though if the thread is anything to go by, don't get your hopes up.)

In particular, the way OmegaNum has a giant array of 1000 numbers for the first four hyperoperators is a design decision that I don't like. I want something that with a finite number of numbers can tell me quickly and accurately which of two numbers is higher all the way up to 10 (hyperoperator 9e15) 10 or even beyond. I also want some kind of meaning or reason to use hyperoperators this massive, and I'm not sure what that is yet (kind of more of a subjective argument).

[Naruyoko]

I admit that OmegaNum's inner representation isn't very efficient. It is painfully slow, so much so that ExpantaNum (which stores the nonzero elements) can be faster when calculating, say, {100,100,200}. It is also bad with representing numbers such as 10{50}1e20, which will have the array representation mostly filled with 0s in OmegaNum, and this applies for majority of numbers representable. Oh course, my standardize function is also horrible and seriously harming the performance, but I can see how the design itself may not be sound.

Also, one thing I would like to add to my libraries is the small numbers (the reciprocals of the large numbers). I am thinking that, after refactoring and migrating code to TS, I can extend them by representing them by negative index 0, in the same way as BE.

[Patashu]

Good luck!

Oh, yeah, I forgot the other thing that I'd want from big number libraries beyond break_eternity - all numbers in the range from smallest to largest should be representable somewhere with error that only goes up monotonically as magnitude increases (e.g. there's no stretches where a large chunk of real numbers aren't representable by any nearby state). I haven't thought about OmegaNum/ExpantaNum hard enough to know if this is true or false, admittedly, but I would definitely demand it be true of my own hypothetical libraries.

[jakub791]

In Incremental games once it switches to displaying F notation (like 1F10) numbers become meaningless - to increase them in a meaningful way you can only use inflationary formulas. So the question is: do we need a bigger library?

[Patashu]

This is something I think about too. It's why I'm trying so hard to implement analytical tetration and its inverses in break_eternity.js, because if past a certain point there's no continuous, gradual kind of math to do on your number library I'm not sure what the point is. (That said, even if I didn't, I'm really happy with the way it handles the transitions from layer 0 to 3 and -3, where the elementary operators we're familiar with are still capable of doing interesting things.) It's also why I think the 'killer feature' of a f_10+ number library is continous hyperoperators and their inverses.

[1231234md5]

Yeah, but that doesn't mean I can't take my own crack at it. (Though if the thread is anything to go by, don't get your hopes up.)

In particular, the way OmegaNum has a giant array of 1000 numbers for the first four hyperoperators is a design decision that I don't like. I want something that with a finite number of numbers can tell me quickly and accurately which of two numbers is higher all the way up to 10 (hyperoperator 9e15) 10 or even beyond. I also want some kind of meaning or reason to use hyperoperators this massive, and I'm not sure what that is yet (kind of more of a subjective argument).

You CAN represent f_(w+1)(9e15) in 4 or 5 numbers (and make a BIG depth[] array to represent f_w2(1000) or bigger), but is this meaningful? Even in inflated^(10^^^^10) incremental games, the number couldn't go to f_(w+3)(10).
And there is another question: Can you format it?

[1231234md5]

Yeah, but that doesn't mean I can't take my own crack at it. (Though if the thread is anything to go by, don't get your hopes up.)
In particular, the way OmegaNum has a giant array of 1000 numbers for the first four hyperoperators is a design decision that I don't like. I want something that with a finite number of numbers can tell me quickly and accurately which of two numbers is higher all the way up to 10 (hyperoperator 9e15) 10 or even beyond. I also want some kind of meaning or reason to use hyperoperators this massive, and I'm not sure what that is yet (kind of more of a subjective argument).

You CAN represent f_(w+1)(9e15) in 4 or 5 numbers (and make a BIG depth[] array to represent f_w2(1000) or bigger), but is this meaningful? Even in inflated^(10^^^^10) incremental games, the number couldn't go to f_(w+3)(10). And there is another question: Can you format it?

also, even with a big library representing numbers up to f_w2(10), the numbers can't go that high. If they go that high, then, addition,multiplaction,exponantation,tetration,.....all the hyperoperators up to {ee9e15}(?)(and even expansion?) can be meaningless:it "cannot change the number", which means it can only change the number a little.

[1231234md5]

Had a idea with the "reality_log"(I call it hlog):
first, you need a number in (sign,layers,arrows,mag) notation (it means sign*((10{arrows})^(layer) mag) in OmegaNum toString()). Then, the number can be expressed in sign*((log10(mag)+layer)J(arrows)) (credit to @cloudytheconquerer doing the J format). So hlog(|number|) is log5((log10(mag)+layer)/2)+arrows. (But wait! it has an error calculating hlog(1). It says "-Infinity".)

[1231234md5]

Writing down some thoughts on the matter since I dreamed about it.

Ok, so the main problem with the hypothetical break_reality.js is that I would want a way to smoothly and continuously measure the growth of numbers across the representable range.

For break_infinity, this is log, and it works great.

For break_eternity, this is slog, and it now works as well as its tetration implementation, which is pretty good in most cases and if I wanted to make it perfect for most cases Iknow what I'd try to do next.

For break_reality, this would be... let's call it reality_log. It'd be a number from 0 to 1e308, and it'd be equal to 'arrows, plus a fractional component .0->.99 that consists of how close all the previous fields make us to the next arrows'. Or in other words, we'd have to estimate with arbitrary precision continuous hyperoperators, since that is what it would mean to have a number be 10.5 arrows or whatever.

And the problem with this is that I think the relevant body of math has not advanced far enough to rigorously define what continuous hyperoperators are for arbitrary arguments. If I am wrong, then great, this library could be defined with some meaning. Perhaps in the future it will be possible.

And then for this hypothetical break_equality that would come next, you'd need 'equality_log', which would be straight up a measurement of a fractional continuous iteration of 'plugging hyperoperator into itself', which seems even more absurdly far away from the cutting edge in mathematics from defining with any rigor.

break_reality takes you from f_n to f_w, break_equality takes you from f_w to f_w+1. After this we have an even bigger problem - if we just keep going from f_w+1 to f_w+2, +3 and so on with each successive number library, we're adding basically nothing. So either we have the 'array of numbers' and go to f_w+1000 with 1000 numbers, or we go from f_w to f_2w by defining the next field (no idea what you'd even call it at this point) which defines how many times we iterate... +1ness... over the... I don't even know. Googology breaks my brain past f_w+1, I kind of get it but not well enough to reason about it. And this 'break_celestiality' would need a 'celestial_log' and we are going hopelessly far away from our dreams of ever defining this with any sort of sense. (And hell if I know what .toString would even look like at this point, lmao.)

So great, the "break_reality" can be done by some programming(but you need to implement a Jx finction when x is real.)

[jakub791]

Isn't this all kinda pointless? I mean if you want to figurę out and do it for fun then go for it, but I wouldn't consider it a serious library indeed for use in real incrementals.

[1231234md5]

why?! the other library that can go to the magnitude of this is Omeganum.js, but it's a waste of space and can make the game freeze.