Possibly v1.4

[MathCookie17]

Added the following features:

• An argument for hyper-4 functions that, when set to true, has them use the linear approximation even for bases <= 10, ensuring consistent behavior in situations where consistent behavior is needed (such as in an incremental game that uses tetration)
• Support for XFY format in fromString
• mod/modular function
• Super roots of arbitrary length (but only for the linear approximation, as super roots don't really work without a consistent definition of tetration)

[Patashu]

Cool, I will take a look at this when I am lucid (hopefully in 1-3 days).

Just while it's on my mind, https://github.com/Patashu/break_eternity.js/issues/22#issuecomment-976093474 onwards is the last of my 'todo list' for the library, with the intent of 'it's better to implement arbitrary tetration/inverses with 100% accuracy before then aiming to make it more performant' (doing binary search or better algorithms to implement inverses with 100% accuracy if a direct way to calculate them is not yet known). Especially with your idea of having a flag to calculate it in a quick-and-dirty-way, then everyone can be happy.

Obviously I don't expect you to do all of this for me, but if you did it'd be one less thing on my bucket list.

[MathCookie17]

It’s been a while - are you still going to look at this at some point?

As a response to what you said: I don’t actually understand your “analytic” version of decimal-degree tetration, otherwise I probably would have tried to extend it. I can’t really help you with extending that to more bases, at least not right now.

[Patashu]

Sorry, last week was really terrible for me, haha. Let's see if this week treats me better.

Extending the current 'more analytic' critical section to more bases is a bit beyond me, too - but by welding the code of http://myweb.astate.edu/wpaulsen/tetcalc/tetcalc.html onto break_eternity.js, then three specific bases (2, 10, e) could be made 100% accurate, and their inverses also 100% accurate by using binary search (or a better approximation, something likew Newton's algorithm, to converge faster) to a desired number of decimal places.

Basically on the premise that if you're going to implement something it should be actually correct - then after that, offering a less precise but faster alternative is fine, and you can choose what you want more.

I'd love to have arbitrary bases accurate too but that math knowledge is beyond me. Maybe some day though.

[MathCookie17]

For the record, the main reason I added a “always use the linear approximation” flag for tetration is because it’s weird that bases below 10 and bases above 10 use different rules. There are some cases where you need the behavior to be consistent across all bases (this is especially true for super-roots: if I recall correctly, using your analytic tetration, 10^^2.5 is around e294, but 10.000001^^2.5, which reverts to linear approximation, is in the e1400s, so the 2.5th super-root of, say, 1e500… would be NaN, because e500 is in the gap. That’s part of the reason that my super-root implementation always uses the linear approximation, as it would have unwieldy behavior when accounting for the gap. slog doesn’t have this problem because it keeps the base constant and searches for the tetra-exponent, but sroot is searching for the base), and since we don’t have a way to do analytic for all bases, the only option is to do linear for all bases when consistency across different bases is needed.

[Patashu]

Good point; I agree with your reasoning.

[Patashu]

Ok, done reading - left some comments for you to take a look at. When you're happy and I'm happy I'll merge it and npm a new build. Apologies again for the delay.

[MathCookie17]

Alright, I'll make changes when I find time. I'm pretty busy these next couple days, but I'll try to get to this soon.

[MathCookie17]

OK, I made the changes to mod. Is there anything else I need to do?

[Patashu]

Nope, I'll take a look today, thanks!

[Patashu]

It looks like your pull request has lines like

<<<<<<< Updated upstream

in it. Did you resolve some merge conflicts incorrectly?

[MathCookie17]

Yeah, I saw those and I have no idea what they are. What was I supposed to do, and what should I do now? This is my first time contributing to someone else’s GitHub project, so I don’t know how merge conflicts work.

[Patashu]

You need to look at the two different pieces of code and merge them into one single piece of code that is correct (has all the changes you want and none of the ones you don't want), then you delete the <<< === >>> types of lines.

These are created automatically when git doesn't know which of these two pieces of code is the one you actually wanted to be here, usually because there's a 'merge conflict' where the thing you were trying to change had an unrelated change in the mean time.

[MathCookie17]

Alright, merge conflicts have been fixed!

[Patashu]

Mod bugs look fixed now, so I'll merge and npm publish. Thanks!