Round problem

[lukasz92]

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? 🙂

[lukasz92]

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.

[Ayn]

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.

[lukasz92]

Shouldn't args be tested for invalid values?

[martin_mueller · Accepted solution]

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)` | ...

[richgalloway]

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.

[Ayn]

What's the idea with supplying a negative integer there at all?

[lukasz92]

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