Analysis of problems with the new test for qFuzzyIsNull() revealed
that, where its version for double uses approximately 4500 * epsilon
and for float used 84 * epsilon as threshold, the qfloat16 version's
value was barely more than epsilon, with the result that the test had
to use a different value than the threshold to pass. (Converting the
threshold from float to qfloat16 and back made it bigger; in effect,
the threshold value was not <= itself.)
Furthermore, comparison with qFuzzyCompare() implied a value of
1/102.5 should be used, roughly 10 * epsilon, for consistency. When
1/102.5 is rounded to three significant digits (the precision we use
in QTest::toString(), for example), to give 0.00976f as threshold, we
get a value that, after conversion to qfloat16 and back to float, does
give a result <= what we started with. So change qFuzzyIsNull() and
its test to use this as qfloat16's threshold value.
[ChangeLog][QtCore][QFloat16] The qfloat16 threshold value for
qFuzzyIsNull() has changed from 1e-3 to 9.76e-3, almost a factor of
ten increase, for consistency with qFuzzyCompare()'s tolerance. Values
between these would previously have had qFuzzyIsNull(f) false despite
qFuzzyCompre(f, 1+f) being true.
Change-Id: I35816dce78da34a3e2339c8bc42d5bd03714a3f6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They were missing.
I also wanted to verify that it's true for sub-normal values.
At the same time, relocate qfloat16's implementation of qFuzzyIsNull()
to between those of qFuzzyCompare() and qIsNull(), since its apparent
absence initially confused me.
Change-Id: I9637c0070e754d16744c76fc9f846596257c6a63
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Calibrated to match F16C and ARM-FP16 hardware conversions.
Change-Id: I3bdd4d3db3046fee4aeb24e4ce8b9bc9a06e0397
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Our hardware optimized conversions of float to qfloat16 rounds to even
where our table based conversion truncated to zero.
The rounding is not in this patch exactly round to even like the
hardware implementation but much closer.
Change-Id: I4c5e72c15fef9079d3660680b2727ff7ba4e768a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Infinite is only when the mantissa is 0, everything else is NaN.
std::isnormal returns false on zero.
Pick-to: 5.15
Change-Id: I897fc0dc3b8a9c557bb1922ea7ca8df501e91859
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use pro2cmake with '--api-version 2' to force regenerate
projects to use the new prefixed qt_foo APIs.
Change-Id: I055c4837860319e93aaa6b09d646dda4fc2a4069
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It is finite and normal; it classifies as a zero; and it should not be > qfloat16(0).
Added tests to match.
Change-Id: I7874fb54f622b4cdf28b0894050ad3e75cf5d77c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Its limits() test was rather large and had some overlap with an older
qNan() test, that needed some clean-up (it combined qfloat16 values
with double and float values in ways that caused qfloat16 to be
promoted to another type, so we weren't testing qfloat16).
Renamed the qNan() test to qNaN(), separated out the parts of it that
actually tested infinity. Moved various parts of limits() to these and
rationalised the result. Split out a properties() test from limits()
for the properties of the qfloat16 type that are supplied by its
numeric_limits. Split out a data-driven finite() test to cover some
repeated code that was in limits() and extended it to test more
values. Added more tests of isNormal().
Fixed my earlier UK-ish spelling of "optimise", in the process, and
identify the processor rather than the virtualization as the context
where the compiler errs.
Change-Id: I8133da6fb7995ee20e5802c6357d611c8c0cba73
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not clear why this test fails - and only does so sometimes - but
fail it does, so we ned to skip it to let development keep going. As
it happens, the same platform over-optimizes various computations
using qfloat16; which can at least be used to test for this platform,
since it wrongly distinguishes two qfloat16 values that theory and all
other platfomrs agree should coincide.
Fixes: QTBUG-75812
Change-Id: Ie9463d7dc21bca679337b475d13417b9f42bbf9b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It should have been qfloat16(1)/qfloat16(infinity) in any case.
Sadly, that behaves no better than qfloat16(1.f/qfloat16(infinity)),
which was promoting the infinity back to float. So retain the check
for over-optimization (but make the comment more accurate).
This is a follow-up to d441f6bba7.
Change-Id: Iec4afe4b04081b0ebfbf98058da606dc3ade07f4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In QCOMPARE, handle NaNs and infinities the way tests want them
handled, rather than by strict IEEE rules. In particular, if a test
expects NaN, this lets it treat that just like any other expected
value, despite NaN != NaN as float16 values. Likewise, format
infinities and NaNs specially in toString() so that they're reported
consistently.
Enable the qfloat16 tests that depend on this QCOMPARE() behavior.
Refise the testlib selftest's float test to test qfloat16 the same way
it tests float and double (and format the test the same way).
This is a follow-up to 37f617c405.
Change-Id: I433256a09b1657e6725d68d07c5f80d805bf586a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This extends support for qfloat16 sufficiently for the things testlib
needs in order to treat it as a first-class citizen. Extended tests
for qfloat to check qFpClassify() on it.
Change-Id: I906292afaf51cd9c94ba384ff5aaa855edd56da1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This shall make it more nearly a first-class numeric type; in
particular, I need some of these for testlib's comparing and
formatting of float16 to handle NaNs and infinities sensibly.
Change-Id: Ic894dd0eb3e05653cd7645ab496463e7a884dff8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both ARM and x86 can convert fp16 much faster in bulk than one at a
time. This also enables hardware accelerated conversion on x86, when
F16C isn't unconditionally available at compile time.
This code is implemented in C to ensure that there's no leakage of
inline symbols from the .obj file that was compiled by Visual Studio
with AVX support. Unfortunately, simd.prf uses $(CXX) instead of $(CC)
for all its sources, which means the file gets interpreted as C++ by
g++, clang++ and icpc. Those compilers at least don't leak any symbols.
Done-with: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I9d26d99e83392861fb09564e0e8e8d76cd8483b3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The operator double() and operator long double() members of qfloat16
are causing cast ambiguities. This removes them, leaving only
operator float() which seems to be adequate.
Also, additional arithmetic operator tests were added which without
this removal fail to compile.
Change-Id: Id52a101b318fd754969b3de13c1e528d0aac2387
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This constitutes a fairly complete submission of an entirely new
floating point type which conforms to IEEE 754 as a 16-bit storage
class. Conversion between qfloat16 and float is currently performed
through a sequence of lookup tables. Global-level functions
qRound(), qRound64(), qFuzzyCompare(), qFuzzyIsNull(), and
qIsNull() each with a qfloat16 parameter have been included
for completeness.
[ChangeLog][QtCore] Added new qfloat16 class.
Change-Id: Ia52eb27846965c14f8140c00faf5ba33c9443976
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
