0

I have a JSON document whose number is 18 digits long. But In cloudwatch logs those numbers are rounded, so that they end with two zeros. Actual JSON snippet:

{
  "prd_slnos": [
    {
      "start": 893800399235546485,
      "end": 893800399235546490
    }
  ]
}

Cloudwatch snippet:

{
  "prd_slnos": [
    {
      "start": 893800399235546400,
      "end": 893800399235546400,
    }
  ]
}
Khalid
  • 4,730
  • 5
  • 27
  • 50
saravanan
  • 1
  • 1
  • The maximum integer you can store in double without precision loss is 2^53. See http://stackoverflow.com/questions/1848700/biggest-integer-that-can-be-stored-in-a-double – Sergei Rodionov Jan 05 '16 at 14:23

1 Answers1

1

Value

The value for the metric.

Type: Double

http://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html

The data type here is a double-precision floating point number, which is a 64-bit number that supports a much larger range of possible values than a 64-bit integer, at the cost of precision. Depending on the value, there are at most 15-17 digits of precision available.

Working this out by hand, I came up with the following value as the closest number possible number to the given input numbers, when the number is represented as a double. I've arrived at a slightly different value than CloudWatch is displaying, presumably because I rounded away from 0 and they rounded toward 0, but you see the implication -- two different numbers both have the same nearest possible number that is representable in double-precision encoding, and this gives the appearance of the two numbers being not only equivalent when they aren't, but also "rounded off," as you've seen. This is a limitation of double-precision encoding -- not every number can be represented. 

# original value      # nearest number in double-precision encoding
893800399235546485 -> 893800399235546600
893800399235546490 -> 893800399235546600

Cloudwatch appears to be behaving as documented.

Michael - sqlbot
  • 169,571
  • 25
  • 353
  • 427