Why 0.1 + 0.05 is not equal to 0.15

Oh, come on ! :smiley:

It reminds me of how there are countable infinities and uncountable infinities. For example, there are more numbers between 0 and 1 then there are integers. When we try to stuff the infinite into the finite space of a computer you have to make compromises somewhere.

1 Like

The Donald Rumfeld paradox ?

Hello everyone, here is a preview of my PR:

It has a default tolerance of 0.0000001, even if you don’t use a mutator. It should solve the problem of 0.1+0.2 not being equal to 0.3

image

PR:

You are missing the test case 0.3 > 0.1 + 0.2

It's not equivalent to the 0.1+0.2<0.3 test.

@ABG both return false in my test

1 Like

That should cover all the cases.

1 Like

Thanks :grinning_face: I’ll include it in my PR

I forgot to include tests with negative numbers.

Do those fool the offsets?

Also, you're going to love this one:

Take the 4 * 3 cross comparisons of the 4 complex numbers at +/- 1 +/- i (n X at the origin of the complex plane.)

Then take an aspirin.
You'll probably need it.

1 Like

No, they work fine. This is the internal operation for different operators:

and, about the complex number comparison, the comparison itself is invalid. It should throw an error as ordering operators are not defined for complex numbers. The behavior is weird though :face_without_mouth:

Are the two signs exchanged?

No, my intention behind using opposite directions of tolerance in LT & LTE is to include near-equal values in LTE.

Example: arg1 = 10 and tolerance = 0.001

LTE: if arg0 is 10.0005 I want LTE to return true as 10.0005 is a near-equal value to 10, that’s why + tolerance is there (10.0005 <= 10.001)

LT uses - for the opposite reason, it should exclude near-equal values.

Any chance of getting this up on a test server, so we can hit it with corner cases?

You need to fetch my PR branch & compile it locally to run on your localhost. Then you can test it OR you can send me test values, I’ll post the result here