Bug? Missed cases with Add and multiply

[xGnoSiSx]

Apologies if I misunderstand the code but it seems to me that there are missing cases for add and multiply:

Add:

    //Special case: If one of the numbers is layer 2 or higher, just take the bigger number.
    if (this.layer >= 2 || decimal.layer >= 2) {
      return this.maxabs(decimal);
    }

Multiply:

    //Special case: If one of the numbers is layer 3 or higher or one of the numbers is 2+ layers bigger than the other, just take the bigger number.
    if (a.layer >= 3 || a.layer - b.layer >= 2) {
      return FC(a.sign * b.sign, a.layer, a.mag);

Both of these cases trap/escape if one numbers layer is greater or equal than layer 2 or greater or equal than layer 3. But there is no case where both numbers are above layer 2 or 3 and at the same layer. I get it that if the layer difference exists at these levels then it doesn't matter, but what if both numbers are layer 5 or layer 10? surely some calculation must happen with the magnitudes, depending if those magnitudes are close, or if they are vastly distant (less impact for addition, more impact for multiplication)

[Patashu]

It's counterintuitive but true. In an arbitrary precision numerical library this would be true, but since the total precision is limited then past a certain point the effects of multiplying two numbers is so miniscule compared to just taking whichever number is bigger.

Try testing it yourself - mess with multiplying numbers as they get bigger and bigger, and watch how the numbers change.

(If you DO find an edge case that isn't properly handled, let me know. But I think all such edge cases require more precision than b_e has)

[xGnoSiSx]

Thanks for the prompt reply. I'm thinking of replicating this code for the JVM. but back to my issue:

If mag is a double float, then surely, for the precision supported by just the double float for at least I don't know? Layer 3-7? You will get some difference in the magnitude doing the regular algebra, because e15 is far less than e308?

[xGnoSiSx]

I see what you mean!!

This is scary and unavoidable with this notation. And when creating a game where you're based on addition and multiplication, it seems this system is doomed or you need to add exponentiation and other more exotic operations to actually increase the magnitude of a high layer number...

[Patashu]

It's just the way math works! Once your numbers get bigger and bigger, the power of lower hyperoperators gets smaller and smaller. And unfortunately too, the power of different hyperoperators get further and further apart from each other, such that eventually you're stranded to individual hyperoperators and amounts of arrows that can never meaningfully and continuously reach each other. Layers 0 and 1 are rich and diverse in mathematical gameplay experience. Layer 2 is a little harder to work with, but still possible to do interesting things about. Layer 3 is the precipice, and layer 4 and beyond is pretty much the land of 'your remaining tools are tetration, slog, cmp and max'. And if you increase the number of arrows between each layer from 1 to 2, the universe is pulled asunder.

The solution may be the implementation of continuous hyperoperators (see https://github.com/Patashu/break_eternity.js/issues/46#issuecomment-1196340750 ), but the required knowledge may not be mature enough yet.

I also want to replace the critical function for tetration bases 2, e and 10 with the exact way to calculate them in http://myweb.astate.edu/wpaulsen/tetcalc/tetcalc.html , just so we can have perfectly exact tetration/slog/sroot without any accuracy tradeoff remaining, but it'll be a tricky surgery so I've been putting it off. And I currently lack the knowledge to make such an exact calculation work for arbitrary bases.

[xGnoSiSx]

:(