Float precision with vector key maps

I’m wondering if using a vector as a key type for maps is stable. I know the engine likes to add (or subtract) a non-zero but negligible amount to vectors at least with viewport transformations I.e. +0.0000002 First I’m curious why it does that, but more importantly is a map key checking exactly equal or nearly equal? If nearly to what decimal? I haven’t had time to test these myself.

Thanks
-Aaron

It won’t work very well because of floating point errors. There is a limit to how accurate a number can be represented. So if you are using GetActorLocation etc. it’s not going to be reliable/precise enough to work in a map. Even explicitly setting a value probably won’t always work.

In C++ you could probably write your own check so it uses nearly equal instead of ==. I’m not sure if that is possible in Unreal, or if it would even be a good thing to do.

An Int vector would work better, if that fits what you want to do. If you are dealing with actors in 3D space that are aligned to a grid, you could store their rounded locations as Int vectors as a variable, and use that in the map. Depends on what you are trying to do.

1 Like

Is this verified or are you going by intuition? (for clarity) Also I didn’t realize int vectors were a thing in ue4 O.o I was going to say I need to know for sure for simplicity/stability in my code, but int vectors is a decent compromise either way. Sleepless me encoded coords into a string for the keys when maps came to blueprints. Came back to it and wondered why I didn’t just use vectors, lol.

Okay I had a hunch that’s how it was, I understand floating point errors when using arithmetic, and I’ve seen stray values in the editor so I got nervous about using it. If I’m rounding to fix errors I may as well just use the int vectors then. Thanks for the help Mosel3y :slight_smile:

Actually, I think rounding would be the best option, really. Beyond not having conversions, fractional grid spaces would still be possible. I’m uncertain if it might still give errors after rounding though. Logically it wouldn’t make sense, but I can’t bring myself to trust vectors because of the viewport value drift. I’ll test further myself later, unless you’re up to it.

Well, a bit of both. But for example, the below won’t work:

The first will work, but the second won’t even though a human would expect both numbers to be the same… the error introduced when modifying the number means it isn’t reliable. It gets worse the larger the number. Even when entering values in a vector you will see the value change. I would only possibly do this if the numbers are not to large, and you are explicitly setting them and never doing any modification of them.

In another project I tried, spawning 10 cubes in random locations, add adding each generated location vector to a map as the key. Add adding each cube to an array. Then iterating through the cube array, GetLocation on each one and attempting to find the location vector in the map.

It worked fine without rounding, even when the cubes were spawned in a 10,000,000x10,000,000x10,000,000 unit area.

I offset the cubes, and then moved them back and it still found the keys.
But again, if I used used multiplication or division on the vector before setting them back, only some keys would be found

It works better than I would have expected, but I suppose, it’s going to depend on what you are doing… I wouldn’t rely on it unless what you are doing is somewhat deterministic though.