The heck is wrong with the testing framework. I can obviously see that it a correct value why doesn't the test case pass.

FAILED:
REQUIRE( positive==static_cast<double>(0.7352941176) )
with expansion:
0.7352941176 == 0.7352941176

===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed

Precision? Esp. with a cast? Just a guess :)

try comparing with a ridiculously narrow range rather than the concrete value

@netikras could you explain it more in detail?

@mr-user I'm on mobile atm, so no copy-paste. Also I'm more java-oriented rather than C, but we have this problem too. It's recommended to test values with dec points to be in a range rather than with ==.

E.G. assert(myValue, 0.075, 0.001)
which means

assert myValue > 0.074
assert myValue < 0.076

since you're playing with dec points, precision is very slippery. Depends on a cpu, on a data type and... Direction of the wind :) double and float values have different precision too, so casting them to each other will definitdly cause trouble when comparing with ==. BigDecimal is prolly the only precision-safe type in Java.

I'm guessing you're stepping on the same mine in C

Floating point math.
One or both values are probably off by a tiny tiny bit due to how it all works.

Tired; not explaining further.
Here’s a description with the best domain name ever:

https://0.30000000000000004.com/

@netikras That seem to be a problem.

@Root thank for your info.

@netikras @Root I thought doubles used different rules for precision. Then again, the standards for c and c++ leave a lot up to what the system can handle and don't guarantee much behavior.

I'm just going to guess that the standards allow for floating point precision on CPUs that would otherwise grind to a halt on decimal ops otherwise.

@AlgoRythm @mr-user

https://docs.microsoft.com/de-de/...

TLDR: float and double store a number as an mathematical expression, not as a fixed number.

Precision - simply put - means just a larger range can be stored, not that the end result is "more precise".

You never EVER test float/double for equality. This is also e.g. a MISRA rule in automotive.

Floating point precision numbers should never be tested by raw equality.

You need to perform an equality test with margin of error.

@AlgoRythm decimal numbers are stored as two int values so are generally more accurate when storing numbers that can be represented as such.