Good explanation of the problem and a clear workaround based on that. I had figured this would probably be related to a floating-points somehow, but since PHP doesn't have this problem (but definitely is prone to floating-point number inaccuracies) I thought there might be another explanation... super interesting that Python gives the same results.
Regardless, using round with a negative value hadn't occurred to me, and provides a clear and relatively readable method of ensuring reliable results. Great stuff!
... View more
I tried setting up a Splunk alert to check for inconsistencies between a rounded total and a raw total, but the alert has been giving false positives at random intervals because Splunk's round function doesn't seem to applying a consistent half-rounding rule. A clear example of this is if the following query is run:
| eval rounded_amount_22=round(22.275,2)
| eval rounded_amount_21=round(21.275,2)
| eval rounded_amount_20=round(20.275,2)
| eval rounded_amount_19=round(19.275,2)
| eval rounded_amount_18=round(18.275,2)
| eval rounded_amount_17=round(17.275,2)
| eval rounded_amount_16=round(16.275,2)
| eval rounded_amount_15=round(15.275,2)
| eval rounded_amount_14=round(14.275,2)
| eval rounded_amount_13=round(13.275,2)
| eval rounded_amount_12=round(12.275,2)
| eval rounded_amount_11=round(11.275,2)
| eval rounded_amount_10=round(10.275,2)
| head 1
If Splunk was using half-up, half-down, or banker's rounding, I'd expect to see consistency in the results, but I just don't see a pattern in what I get back:
In particular, every rounding scheme I know of should treat 10.275 and 20.275 the same - but as shown in the above list, Splunk is rounding up to 10.28 and down to 20.27 . I just don't see a pattern in it.
I've also tried wrapping the round function in exact , but that doesn't change the results.
What's going on here? Is it possible for this query to return consistent half-rounding results?
... View more