qt5base-lts/tests/auto/testlib/selftests/expected_float.tap

1182 lines
42 KiB
Plaintext
Raw Normal View History

TAP version 13
# tst_float
ok 1 - initTestCase()
not ok 2 - doubleComparisons(should FAIL 1)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 3 (operandRight)
found: 1 (operandLeft)
expected: 3 (operandRight)
actual: 1 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 3 - doubleComparisons(should PASS 1)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
not ok 4 - doubleComparisons(should FAIL 2)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 3e-07 (operandRight)
found: 1e-07 (operandLeft)
expected: 3e-07 (operandRight)
actual: 1e-07 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 5 - doubleComparisons(should PASS 2)
not ok 6 - doubleComparisons(should FAIL 3)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 999999999998 (operandRight)
found: 999999999999 (operandLeft)
expected: 999999999998 (operandRight)
actual: 999999999999 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 7 - doubleComparisons(should PASS 3)
not ok 8 - doubleComparisons(should FAIL 4)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 9.99999999997e-311 (operandRight)
found: 9.99999999999e-311 (operandLeft)
expected: 9.99999999997e-311 (operandRight)
actual: 9.99999999999e-311 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 9 - doubleComparisons(should PASS 4)
not ok 10 - doubleComparisons(should FAIL 5)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 9.99999999997e+306 (operandRight)
found: 9.99999999999e+306 (operandLeft)
expected: 9.99999999997e+306 (operandRight)
actual: 9.99999999999e+306 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 11 - doubleComparisons(should PASS: NaN == NaN)
not ok 12 - doubleComparisons(should FAIL: NaN != 0)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: nan (operandLeft)
expected: 0 (operandRight)
actual: nan (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 13 - doubleComparisons(should FAIL: 0 != NaN)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 0 (operandLeft)
expected: nan (operandRight)
actual: 0 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 14 - doubleComparisons(should FAIL: NaN != 1)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: nan (operandLeft)
expected: 1 (operandRight)
actual: nan (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 15 - doubleComparisons(should FAIL: 1 != NaN)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 1 (operandLeft)
expected: nan (operandRight)
actual: 1 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 16 - doubleComparisons(should PASS: inf == inf)
ok 17 - doubleComparisons(should PASS: -inf == -inf)
not ok 18 - doubleComparisons(should FAIL: inf != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: inf (operandLeft)
expected: -inf (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 19 - doubleComparisons(should FAIL: -inf != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -inf (operandLeft)
expected: inf (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 20 - doubleComparisons(should FAIL: inf != nan)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: nan (operandRight)
found: inf (operandLeft)
expected: nan (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 21 - doubleComparisons(should FAIL: nan != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: nan (operandLeft)
expected: inf (operandRight)
actual: nan (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 22 - doubleComparisons(should FAIL: -inf != nan)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: nan (operandRight)
found: -inf (operandLeft)
expected: nan (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 23 - doubleComparisons(should FAIL: nan != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: nan (operandLeft)
expected: -inf (operandRight)
actual: nan (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 24 - doubleComparisons(should FAIL: inf != 0)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: inf (operandLeft)
expected: 0 (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 25 - doubleComparisons(should FAIL: 0 != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 0 (operandLeft)
expected: inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 26 - doubleComparisons(should FAIL: -inf != 0)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: -inf (operandLeft)
expected: 0 (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 27 - doubleComparisons(should FAIL: 0 != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 0 (operandLeft)
expected: -inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 28 - doubleComparisons(should FAIL: inf != 1)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: inf (operandLeft)
expected: 1 (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 29 - doubleComparisons(should FAIL: 1 != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 1 (operandLeft)
expected: inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 30 - doubleComparisons(should FAIL: -inf != 1)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: -inf (operandLeft)
expected: 1 (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 31 - doubleComparisons(should FAIL: 1 != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 1 (operandLeft)
expected: -inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 32 - doubleComparisons(should FAIL: inf != max)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 1.79769313486e+308 (operandRight)
found: inf (operandLeft)
expected: 1.79769313486e+308 (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 33 - doubleComparisons(should FAIL: inf != -max)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -1.79769313486e+308 (operandRight)
found: inf (operandLeft)
expected: -1.79769313486e+308 (operandRight)
actual: inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 34 - doubleComparisons(should FAIL: max != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 1.79769313486e+308 (operandLeft)
expected: inf (operandRight)
actual: 1.79769313486e+308 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 35 - doubleComparisons(should FAIL: -max != inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -1.79769313486e+308 (operandLeft)
expected: inf (operandRight)
actual: -1.79769313486e+308 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 36 - doubleComparisons(should FAIL: -inf != max)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: 1.79769313486e+308 (operandRight)
found: -inf (operandLeft)
expected: 1.79769313486e+308 (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 37 - doubleComparisons(should FAIL: -inf != -max)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -1.79769313486e+308 (operandRight)
found: -inf (operandLeft)
expected: -1.79769313486e+308 (operandRight)
actual: -inf (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 38 - doubleComparisons(should FAIL: max != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 1.79769313486e+308 (operandLeft)
expected: -inf (operandRight)
actual: 1.79769313486e+308 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 39 - doubleComparisons(should FAIL: -max != -inf)
---
type: QCOMPARE
message: Compared doubles are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: -1.79769313486e+308 (operandLeft)
expected: -inf (operandRight)
actual: -1.79769313486e+308 (operandLeft)
at: tst_float::doubleComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:103)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 103
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 40 - floatComparisons(should FAIL 1)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3 (operandRight)
found: 1 (operandLeft)
expected: 3 (operandRight)
actual: 1 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
...
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
ok 41 - floatComparisons(should PASS 1)
not ok 42 - floatComparisons(should FAIL 2)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3e-07 (operandRight)
found: 1e-07 (operandLeft)
expected: 3e-07 (operandRight)
actual: 1e-07 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 43 - floatComparisons(should PASS 2)
not ok 44 - floatComparisons(should FAIL 3)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 99998 (operandRight)
found: 99999 (operandLeft)
expected: 99998 (operandRight)
actual: 99999 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 45 - floatComparisons(should PASS 3)
not ok 46 - floatComparisons(should FAIL 4)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 9.99971e-40 (operandRight)
found: 9.9999e-40 (operandLeft)
expected: 9.99971e-40 (operandRight)
actual: 9.9999e-40 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 47 - floatComparisons(should PASS 4)
not ok 48 - floatComparisons(should FAIL 5)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 9.9997e+37 (operandRight)
found: 9.9999e+37 (operandLeft)
expected: 9.9997e+37 (operandRight)
actual: 9.9999e+37 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 49 - floatComparisons(should PASS: NaN == NaN)
not ok 50 - floatComparisons(should FAIL: NaN != 0)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: nan (operandLeft)
expected: 0 (operandRight)
actual: nan (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 51 - floatComparisons(should FAIL: 0 != NaN)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 0 (operandLeft)
expected: nan (operandRight)
actual: 0 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 52 - floatComparisons(should FAIL: NaN != 1)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: nan (operandLeft)
expected: 1 (operandRight)
actual: nan (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 53 - floatComparisons(should FAIL: 1 != NaN)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 1 (operandLeft)
expected: nan (operandRight)
actual: 1 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
ok 54 - floatComparisons(should PASS: inf == inf)
ok 55 - floatComparisons(should PASS: -inf == -inf)
not ok 56 - floatComparisons(should FAIL: inf != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: inf (operandLeft)
expected: -inf (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 57 - floatComparisons(should FAIL: -inf != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -inf (operandLeft)
expected: inf (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 58 - floatComparisons(should FAIL: inf != nan)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: nan (operandRight)
found: inf (operandLeft)
expected: nan (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 59 - floatComparisons(should FAIL: nan != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: nan (operandLeft)
expected: inf (operandRight)
actual: nan (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 60 - floatComparisons(should FAIL: -inf != nan)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: nan (operandRight)
found: -inf (operandLeft)
expected: nan (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 61 - floatComparisons(should FAIL: nan != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: nan (operandLeft)
expected: -inf (operandRight)
actual: nan (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 62 - floatComparisons(should FAIL: inf != 0)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: inf (operandLeft)
expected: 0 (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 63 - floatComparisons(should FAIL: 0 != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 0 (operandLeft)
expected: inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 64 - floatComparisons(should FAIL: -inf != 0)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: -inf (operandLeft)
expected: 0 (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 65 - floatComparisons(should FAIL: 0 != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 0 (operandLeft)
expected: -inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 66 - floatComparisons(should FAIL: inf != 1)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: inf (operandLeft)
expected: 1 (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 67 - floatComparisons(should FAIL: 1 != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 1 (operandLeft)
expected: inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 68 - floatComparisons(should FAIL: -inf != 1)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: -inf (operandLeft)
expected: 1 (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 69 - floatComparisons(should FAIL: 1 != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 1 (operandLeft)
expected: -inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 70 - floatComparisons(should FAIL: inf != max)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3.40282e+38 (operandRight)
found: inf (operandLeft)
expected: 3.40282e+38 (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 71 - floatComparisons(should FAIL: inf != -max)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -3.40282e+38 (operandRight)
found: inf (operandLeft)
expected: -3.40282e+38 (operandRight)
actual: inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 72 - floatComparisons(should FAIL: max != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 3.40282e+38 (operandLeft)
expected: inf (operandRight)
actual: 3.40282e+38 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 73 - floatComparisons(should FAIL: -max != inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -3.40282e+38 (operandLeft)
expected: inf (operandRight)
actual: -3.40282e+38 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 74 - floatComparisons(should FAIL: -inf != max)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3.40282e+38 (operandRight)
found: -inf (operandLeft)
expected: 3.40282e+38 (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 75 - floatComparisons(should FAIL: -inf != -max)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -3.40282e+38 (operandRight)
found: -inf (operandLeft)
expected: -3.40282e+38 (operandRight)
actual: -inf (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
...
not ok 76 - floatComparisons(should FAIL: max != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 3.40282e+38 (operandLeft)
expected: -inf (operandRight)
actual: 3.40282e+38 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
...
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
not ok 77 - floatComparisons(should FAIL: -max != -inf)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
Add testlib selftests for double and for non-finite float and double Tidied up the existing float tests in the process. (In particular, s/SUCCESS/PASS/ since that matches real test output.) These verify that QCOMPARE() handles floats and doubles as intended. Extended the existing qFuzzyCompare tests to probe the boundaries of the ranges of values of both types, in the process. Revised the toString<double> that qCompare() uses to give enough precision to actually show some of the differences being tested there (12 digits, to match what qFuzzyCompare tests, so as to show different values rather than, e.g. 1e12 for both expected and actual) and to give consistent results for infinities and NaN (MinGW had eccentric versions for these, leading to different output from tests, which thus failed); did the latter also for toString<float> and fixed stray zeros in MinGW's exponents (which made a kludge in tst_selftest.cpp redundant, so I removed that, too). That's further complicated handling of floating-point types, so let's just keep an eye on how expensive that's getting by adding a benchmark test for QTest::toString(). Unfortunately, default settings only get runs that take modest numbers of milliseconds (some as low as 40) while increasing this with -minumumvalue 100 or more gets the process killed - and I'm unable to find out who's doing the killing (it's not QProcess::kill, ::kill or the QtTest WatchDog, as far as I can tell). So results are rather noisy; the integral tests exhibit speed-ups by factors up to 5, and slow-downs by factors up to 100, between runs with and without this change, which does not affec the integral tests. The relatively modest slow-downs and speed-ups in the floating point tests thus seem likely to be happenstance rather than signal. Change-Id: I4a6bbbab6a43bf14a4089e96238a7c8da2c3127e Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2019-01-14 19:50:41 +00:00
wanted: -inf (operandRight)
found: -3.40282e+38 (operandLeft)
expected: -inf (operandRight)
actual: -3.40282e+38 (operandLeft)
at: tst_float::floatComparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:137)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 137
...
not ok 78 - float16Comparisons(should FAIL 1)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 3 (operandRight)
found: 1 (operandLeft)
expected: 3 (operandRight)
actual: 1 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 79 - float16Comparisons(should PASS 1)
not ok 80 - float16Comparisons(should FAIL 2)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 0.0003 (operandRight)
found: 0.0001 (operandLeft)
expected: 0.0003 (operandRight)
actual: 0.0001 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 81 - float16Comparisons(should PASS 2)
not ok 82 - float16Comparisons(should FAIL 3)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 99 (operandRight)
found: 98 (operandLeft)
expected: 99 (operandRight)
actual: 98 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 83 - float16Comparisons(should PASS 3)
not ok 84 - float16Comparisons(should FAIL 4)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 5.87e-05 (operandRight)
found: 5.93e-05 (operandLeft)
expected: 5.87e-05 (operandRight)
actual: 5.93e-05 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 85 - float16Comparisons(should PASS 4)
not ok 86 - float16Comparisons(should FAIL 5)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 5.88e+04 (operandRight)
found: 5.94e+04 (operandLeft)
expected: 5.88e+04 (operandRight)
actual: 5.94e+04 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 87 - float16Comparisons(should PASS: NaN == NaN)
not ok 88 - float16Comparisons(should FAIL: NaN != 0)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: nan (operandLeft)
expected: 0 (operandRight)
actual: nan (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 89 - float16Comparisons(should FAIL: 0 != NaN)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 0 (operandLeft)
expected: nan (operandRight)
actual: 0 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 90 - float16Comparisons(should FAIL: NaN != 1)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: nan (operandLeft)
expected: 1 (operandRight)
actual: nan (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 91 - float16Comparisons(should FAIL: 1 != NaN)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: nan (operandRight)
found: 1 (operandLeft)
expected: nan (operandRight)
actual: 1 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
ok 92 - float16Comparisons(should PASS: inf == inf)
ok 93 - float16Comparisons(should PASS: -inf == -inf)
not ok 94 - float16Comparisons(should FAIL: inf != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: inf (operandLeft)
expected: -inf (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 95 - float16Comparisons(should FAIL: -inf != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -inf (operandLeft)
expected: inf (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 96 - float16Comparisons(should FAIL: inf != nan)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: nan (operandRight)
found: inf (operandLeft)
expected: nan (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 97 - float16Comparisons(should FAIL: nan != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: nan (operandLeft)
expected: inf (operandRight)
actual: nan (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 98 - float16Comparisons(should FAIL: -inf != nan)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: nan (operandRight)
found: -inf (operandLeft)
expected: nan (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 99 - float16Comparisons(should FAIL: nan != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: nan (operandLeft)
expected: -inf (operandRight)
actual: nan (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 100 - float16Comparisons(should FAIL: inf != 0)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: inf (operandLeft)
expected: 0 (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 101 - float16Comparisons(should FAIL: 0 != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 0 (operandLeft)
expected: inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 102 - float16Comparisons(should FAIL: -inf != 0)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 0 (operandRight)
found: -inf (operandLeft)
expected: 0 (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 103 - float16Comparisons(should FAIL: 0 != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 0 (operandLeft)
expected: -inf (operandRight)
actual: 0 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 104 - float16Comparisons(should FAIL: inf != 1)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: inf (operandLeft)
expected: 1 (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 105 - float16Comparisons(should FAIL: 1 != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 1 (operandLeft)
expected: inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 106 - float16Comparisons(should FAIL: -inf != 1)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 1 (operandRight)
found: -inf (operandLeft)
expected: 1 (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 107 - float16Comparisons(should FAIL: 1 != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 1 (operandLeft)
expected: -inf (operandRight)
actual: 1 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 108 - float16Comparisons(should FAIL: inf != max)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 6.55e+04 (operandRight)
found: inf (operandLeft)
expected: 6.55e+04 (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 109 - float16Comparisons(should FAIL: inf != -max)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -6.55e+04 (operandRight)
found: inf (operandLeft)
expected: -6.55e+04 (operandRight)
actual: inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 110 - float16Comparisons(should FAIL: max != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: 6.55e+04 (operandLeft)
expected: inf (operandRight)
actual: 6.55e+04 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 111 - float16Comparisons(should FAIL: -max != inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: inf (operandRight)
found: -6.55e+04 (operandLeft)
expected: inf (operandRight)
actual: -6.55e+04 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 112 - float16Comparisons(should FAIL: -inf != max)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: 6.55e+04 (operandRight)
found: -inf (operandLeft)
expected: 6.55e+04 (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 113 - float16Comparisons(should FAIL: -inf != -max)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -6.55e+04 (operandRight)
found: -inf (operandLeft)
expected: -6.55e+04 (operandRight)
actual: -inf (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 114 - float16Comparisons(should FAIL: max != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: 6.55e+04 (operandLeft)
expected: -inf (operandRight)
actual: 6.55e+04 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 115 - float16Comparisons(should FAIL: -max != -inf)
---
type: QCOMPARE
message: Compared qfloat16s are not the same (fuzzy compare)
wanted: -inf (operandRight)
found: -6.55e+04 (operandLeft)
expected: -inf (operandRight)
actual: -6.55e+04 (operandLeft)
at: tst_float::float16Comparisons() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:171)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 171
...
not ok 116 - compareFloatTests(1e0)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3 (t3)
found: 1 (t1)
expected: 3 (t3)
actual: 1 (t1)
at: tst_float::compareFloatTests() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:210)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 210
...
not ok 117 - compareFloatTests(1e-7)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3e-07 (t3)
found: 1e-07 (t1)
expected: 3e-07 (t3)
actual: 1e-07 (t1)
at: tst_float::compareFloatTests() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:210)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 210
...
not ok 118 - compareFloatTests(1e+7)
---
type: QCOMPARE
message: Compared floats are not the same (fuzzy compare)
wanted: 3e+07 (t3)
found: 1e+07 (t1)
expected: 3e+07 (t3)
actual: 1e+07 (t1)
at: tst_float::compareFloatTests() (qtbase/tests/auto/testlib/selftests/float/tst_float.cpp:210)
file: qtbase/tests/auto/testlib/selftests/float/tst_float.cpp
line: 210
...
ok 119 - cleanupTestCase()
1..119
# tests 119
# pass 23
# fail 96