collision system produces points / vectors that are 'not equal' despite being equal by value.

[BMaxV]

Description

Ok, I found it. It's python floating point imprecision. Not sure how to fix it. Some details / workarounds can be found in the official docs though.

https://docs.python.org/3/tutorial/floatingpoint.html

The docs mention .as_integer_ratio() to find the "true value" and I included that in the script, which shows that the problem is coming from panda internals and not the python defined values.

Steps to Reproduce

I created a script that reproduces the bug.

https://github.com/BMaxV/collision_points_bug

The 'comp_d' were created by just printing to console and copy pasting them back into the script.

from panda3d.core import CollisionTraverser, CollisionNode
from panda3d.core import CollisionHandlerQueue  # , CollisionRay
from panda3d.core import CollisionSphere  # CollisionHandlerPusher
from panda3d.core import CollideMask
from panda3d.core import NodePath
from panda3d.core import LVector3f, LPoint3f


def main():
    rd1 = setup(3)
    comp_d1 = {'0': {'sp': LPoint3f(1.6, 0, 0), 'cp': LPoint3f(3, 0, 0), 'ip': LPoint3f(1.5, 0, 0), 'cn': LVector3f(1, 0, 0)}, '1': {
        'sp': LPoint3f(1.5, 0, 0), 'cp': LPoint3f(0.1, 0, 0), 'ip': LPoint3f(1.6, 0, 0), 'cn': LVector3f(-1, 0, 0)}}
    print("these dicts are 'not equal'")
    print(rd1 == comp_d1)
    
    print(rd1)
    print(comp_d1)
    print("")
    for key1 in rd1:
        for key2 in rd1[key1]:
            v1=rd1[key1][key2]
            v2=comp_d1[key1][key2]
            if v1!=v2:
                print("")
                print("these are 'not equal'")
                print(key1,key2)
                print(v1,v2)
                print(list(v1),list(v2))
                c=0
                m=3
                print("")
                while c < m:
                    print("v1",list(v1)[c].as_integer_ratio())
                    print("v2",list(v2)[c].as_integer_ratio())
                    c+=1
                print("")

    print("")
    rd2 = setup(2.5)
    comp_d2 = {'0': {'sp': LPoint3f(1.6, 0, 0), 'cp': LPoint3f(2.5, 0, 0), 'ip': LPoint3f(1, 0, 0), 'cn': LVector3f(1, 0, 0)}, '1': {
        'sp': LPoint3f(1, 0, 0), 'cp': LPoint3f(0.1, 0, 0), 'ip': LPoint3f(1.6, 0, 0), 'cn': LVector3f(-1, 0, 0)}}

    print(rd2 == comp_d2)


def setup(x):
    node_root = NodePath("node_root")

    cTrav = CollisionTraverser()

    CH_queue = CollisionHandlerQueue()

    Col1 = CollisionNode('col1')
    Col1.addSolid(CollisionSphere(center=(0.1, 0, 0), radius=1.5))
    Col1.setFromCollideMask(CollideMask.bit(1))
    Col1.setIntoCollideMask(CollideMask.bit(1))
    Col1NP = NodePath(Col1)
    Col1NP.reparentTo(node_root)

    Col2 = CollisionNode('col2')
    Col2.addSolid(CollisionSphere(center=(x, 0, 0), radius=1.5))
    Col2.setFromCollideMask(CollideMask.bit(1))
    Col2.setIntoCollideMask(CollideMask.bit(1))
    Col2NP = NodePath(Col2)
    Col2NP.reparentTo(node_root)

    cTrav.addCollider(Col1NP, CH_queue)
    cTrav.addCollider(Col2NP, CH_queue)

    cTrav.traverse(node_root)

    entries = CH_queue.getEntries()
    CH_queue.clearEntries()

    m = len(entries)
    c = 0

    rd = {}
    while c < m:
        entry = entries[c]

        collisionargs = [entry]

        fromn = collisionargs[0].from_node
        inton = collisionargs[0].into_node

        surface_point = collisionargs[0].getSurfacePoint(node_root)
        contact_pos = collisionargs[0].getContactPos(node_root)
        interior_point = collisionargs[0].getInteriorPoint(node_root)
        collision_normal = collisionargs[0].getSurfaceNormal(node_root)

        result_l = [surface_point, contact_pos,
                    interior_point, collision_normal]
        my_d = {str(c): {"sp": surface_point, "cp": contact_pos,
                         "ip": interior_point, "cn": collision_normal}}
        rd.update(my_d)

        c += 1

    return rd


