<story><title>How to compare floats in Python</title><url>https://davidamos.dev/the-right-way-to-compare-floats-in-python/</url></story><parent_chain><item><author>daenz</author><text>Floating point numbers are a common source of issues in large open world games. Because of how a float is stored, there is more precision for values closer to the &amp;quot;origin&amp;quot; of the world (0, 0, 0). Which means there is less precision for very far away things. This can result in things like &amp;quot;z-fighting&amp;quot;[0], which I&amp;#x27;m sure most gamers have seen, and also issues with physics.&lt;p&gt;One solution to address some of the precision issues (not necessarily z-fighting, as it operates in a different coordinate system) is to dynamically re-adjust the player&amp;#x27;s world origin as they move throughout the world. This way, they are always getting the highest float precision for things near to them.&lt;p&gt;0. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Z-fighting&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Z-fighting&lt;/a&gt;</text></item></parent_chain><comment><author>jbay808</author><text>Is there a reason that game developers don&amp;#x27;t use fixed-point math for Cartesian coordinates?&lt;p&gt;A 64 bit integer and a 64 bit float both chop up your coordinate system into the same number of points, but with the integer, those points are equally spaced which is the behaviour you&amp;#x27;d expect from a Cartesian coordinate system (based on the symmetry group of translational invariance).&lt;p&gt;And even a 32-bit integer is still fine enough resolution to support four kilometres at one-micrometer resolution. With 64 bits per axis you can represent the entire solar system with 15 nm resolution, while maintaining &lt;i&gt;equal resolution at any location&lt;/i&gt;, and exact distance calculations between any points no matter how close or how far.</text></comment>
<story><title>How to compare floats in Python</title><url>https://davidamos.dev/the-right-way-to-compare-floats-in-python/</url></story><parent_chain><item><author>daenz</author><text>Floating point numbers are a common source of issues in large open world games. Because of how a float is stored, there is more precision for values closer to the &amp;quot;origin&amp;quot; of the world (0, 0, 0). Which means there is less precision for very far away things. This can result in things like &amp;quot;z-fighting&amp;quot;[0], which I&amp;#x27;m sure most gamers have seen, and also issues with physics.&lt;p&gt;One solution to address some of the precision issues (not necessarily z-fighting, as it operates in a different coordinate system) is to dynamically re-adjust the player&amp;#x27;s world origin as they move throughout the world. This way, they are always getting the highest float precision for things near to them.&lt;p&gt;0. &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Z-fighting&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Z-fighting&lt;/a&gt;</text></item></parent_chain><comment><author>cyber_kinetist</author><text>I&amp;#x27;ve heard that the Star Citizen engine devs had to change all of their math operations in CryEngine from single to double precision to add support for seamless large worlds (the player origin hack has limits...) Don&amp;#x27;t even want to imagine how awful of a nightmare that would have been.</text></comment>