Changes to handle the double precision errors

[kedarbcs16]

Currently, there are some data verification failures for near equal values, this PR is to ignore them as data verification failures and to mark as a new type data precision failure if they are failing for the precision value, also it has changed the precision value to a more accepted value and the following changes as well:-

1. parameterize the precision value(FEPS ksay)
   2)checking for 2 more precision values for the same value in case of an error (i.e. FEPS * 10 AND FEPS * 100)

The results previously were for eg:-
Query: /root/drillAutomation/master/framework/resources/Advanced/tpch/tpch_sf1/sanity/maprdb/json/query10_sum.sql
select sum(L_DISCOUNT) from lineitem

Baseline: /root/drillAutomation/master/framework/resources/Advanced/tpch/tpch_sf1/sanity/maprdb/json/query10_sum.e_tsv
Expected number of rows: 1
Actual number of rows from Drill: 1
Number of matching rows: 0
Number of rows missing: 1
Number of rows unexpected: 1

These rows are not expected (first 10):
300057.3300002678

These rows are missing (first 10):
300057.3299997481 (1 occurence(s)

After Proposed Change:-
[PASS] (10.51 s) /root/drillAutomation/master/framework/resources/Advanced/tpch/tpch_sf1/sanity/maprdb/json/query10_sum.sql

There is only one failure in data verification remaining which looks like an actual failure:-
These rows are not expected (first 10):
able AAAAAAAAABBAAAAA 5201 1 1 1 1 1 1 1
able AAAAAAAAABBAAAAA 5202 1 1 1 1 1 1 1
able AAAAAAAAABBAAAAA 5203 1 1 1 1 1 1 1

These rows are missing (first 10):
able AAAAAAAAABBAAAAA 5201 1.02596238783322112347 0.92348065982403962962 1.03775175070487385991 1.1958496976011165 0.89227580926364466986 0.93194781639240754520 1.4127765679517665 (24 occurence(s))
able AAAAAAAAABBAAAAA 5202 1.1275577509523670 0.85947464754000782300 0.68491126287602118020 0.96069716471214886353 1.00142901006058381877 1.10846217231602910574 1.1287102632635932 (49 occurence(s))
able AAAAAAAAABBAAAAA 5203 1.01586468414891918392 0.95815542511844994124 0.93023648307049253221 0.95005761509395845600 0.83205349185674132545 0.94734936141143506888 0.93014764945033420991 (27 occurence(s))

[agirish]

Hey Kedar,

Can we sync up in person tomorrow or the day after to go over this? It'll be easier. Plus I want to run through multiple tests - as this is updating core logic.

[kedarbcs16]

Hey Kedar,

Can we sync up in person tomorrow or the day after to go over this? It'll be easier. Plus I want to run through multiple tests - as this is updating core logic.

ok

[agozhiy]

@kedarbcs16, @agirish, what is the status of this?

[agirish]

Had a discussion with Kedar - we will treat precision issues as a separate category from regular data verification failures. And he'll use the queries here to test the new logic. @kedarbcs16 please share an update once you have made progress.

[kkhatua]

@kedarbcs16 (cc: @agirish )
what is the status of the precision check ? @agozhiy also had PR #527 that does the same. We should close one if the other is ready to be merged.

[arina-ielchiieva]

@kkhatua / @agirish do you know the status of this PR? Will it be merged?

[agirish]

@arina-ielchiieva , I this this PR needs some rework. We do not have the bandwidth to look into it anytime soon. So I think we will get Anton's PR merged in.