if __name__ == "__main__":
    main()

Environment

• Operating system: linux
• System architecture: x86
• Panda3D version:1.10.14
• Installation method: pip
• Python version (if using Python): Python 3.10.12
• Compiler (if using C++): ---

[ArsThaumaturgis]

I'm not sure that this is a bug, per se, but rather a standard limitation of working with floats.

In general--and not just in Python--I seem to recall that it's advised to avoid attempting to attempt equality tests between floats.

Instead, one tends to test for "nearness"--for the floats to be the same within a given tolerance.

And indeed, Panda's vector classes provide a set of methods by which to deal with that: "almostEqual".

(To be specific, there are two variants of "almostEqual": one that takes only a vector against which to compare, using a default tolerance, and one that additionally takes a specified tolerance.)

Further, there's the "compareTo" method, which sorts vectors relative to each other, again using a tolerance-value.

Consider the following slightly-artificial example:

from panda3d.core import Vec3

vec1 = Vec3(0.1, 0.2, 0.3)
vec2 = Vec3(0.10000001, 0.2, 0.3)

print (vec1 == vec2)
print (vec1.almostEqual(vec2))

On my machine, this prints out the following:

False
True

Now, this does make comparing dictionaries of vectors a bit trickier. I might suggest something like this:

result = all([dict1[key].almostEqual(dict2[key]) for key in dict1.keys()])
print (result)

[BMaxV]

Yes, they mention that in the docs I linked.

I didn't make it really clear what the output is.

If you compare the two vectors, it says they are NOT equal.

if you then PRINT the vectors, they print as:

LVector3f(-1, 0, 0) LVector3f(-1, 0, 0)

Maybe that's "just" something wrong with __repr__ function. And if you convert to lists it does print correctly.

[-0.9999999403953552, 0.0, 0.0] [-1.0, 0.0, 0.0]

So there is definitely something wrong. Maybe it's a "won't fix" but it at least deserves a mention in the docs.

[ArsThaumaturgis]

If you compare the two vectors, it says they are NOT equal.

I tried that myself, using the values that you printed, via the following simple program:

from panda3d.core import Vec3

v1 = Vec3(-1.0, 0.0, 0.0)
v2 = Vec3(-0.9999999403953552, 0.0, 0.0)

print (v1 == v2)
print (v1.almostEqual(v2))

On my end, this prints the following:

False
True

As expected.

Going back to your original code, I modified it to use "almostEqual" instead of "==". The code is perhaps not ideal, but I think that it should work.

Specifically, the "main" function now looks like this:

