Remove the hasNans config and no_nan data gen in test code.
#6502
Conversation
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
Signed-off-by: remzi <13716567376yh@gmail.com>
|
build |
| @@ -954,7 +891,7 @@ def test_hash_multiple_mode_query_avg_distincts(data_gen, conf): | |||
| @approximate_float | |||
| @ignore_order | |||
| @incompat | |||
| @pytest.mark.parametrize('data_gen', _init_list_no_nans, ids=idfn) | |||
| @pytest.mark.parametrize('data_gen', _init_list, ids=idfn) | |||
There was a problem hiding this comment.
Note that just because we're removing the hasNans config does not mean we want to avoid testing values without NaNs. One concern with allowing NaNs into the mix is that it can cause some operations to effectively always return NaN because the chance of generating at least one NaN in the input could be high, and summing/averaging with a NaN produces a NaN. If too many NaNs are generated then we're not really testing whether we're getting the non-NaN case right because the NaNs "eclipse" the results.
If we're convinced that NaN-eclipsing isn't going to be a problem then we're fine, but for a full reduction on a column it seems likely at least one NaN would be generated. Ideally we want to test both cases, with and without NaNs, to make sure we're doing both correctly.
Co-authored-by: Jason Lowe <jlowe@nvidia.com>
Signed-off-by: remzi 13716567376yh@gmail.com
close #6487.