Hi, I'm wondering why Splunk starts rounding to the next integer in the second row.
The command behind this is just:
....
| eval xi=x*i
Best regards
Heinz
Edit:
It does it because it is <1. If it is greater-than-one, it rounds to integer. You can control this with these commands: ceil
, exact
, floor
, round
and sigfig
.
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
It does it because it is <1. If it is greater-than-one, it rounds to integer. You can control this with these commands: ceil
, exact
, floor
, round
and sigfig
.
And here comes another challenge:
When I use
| eval x=round(x, 2)
| eval xi=x*i
Now it starts rounding in row 12. It seems to me, that the format of x influences the rounding in xi.
I've added screenshot in my question (I don't know how to upload it in the comments...)
0.90 * 12 (both with 2 significant digits... if it was an exact calculation you'd have 10.8 (which is three significant digits)... so we have to round to 2 digits which is 11.
Exactly. It appears that number
values are initially typeset
as integer
so that they round to integer
if >1 but do not if <1. If you use round
then you change the typesetting and it behaves differently after that. It seeps that if you round with 2
as you did, then once it has 2 significant digits, it stops keeping the decimal part. This should probably be documented somewhere; it is interesting and can create problems, for sure.
Thanks for clarifying this behaviour.This is definitely something I have to keep in mind!
I can't explain why Splunk rounds like it does, but I have a workaround.
... | eval xi=exact(x*i) | ...
Thanks for your input, I didn't know this function.
This would be a workaround as well.
...
| eval xi=round(x*i, 2)
I am just wondering about this implicit floor/ceil behaviour
I think only someone from the Splunk development team and explain the behavior.
The rest of us should just remember to use round
or exact
if we expect decimals from an eval.