2011-09-20 01:56:31 +00:00
|
|
|
/****************************************************************************
|
|
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** Copyright (C) 2016 The Qt Company Ltd.
|
|
|
|
|
** Contact: https://www.qt.io/licensing/
|
2011-09-20 01:56:31 +00:00
|
|
|
**
|
|
|
|
|
** This file is part of the test suite of the Qt Toolkit.
|
|
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** $QT_BEGIN_LICENSE:GPL-EXCEPT$
|
2012-09-19 12:28:29 +00:00
|
|
|
** Commercial License Usage
|
|
|
|
|
** Licensees holding valid commercial Qt licenses may use this file in
|
|
|
|
|
** accordance with the commercial license agreement provided with the
|
|
|
|
|
** Software or, alternatively, in accordance with the terms contained in
|
2015-01-28 08:44:43 +00:00
|
|
|
** a written agreement between you and The Qt Company. For licensing terms
|
2016-01-15 12:36:27 +00:00
|
|
|
** and conditions see https://www.qt.io/terms-conditions. For further
|
|
|
|
|
** information use the contact form at https://www.qt.io/contact-us.
|
2012-09-19 12:28:29 +00:00
|
|
|
**
|
2016-01-15 12:36:27 +00:00
|
|
|
** GNU General Public License Usage
|
|
|
|
|
** Alternatively, this file may be used under the terms of the GNU
|
|
|
|
|
** General Public License version 3 as published by the Free Software
|
|
|
|
|
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
|
|
|
|
|
** included in the packaging of this file. Please review the following
|
|
|
|
|
** information to ensure the GNU General Public License requirements will
|
|
|
|
|
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
|
2011-09-20 01:56:31 +00:00
|
|
|
**
|
|
|
|
|
** $QT_END_LICENSE$
|
|
|
|
|
**
|
|
|
|
|
****************************************************************************/
|
|
|
|
|
|
2012-01-10 00:28:42 +00:00
|
|
|
#include <QtCore/QCoreApplication>
|
2018-11-09 13:05:35 +00:00
|
|
|
#include <QtCore/qfloat16.h>
|
2011-09-20 01:56:31 +00:00
|
|
|
#include <QtTest/QtTest>
|
|
|
|
|
#include <QDebug>
|
|
|
|
|
|
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
|
|
|
// Test proper handling of floating-point types
|
2011-09-20 01:56:31 +00:00
|
|
|
class tst_float: public QObject
|
|
|
|
|
{
|
|
|
|
|
Q_OBJECT
|
|
|
|
|
private slots:
|
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
|
|
|
void doubleComparisons() const;
|
|
|
|
|
void doubleComparisons_data() const;
|
2011-09-20 01:56:31 +00:00
|
|
|
void floatComparisons() const;
|
|
|
|
|
void floatComparisons_data() const;
|
2018-11-09 13:05:35 +00:00
|
|
|
void float16Comparisons() const;
|
|
|
|
|
void float16Comparisons_data() const;
|
2011-09-20 01:56:31 +00:00
|
|
|
void compareFloatTests() const;
|
|
|
|
|
void compareFloatTests_data() const;
|
|
|
|
|
};
|
|
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
template<typename F>
|
|
|
|
|
static void nonFinite_data(F zero, F one)
|
|
|
|
|
{
|
|
|
|
|
using Bounds = std::numeric_limits<F>;
|
|
|
|
|
|
|
|
|
|
// QCOMPARE special-cases non-finite values
|
|
|
|
|
if (Bounds::has_quiet_NaN) {
|
|
|
|
|
const F nan = Bounds::quiet_NaN();
|
|
|
|
|
QTest::newRow("should PASS: NaN == NaN") << nan << nan;
|
|
|
|
|
QTest::newRow("should FAIL: NaN != 0") << nan << zero;
|
|
|
|
|
QTest::newRow("should FAIL: 0 != NaN") << zero << nan;
|
|
|
|
|
QTest::newRow("should FAIL: NaN != 1") << nan << one;
|
|
|
|
|
QTest::newRow("should FAIL: 1 != NaN") << one << nan;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (Bounds::has_infinity) {
|
|
|
|
|
const F uge = Bounds::infinity();
|
|
|
|
|
QTest::newRow("should PASS: inf == inf") << uge << uge;
|
|
|
|
|
QTest::newRow("should PASS: -inf == -inf") << -uge << -uge;
|
|
|
|
|
QTest::newRow("should FAIL: inf != -inf") << uge << -uge;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != inf") << -uge << uge;
|
|
|
|
|
if (Bounds::has_quiet_NaN) {
|
|
|
|
|
const F nan = Bounds::quiet_NaN();
|
|
|
|
|
QTest::newRow("should FAIL: inf != nan") << uge << nan;
|
|
|
|
|
QTest::newRow("should FAIL: nan != inf") << nan << uge;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != nan") << -uge << nan;
|
|
|
|
|
QTest::newRow("should FAIL: nan != -inf") << nan << -uge;
|
|
|
|
|
}
|
|
|
|
|
QTest::newRow("should FAIL: inf != 0") << uge << zero;
|
|
|
|
|
QTest::newRow("should FAIL: 0 != inf") << zero << uge;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != 0") << -uge << zero;
|
|
|
|
|
QTest::newRow("should FAIL: 0 != -inf") << zero << -uge;
|
|
|
|
|
QTest::newRow("should FAIL: inf != 1") << uge << one;
|
|
|
|
|
QTest::newRow("should FAIL: 1 != inf") << one << uge;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != 1") << -uge << one;
|
|
|
|
|
QTest::newRow("should FAIL: 1 != -inf") << one << -uge;
|
|
|
|
|
|
|
|
|
|
const F big = Bounds::max();
|
|
|
|
|
QTest::newRow("should FAIL: inf != max") << uge << big;
|
|
|
|
|
QTest::newRow("should FAIL: inf != -max") << uge << -big;
|
|
|
|
|
QTest::newRow("should FAIL: max != inf") << big << uge;
|
|
|
|
|
QTest::newRow("should FAIL: -max != inf") << -big << uge;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != max") << -uge << big;
|
|
|
|
|
QTest::newRow("should FAIL: -inf != -max") << -uge << -big;
|
|
|
|
|
QTest::newRow("should FAIL: max != -inf") << big << -uge;
|
|
|
|
|
QTest::newRow("should FAIL: -max != -inf") << -big << -uge;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
void tst_float::doubleComparisons() const
|
|
|
|
|
{
|
|
|
|
|
QFETCH(double, operandLeft);
|
|
|
|
|
QFETCH(double, operandRight);
|
|
|
|
|
|
|
|
|
|
QCOMPARE(operandLeft, operandRight);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void tst_float::doubleComparisons_data() const
|
|
|
|
|
{
|
|
|
|
|
QTest::addColumn<double>("operandLeft");
|
|
|
|
|
QTest::addColumn<double>("operandRight");
|
2019-02-21 19:53:15 +00:00
|
|
|
double zero(0.), one(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
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
QTest::newRow("should FAIL 1") << one << 3.;
|
|
|
|
|
QTest::newRow("should PASS 1") << zero << zero;
|
|
|
|
|
QTest::newRow("should FAIL 2") << 1.e-7 << 3.e-7;
|
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
|
|
|
|
|
|
|
|
// QCOMPARE for doubles uses qFuzzyCompare(), which succeeds if the numbers
|
|
|
|
|
// differ by no more than 1e-12 times the smaller value. Thus
|
|
|
|
|
// QCOMPARE(1e12-2, 1e12-1) should fail, while QCOMPARE(1e12+1, 1e12+2)
|
|
|
|
|
// should pass.
|
|
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
QTest::newRow("should PASS 2") << 1e12 + one << 1e12 + 2.;
|
|
|
|
|
QTest::newRow("should FAIL 3") << 1e12 - one << 1e12 - 2.;
|
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
|
|
|
// ... but rounding makes that a bit unrelaible when scaled close to the bounds.
|
|
|
|
|
QTest::newRow("should PASS 3") << 1e-310 + 1e-322 << 1e-310 + 2e-322;
|
|
|
|
|
QTest::newRow("should FAIL 4") << 1e-310 - 1e-322 << 1e-310 - 3e-322;
|
|
|
|
|
QTest::newRow("should PASS 4") << 1e307 + 1e295 << 1e307 + 2e295;
|
|
|
|
|
QTest::newRow("should FAIL 5") << 1e307 - 1e295 << 1e307 - 3e295;
|
|
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
nonFinite_data(zero, one);
|
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
|
|
|
}
|
|
|
|
|
|
2011-09-20 01:56:31 +00:00
|
|
|
void tst_float::floatComparisons() const
|
|
|
|
|
{
|
|
|
|
|
QFETCH(float, operandLeft);
|
|
|
|
|
QFETCH(float, operandRight);
|
|
|
|
|
|
|
|
|
|
QCOMPARE(operandLeft, operandRight);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void tst_float::floatComparisons_data() const
|
|
|
|
|
{
|
|
|
|
|
QTest::addColumn<float>("operandLeft");
|
|
|
|
|
QTest::addColumn<float>("operandRight");
|
2019-02-21 19:53:15 +00:00
|
|
|
float zero(0.f), one(1.f);
|
2011-09-20 01:56:31 +00:00
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
QTest::newRow("should FAIL 1") << one << 3.f;
|
|
|
|
|
QTest::newRow("should PASS 1") << zero << zero;
|
|
|
|
|
QTest::newRow("should FAIL 2") << 1.e-7f << 3.e-7f;
|
2011-09-20 01:56:31 +00:00
|
|
|
|
2012-02-03 05:43:28 +00:00
|
|
|
// QCOMPARE for floats uses qFuzzyCompare(), which succeeds if the numbers
|
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
|
|
|
// differ by no more than 1e-5 times the smaller value. Thus
|
|
|
|
|
// QCOMPARE(1e5-2, 1e5-1) should fail, while QCOMPARE(1e5+1, 1e5+2)
|
2012-02-03 05:43:28 +00:00
|
|
|
// should pass.
|
|
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
QTest::newRow("should PASS 2") << 1e5f + one << 1e5f + 2.f;
|
|
|
|
|
QTest::newRow("should FAIL 3") << 1e5f - one << 1e5f - 2.f;
|
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
|
|
|
// ... but rounding makes that a bit unrelaible when scaled close to the bounds.
|
|
|
|
|
QTest::newRow("should PASS 3") << 1e-39f + 1e-44f << 1e-39f + 2e-44f;
|
|
|
|
|
QTest::newRow("should FAIL 4") << 1e-39f - 1e-44f << 1e-39f - 3e-44f;
|
|
|
|
|
QTest::newRow("should PASS 4") << 1e38f + 1e33f << 1e38f + 2e33f;
|
|
|
|
|
QTest::newRow("should FAIL 5") << 1e38f - 1e33f << 1e38f - 3e33f;
|
|
|
|
|
|
2019-02-21 19:53:15 +00:00
|
|
|
nonFinite_data(zero, one);
|
2011-09-20 01:56:31 +00:00
|
|
|
}
|
|
|
|
|
|
2018-11-09 13:05:35 +00:00
|
|
|
void tst_float::float16Comparisons() const
|
|
|
|
|
{
|
|
|
|
|
QFETCH(qfloat16, operandLeft);
|
|
|
|
|
QFETCH(qfloat16, operandRight);
|
|
|
|
|
|
|
|
|
|
QCOMPARE(operandLeft, operandRight);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void tst_float::float16Comparisons_data() const
|
|
|
|
|
{
|
|
|
|
|
QTest::addColumn<qfloat16>("operandLeft");
|
|
|
|
|
QTest::addColumn<qfloat16>("operandRight");
|
|
|
|
|
|
|
|
|
|
QTest::newRow("should SUCCEED 1")
|
|
|
|
|
<< qfloat16(0)
|
|
|
|
|
<< qfloat16(0);
|
|
|
|
|
|
|
|
|
|
QTest::newRow("should FAIL 1")
|
|
|
|
|
<< qfloat16(1.000)
|
|
|
|
|
<< qfloat16(3.000);
|
|
|
|
|
|
|
|
|
|
QTest::newRow("should FAIL 2")
|
|
|
|
|
<< qfloat16(1.000e-4f)
|
|
|
|
|
<< qfloat16(3.000e-4f);
|
|
|
|
|
|
|
|
|
|
// QCOMPARE for qfloat16s uses qFuzzyCompare()
|
|
|
|
|
|
|
|
|
|
QTest::newRow("should FAIL 3")
|
|
|
|
|
<< qfloat16(98)
|
|
|
|
|
<< qfloat16(99);
|
|
|
|
|
|
|
|
|
|
QTest::newRow("should SUCCEED 2")
|
|
|
|
|
<< qfloat16(1001)
|
|
|
|
|
<< qfloat16(1002);
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-20 01:56:31 +00:00
|
|
|
void tst_float::compareFloatTests() const
|
|
|
|
|
{
|
|
|
|
|
QFETCH(float, t1);
|
|
|
|
|
|
|
|
|
|
// Create two more values
|
|
|
|
|
// t2 differs from t1 by 1 ppm (part per million)
|
|
|
|
|
// t3 differs from t1 by 200%
|
|
|
|
|
// we should consider that t1 == t2 and t1 != t3
|
|
|
|
|
const float t2 = t1 + (t1 / 1e6);
|
|
|
|
|
const float t3 = 3 * t1;
|
|
|
|
|
|
|
|
|
|
QCOMPARE(t1, t2);
|
|
|
|
|
|
|
|
|
|
/* Should FAIL. */
|
|
|
|
|
QCOMPARE(t1, t3);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void tst_float::compareFloatTests_data() const
|
|
|
|
|
{
|
|
|
|
|
QTest::addColumn<float>("t1");
|
|
|
|
|
QTest::newRow("1e0") << 1e0f;
|
|
|
|
|
QTest::newRow("1e-7") << 1e-7f;
|
|
|
|
|
QTest::newRow("1e+7") << 1e+7f;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
QTEST_MAIN(tst_float)
|
|
|
|
|
|
|
|
|
|
#include "tst_float.moc"
|
