Naruyoko
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}....
This seems to be caused by the limit on the number of iterations of `pow` (set to 100) before exiting. `OmegaNum(1.4447).tetr(b)` for b>100 fits this limit, which sets `f` (layers...
[0.5.6](https://github.com/Naruyoko/OmegaNum.js/commit/e0dcab8d8d9b7738e045745acfeff80a1b9a965e)
Sorry for late reply, however I'm struggling to reproduce the issue. Can you give me what numbers you used for the ExpantaNum number and maxOps?
[α 1.3.8](https://github.com/Naruyoko/ExpantaNum.js/releases/tag/%CE%B1-1.3.8)
That's nice, and probably work similarly for larger libraries I'll make, however, I felt like the gap between (10^)^9e15 10 and 10^^ee10 is too much; Yes, the numbers are huge,...
However, at around 10{1000}x, there would probably be only few numbers since nobody cares, at around 10{100000}x, I think it is safe to assume that nobody cares about x other...
We can only drop numbers and not lose precision when we can't even hold the number of arrows without losing precision: Which is 9e15. At that point since 10{MSI}10 and...
[α 1.4.0](https://github.com/Naruyoko/ExpantaNum.js/releases/tag/%CE%B1-1.4.0)
I can't seem to reproduce this... what version were you using?