If I had to make an educated guess this behaviour actually looks like the behavior of Significant digits and Significance arithmetic. When you're doing math with values that are only accurate to a specific number of places, your result can only be as accurate as the input numbers.
Try these out for yourself:
1 * 0.9 = 0.9 (One significant digit on both operands, one significant digit in the result)
2 * 0.9 = 2 ( if 0.9 was exact, then we would have 1.8, however since we cannot say that by default, we need to round to 1 significant digit so 2 )
2 * 0.90 = 1.8 (The right hand side has 2 significant digits, and splunk adjusts accordingly)
2 * 0.99 = 2 ( Again if .99 was exact, then the calculation would be 1.98, but since we can only have 2 significant digits, so rounds to 2)
1000 * 0.9 = 900 (I'm not sure if splunk is treating these trailing 0s as significant or not, but in this case we still only have 1 on each side)
1100 * 0.9 = 990 (ditto but with 2 significant digits on the left hand side)
Edit to add, in fact this was previously answered by a splunker: https://answers.splunk.com/answering/11400/view.html
Another edit to add: Splunk's docs used to have an explanation on this: http://docs.splunk.com/Documentation/Splunk/4.2/SearchReference/eval#Significant_figures_and_precisi...
But it seems the rules have changed a bit since then... so we probably need a splunk dev to clarify:
2.0 * 1024 = 2048
2.2 * 1024 = 2253 (instead of 2252.8 with an exact calculation)
2.1 * 1024 = 2150 (instead of 2150.4 with an exact calculation)
2.10 * 1024 = 2150
2.100 * 1024 = 2150
2.1000 * 1024 = 2150.4 (five significant digits on the left hand side)
2.1 * 1024.0 = 2150 (uh... wut? )
2.1 * 1024.1 = 2151 (instead of 2150.61 )
2.100000000 * 1024.1 = 2150.6
2.10000 * 1024.1 = 2150.6
2.10000 * 1024.10 = 2150.61