def main():
    rd1 = setup(3)
    comp_d1 = {'0': {'sp': LPoint3f(1.6, 0, 0), 'cp': LPoint3f(3, 0, 0), 'ip': LPoint3f(1.5, 0, 0), 'cn': LVector3f(1, 0, 0)}, '1': {
        'sp': LPoint3f(1.5, 0, 0), 'cp': LPoint3f(0.1, 0, 0), 'ip': LPoint3f(1.6, 0, 0), 'cn': LVector3f(-1, 0, 0)}}
    print("these dicts are 'not equal'")
    tempList = []
    for key in rd1.keys():
        subDict1 = rd1[key]
        subDict2 = comp_d1[key]
        
        result = all([subDict1[key2].almostEqual(subDict2[key2]) for key2 in subDict1.keys()])
        tempList.append(result)
    result = all(tempList)
    print(result)
    
    rd2 = setup(2.5)
    comp_d2 = {'0': {'sp': LPoint3f(1.6, 0, 0), 'cp': LPoint3f(2.5, 0, 0), 'ip': LPoint3f(1, 0, 0), 'cn': LVector3f(1, 0, 0)}, '1': {
        'sp': LPoint3f(1, 0, 0), 'cp': LPoint3f(0.1, 0, 0), 'ip': LPoint3f(1.6, 0, 0), 'cn': LVector3f(-1, 0, 0)}}

    tempList = []
    for key in rd2.keys():
        subDict1 = rd2[key]
        subDict2 = comp_d2[key]
        
        result = all([subDict1[key2].almostEqual(subDict2[key2]) for key2 in subDict1.keys()])
        tempList.append(result)
    result = all(tempList)
    print(result)

(I've removed the printing out of the dictionaries for the sake of simplicity.)

And indeed, on my end it prints out "True" for both sets of dictionaries, suggesting that using "almostEqual" works.

Maybe that's "just" something wrong with repr function. And if you convert to lists it does print correctly.

More likely it's just rounding to the nearest few decimal places.

[BMaxV]

Whether or not a workaround exists is beside the point.

I wrote an issue because the default output is misleading.

Imo, that's bad behavior and a "bug".

[ArsThaumaturgis]

Regarding the approach that I showed, I'd argue that it's not really a workaround: it's how floats are handled, I fear. It is, in general, inadvisable to attempt simple equality-testing with floats.

As to the output of "print", that's a little more complex, I think:

To start with, the output of a simple "print"-statement should go through the "__str__" function, if available--which should produce an easy-to-use, human-readable approach, intended for end-users, not devs, I believe.

For this purpose, a rounded value seems appropriate to me-- "Vec3(-0.1, 0, 0)" is far more readable than "Vec3(-0.9999999403953552, 0, 0)"--let alone should the latter have three such values.

However, based on a quick look, it seems that the vector-class doesn't have a "__str__" function. In this case I gather that print falls back on the "__repr__" function--as though it had been passed the result of a call to the built-in "repr" function.

And "__repr__" is supposed to produce something that (to quote the Python docs) "... should look like a valid Python expression that could be used to recreate an object with the same value ...". It's intended for developer-use.

Now, it's true that the vector-class's "__repr__" function doesn't do this--it appears to apply some rounding (to six decimal places, it seems).

But I'd argue that for most game-developer purposes, that's more than precise enough. How often does one need to know a position or velocity or other such common point or vector to more than six decimal places?

And conversely, printing to the fullest extent seems likely to make many vectors far less readable, making debugging via printout more difficult.

So I'd argue that, for the presumed purposes of this vector-class, it's appropriate for the representation of vectors to be rounded a little.

[rdb]

@ArsThaumaturgis has explained well that this is a limitation of floats. It's why 0.1 + 0.2 isn't 0.3 in Python. On top of that, Panda uses single-precision floats (for performance), Python uses double-precision floats.

That said, I realise it seems confusing that two different floats still print the same way. I am wondering if Python has some special way of doing this. I tried printing 0.1 and it prints 0.1, even though the number 0.1 is not exactly representable using a floating-point number. It seems it does some rounding, but just the correct amount.

From investigating, Python uses a special implementation of dtoa that guarantees "correctly rounded" conversions with just the right amount of decimal digits for this to work this way.

I can see about modifying Panda's vector repr() function to also satisfy this guarantee. A round-trip through repr() should yield the same vector.

[BMaxV]

Thank you, that sounds like a solution.

[rdb]

C++17 has to_chars, which can do minimum-size representations. Until such time as we adopt C++17, I implemented a hackier approach to convert floats to strings without excessive precision.

0.9999999403953552 will now be printed as 0.99999994, since these are equal with single-precision floats. At the same time, 3.3 will still be printed as 3.3 instead of 3.29999995.