Closed TheZoq2 closed 5 years ago
Nice find @TheZoq2 ! Can you please change your MR request so it will merge into develop
? I will bring your fix into develop
, write some unit tests around this bug fix, and then make a new release to master
.
@TheZoq2 I just found out I can change the base branch myself. I will hopefully merge this fix soon!
Merging #96 into develop will not change coverage. The diff coverage is
100%
.
@@ Coverage Diff @@
## develop #96 +/- ##
========================================
Coverage 92.07% 92.07%
========================================
Files 2 2
Lines 227 227
========================================
Hits 209 209
Misses 18 18
Impacted Files | Coverage Δ | |
---|---|---|
include/MFixedPoint/FpF.hpp | 100% <100%> (ø) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 3db2782...44f2573. Read the comment docs.
Great, thanks! In the mean time, I found another similar issue.
using Fp = mn::MFixedPoint::FpF<int64_t, int64_t, 25>;
Fp a = 75;
REQUIRE(a == 75); // Fails because a == -53
This seems to be caused by the constructors from ints cast the values to int32_t
instead of BaseType
. My latest commit seems to fix that issue
I think I discovered and fixed a pretty nasty bug in this library. To start off, here are the symptoms:
Clearly, the result of the above code should be ~52, however, the actual output is 2. If the fractional bit amount is 19, the output is correct.
As far as I can tell, the issue comes from the fact that FpFMultiply uses 32 bit values as inputs even if the BaseType used is 64 bit.