I thought this is going to be about floating point inaccuracies. For example, here's a Blender Geometry Nodes setup that instead of constructing a circle using

I thought this is going to be about floating point inaccuracies. For example, here's a Blender Geometry Nodes setup that instead of constructing a circle using a provided node "Circle", or by positioning and connecting points, which coordinates are calculated independently using an incremented angle, sine and cosine, instead draws a circle by walking in a circle: on each step ("extrusion"), the direction of the step is rotated by 360°/total_steps (for 360 steps it's rotated by 1°). The more steps there are, the bigger the accumulated floating point error (the error is guaranteed when positioning a new vertex, which position is stored as a xyz triplet of float32 values, but I imagine in Blender code floats are used as well). video: https://streamable.com/0xba64 https://streamable.com/0xba64 .gif: https://i.imgur.com/4Y33nrf.gif https://i.imgur.com/4Y33nrf.gif .blend file: https://e.pcloud.link/publink/show?code=XZvFUnZKrqbyl9h8ab3UCrJxdlBLHaW6qsX https://e.pcloud.link/publink/show?code=XZvFUnZKrqbyl9h8ab3U... Going back to the article, I like the illustrations depicting all possible values as areas; it seems you could calculate with a formula the boundaries of those areas and so draw them efficiently and allow to dynamically modify precision, ciechanow.ski style...