0

Right now, my current method for updating very large numbers is the follows:

  1. Keep track of the health of a given monster, to be attacked, with both a double to keep track of significant digits, and an int to keep track of the power
  2. If the monster is attacked, only update the small double / exponent values used

By following the above, I am only ever dealing with calculations that are between small doubles between 0 and 10. However, I feel as though this is extremely complicated, in comparison to simply using bigintegers.

I have worked in Java previously, and using BigInt resulted in a HUGE performance loss when the exponential numbers became massive (e.g., 10 ^ 20000 +), if I remember correctly.

In the interest of coding a game, and not having to re-evaluate formulas later, what is the best course of action?

Am I really saving that much performance by keeping calculations between small numbers? Or is there an implementation of BigDouble / BigInt for Swift that makes any gain in performance by another implementation negligible? I am well versed in how to use BigDouble / BigInt, so I am really only concerned with the performance difference between using either of those versus an implementation of big numbers by splitting the number into a double (to represent significant digits) and an int (to represent the exponent).

Thank you, and if there needs to be any clarification, I can provide it.

Mat
  • 202,337
  • 40
  • 393
  • 406
G0mega
  • 1
  • Just out of curiosity, do you really have monsters with higher health than what can fit in a long (Long.MAX_VALUE)? – ewramner Mar 28 '18 at 07:41
  • Yes. Based on how the game will scale, long stops being an option fairly quickly. Long is extremely small in comparison to what I need. – G0mega Mar 28 '18 at 07:44
  • Using more than 64bit integers for something that is clearly an arbitrary number that is only this big by design choice and not because it actually has to be this big seems like a bad design decision. Why are you using an integer to represent the health, why don't you just use small `Double` numbers to represent damage and hence scale down the health values to the range `Double` can represent? – Dávid Pásztor Mar 28 '18 at 09:05
  • Right, so that's my question. My current implementation is doing exactly what you just described -- I have everything split up so that the "really large" numbers I mentioned are actually just small doubles / ints. However, my question was concerned with whether or not there is a considerable difference in performance between simply using BigDouble / BigInt versus this. – G0mega Mar 28 '18 at 10:04
  • How often do you need to re-evaluate the health that performance might become an issue? A performant implementation that doesn't use some kind of scaling approach will likely require a fixed-size representation, maybe a custom `UInt65536` via code generation, but that's surely overkill. If I understand you correctly, this is not a problem of fitting the needed precision into a 64 bit value but just the overall magnitude being too large? – Marcel Tesch Mar 28 '18 at 11:33
  • Can't comment directly on Swift, but because usually, doubles and floats are hardware supported and BigIntegers are software types (and BigDoubles too), you will be hard-pressed to find any BigInteger implementation that is faster than a double or float, no matter in which language. If you have such huge values, why don't you use a logarithmic scale? Store logarithms, not values directly. I can't imagine you need hundreds of thousands of bits of *precision*, I assume you just need a huge *range*. Then, logarithms are a better fit. IOW, for the value 10^20000, store 200000, not 10^200000. – Rudy Velthuis Mar 28 '18 at 22:26
  • Note that 200000 only requires 18 bits of storage (and easily fits in an int), while 10^200000 requires more than half a million bits (and does not fit in a double). If you need more precision, use an extra int (32 bits, I guess) for the extra bits of precision. That way, you more or less have your own kind of FP type, with a relatively small mantissa (32 bits) and a relatively large (32 bits too) exponent. – Rudy Velthuis Mar 28 '18 at 22:43

0 Answers0