When I enter this query:
index=_internal | head 100 | eval time1=round(_time,0) | eval time2=round(_time,-3) | eval time3=round(_time,-2) | eval time4=round(_time,-1) | eval time5=round(987987778768,-4) | table time1,time2,time3,time4,time5
I get -nan in columns when second parameter of round function is less than -2.
When -2 , everything is rounded to the -2 place after the dot (it equals second place beforce the dot)
Could you explain why?
Is this bug or a feature? 🙂
To get around the syntax ugliness you can define a macro round(2)
with arguments $x$,$y$
as (round($x$*pow(10,$y$))/pow(10,$y$))
and call that like this:
... | eval time2 = `round(_time, -3)` | ...
Solution works, but I think this is a faulty function.
Could I trust "pow", or there are another crazy limitations I don't know? 😕
It is not documented what the second parameter should look like,
@richgalloway comment should definetly appear in the official documentation.
I disagree with that interpretation. The documentation states:
This function takes one or two numeric arguments X and Y, returning X rounded to the amount of decimal places specified by Y.
It makes no sense in this context to mention negative integers at all.
Shouldn't args be tested for invalid values?
To get around the syntax ugliness you can define a macro round(2)
with arguments $x$,$y$
as (round($x$*pow(10,$y$))/pow(10,$y$))
and call that like this:
... | eval time2 = `round(_time, -3)` | ...
The documentation for the round() function does not mention use of negative values for the second argument. Based on that and your experience, I conclude they are not supported.
What's the idea with supplying a negative integer there at all?
negative integer after a dot = positive integer before a dot - isn't it logic?
I want to round a number to thousands (1345 -> 1000 ; 1501 -> 2000).
Syntax round(1345/1000,0)*1000 is uglier