Scripted field rounds values <1 to 0

[apatel (Anand Patel)]

I have two fields (px_last and implied_price) that I am trying to find the percent difference of using a scripted field in painless. I ran into problems trying to calculate it when I saw I was getting results of 200% deviation, which was being caused by the first field being interpreted as 0 whenever the field was between 0 and 1. Even when I try to simply print the value in a dummy scripted field price it rounds to 0:

return doc['implied_price'].value;

I've checked the mappings and ensured both fields were floats, tried multiplying by 100.0 then dividing by 100.0, and explicitly casting the value to a double, but all yield a value of 0. I also changed the format of the scripted field to show 3-5 decimals places. I'm using Kibana 5.6.8 and Elasticsearch 5.6.9.

Here's an example of an affected row:

I've tried searching all related issues on the elastic forum and checked the issues on the github repository and couldn't find anything that helped solve my problem, so any help would be appreciated.

[Nathan_Reese]

Can you try storing px_last as a scaled_float?

[Nathan_Reese]

Can you try the following.

In Dev tools, create a simple index pattern and add some documents by running the following

PUT testindex
{
    "settings" : {
        "index" : {
            "number_of_shards" : 1, 
            "number_of_replicas" : 0
        }
    }
}

PUT testindex/_mapping/_doc 
{
  "properties": {
    "myFloat": {
      "type": "float"
    }
  }
}

PUT testindex/_doc/1
{
    "myFloat" : 0.98604
}

PUT testindex/_doc/2
{
    "myFloat" : 1.9
}

 PUT testindex/_doc/3
{
    "myFloat" : 0.3
}

Then create an index pattern for testindex and create a scripted field with the following script return doc['myFloat'].value;.

What do you see on Discover? You should see something like this

[apatel (Anand Patel)]

@Nathan_Reese

return doc['myFloat'].value;

I tried this and it worked, and realized that the rows affected with this problem only come from one day, so I'll see if I can try to re-log those records and see if the problem is fixed