It looks like the tests are currently failing due to some handling of the floating points:

  Expected: "poco,tag=tag\\ val value=15.444,ValueWithEmptyName=25,ValueWit..."
  But was:  "poco,tag=tag\\ val value=15.444000000000001,ValueWithEmptyName..."

  Expected: "...,integer=7i,long=1i,point=13.3,sbyte=12i,short=8i,string="..."
  But was:  "...,integer=7i,long=1i,point=13.300000000000001,sbyte=12i,sho..."

  Expected: "...33,double16=16.3333333333333333,double17=17.33333333333333333"
  But was:  "...32,double16=16.333333333333332,double17=17.333333333333332"

This is a behavior change. Hopefully, someone does not depend on exact floating points, but I have concerns about this causing issues for existing users. I was hoping to have @bednar and @davidby-influx chime in on the change.

Thanks!

My suggestion is to change the tests to round the got value to the precision of the expected value. There may be customers who depend exact floating point comparison, but that always leads to tears.

Something like:

expected = 2.33333

got = ComputedValue()

if Math.Round(got, 5) != expected
{
UnhappyNoises()
}

This may not fix everything (because midpoint rounding can cause problems, but it will fix a lot of the cases.

Thanks for the looking at the PR!

The tests are primarily comparing two strings of line protocol. I think in those cases if we are good with updates to the floating points and it sounds like we are, I can update the expected. I'll let this this sit over night and see if Jakub chimes in.

Thanks again, I appreciate the review.

It looks good for me 👍

How will this work when we add a filter to compare
|> filter(fn: (r) => r["_value"] >= -180)
currently it throws an error something like below
Error –
{

"code": "invalid",
"message": "runtime error @6:6-6:44: filter: cannot compile @ 6:17-6:43: unsupported binary expression string >= int"

}

Thank you both - the failing tests are updated, formatting corrected, and readme rebased.