Rounding errors when trying to implement initiative tie-breakers.

Some numbers randomly cause a lot of trailing digits that screw with the initiative tracker when rolled. A quick example is [[1d20+13.13 &{tracker}]], which consistently causes problems by showing up as something like "19.130000000000003" whenever it rolls anything other than a natural 1, 2, 19, or 20, which resolve fine. Some numbers don't cause this problem, some do, which is just weird.

Addendum: a similarly problematic number is 12.12, which resolves into things like "18.119999999999997" for all natural roll results other than 1, 2, 3, or 20. But these are likely far from a comprehensive list, as I recall encountering this problem many times on many characters.

I'm encountering a similar problem. I'll poke the Devs and see what's up.

Here's the result of a comprehensive search for such numbers on the range from -1 to 50, as any other initiative modifier is extremely unlikely to happen: -1.01 fails at natural 1. 3.03 fails at natural 1,2,3,4. 6.06 fails at natural 2,3,4,5,6,7,8,9. 12.12 fails at all naturals except 1,2,19,20. 13.13 fails at all naturals except 1,2,3,20. 23.23 fails at all naturals except 1,2,3,4,5,6,7,8. 24.24 fails at all naturals except 1,2,3,4,5,6,7. 26.26 fails at all naturals except 1,2,3,4,5. 27.27 fails at all naturals except 1,2,3,4. 46.46 fails at natural 18,19,20. 48.48 fails at natural 16,17,18,19,20. 49.49 fails at natural 15,16,17,18,19,20. All other numbers in this range work correctly.

This is an issue with the way floating-point numbers are implemented in JavaScript (actually, the way they're implemented, period), not with the VTT specifically. A useful way to highlight the error is with fractions. In base-10 (what we're all used to counting with), 1/3 is 0.333333... repeating forever. You can't accurately represent the fraction in decimal notation. In base-2 (what computers count with), 1/10 is 0.0001100110011... repeating forever. The computer can't accurately represent the number 0.1 (base-10), and with very few exceptions computers do not store the actual fraction. The net result is that when you do floating-point math, the computer gives you the closest number it can represent to the actual result. This is all due to the fact that there are an infinite number of numbers between 0 and 1, but the computer has a finite number of bits to spend on representing a value.

Brian said: This is an issue with the way floating-point numbers are implemented in JavaScript (actually, the way they're implemented, period), not with the VTT specifically. A useful analogy is with fractions. In base-10 (what we're all used to counting with), 1/3 is 0.333333... repeating forever. You can't accurately represent the fraction in decimal notation. In base-2 (what computers count with), 1/10 is 0.0001100110011... repeating forever. The computer can't accurately represent the number 0.1 (base-10), and with very few exceptions computers do not store the actual fraction. The net result is that when you do floating-point math, the computer gives you the closest number it can represent to the actual result. It is, however, to my knowledge, possible to process outputs and display them as rounded to a certain digit. There is no reason to display the whole floating point number instead of rounding to, say, 8 digits after the comma, which should solve the problem without sacrificing any functionality and requiring minimal effort.

Another option that would be simple to implement and that would work well in the context of RPG games is simply using fixed-point numbers, as they avoid such pitfalls.

Roll20 is largely implemented with Javascript, which does not have fixed-point numbers.

Brian said: Roll20 is largely implemented with Javascript, which does not have fixed-point numbers. It should still be possible to simply format outputs by rounding off excess digits. There is no reason whatsoever to ever output more than, say, 8 (number arbitrary) digits after the comma. Especially in RPG context.

I divide by 100 in the Initiative macro and I do not encounter these problems. &{template:DnD35StdRoll} {{initflag=true}} {{name=@{selected|token_name} }} {{subtags=gets ready to fight! }} {{check=Initiative roll:}} {{checkroll= [[1d20 + [[@{initstatmod} ]] [Ability] + @{initmagicmod} [Magic] + @{initmiscmod} [Misc] + ?{Additional Initiative Modifier? (Do not use + sign)|0} [Add'l Init Mod] + [[ ([[ (@{init} + ?{Additional Initiative Modifier? (Do not use + sign)|0})]]/100) ]] [Tiebreak] &{tracker}]] }}

Rabulias said: I divide by 100 in the Initiative macro and I do not encounter these problems. &{template:DnD35StdRoll} {{initflag=true}} {{name=@{selected|token_name} }} {{subtags=gets ready to fight! }} {{check=Initiative roll:}} {{checkroll= [[1d20 + [[@{initstatmod} ]] [Ability] + @{initmagicmod} [Magic] + @{initmiscmod} [Misc] + ?{Additional Initiative Modifier? (Do not use + sign)|0} [Add'l Init Mod] + [[ ([[ (@{init} + ?{Additional Initiative Modifier? (Do not use + sign)|0})]]/100) ]] [Tiebreak] &{tracker}]] }} Wow. Upon testing, that is both true and utterly weird. [[1d20+13.13 &{tracker}]] causes problems. [[1d20+13+0.13 &{tracker}]] doesn't cause problems. This is extremely counter-intuitive, but solves my problem. Thank you.