Similar method to python math.isClose but in runtime with IFloatingPointIeee754

[DrkWzrd]

Python currently has a convenience method to check if two floating point numbers are similar/close.

Is there an alternative built-in in the runtime?

[colejohnson66]

No because the concept of “is close” depends on your program’s concept of close. Is magnitude difference important? What about percentage? ULPs?

For example, are 500 and 505 close? It’s a magnitude difference of 5, but only a 1% change. In some situations, that would be fine (such as a milliliters for a recipe), but, in others situations, that’s a meaningful difference.

[tannergooding]

Is there an alternative built-in in the runtime?

No, and part of the reason is that such APIs are error prone, are often the incorrect thing to do/use, and have been incorrectly taken and used in places based on developers not fully understanding the contexts of where they would be appropriate.

IEEE 754 floating-point arithmetic is, by spec, deterministic. Additionally, it has what is effectively "variable precision" where the delta between representable values doubles every power of 2.

Most of the perception of needing "tolerance" comes from developers working and thinking about their math in base-10 when the values are actually base-2. They see 0.1 + 0.2 and think "oh, this must be equal to 0.3", when in actuality this isn't what the code is doing. The rest of the issue comes from them thinking about the math like real math, when in fact its an approximation and that remains true even for types like decimal which are base-10 floating-point types.

---

What actually happens for 0.1 + 0.2 is that you have parse("0.1") + parse("0.2") with the parse operations happening as part of the compiler interpreting the literal. This means that even though you wrote 0.1 + 0.2, the logic that actually gets executed is 0.1000000000000000055511151231257827021181583404541015625 + 0.200000000000000011102230246251565404236316680908203125. This logic produces an infinitely precise result of 0.3000000000000000166533453693773481063544750213623046875 which then rounds to the nearest representable result 0.3000000000000000444089209850062616169452667236328125. -- This result is closer to the infinitely precise result than parse("0.3"), which produces 0.299999999999999988897769753748434595763683319091796875 (which you'll note itself is closer to infinitely precise value the user gave: 0.3).

Even for decimal you get these precision and other fundamental issues, trivially. For example: ((1.0m / 3.0m) * 3.0m) != 1.0m, it rather instead produces 0.9999999999999999999999999999m because there is a limit to the precision representable and it follows the same rules of computing the infinitely precise answer using the represented input values and then rounding to the nearest representable. As another example, 79228162514264337593543950334.5m does not produce 79228162514264337593543950334.5, it produces 79228162514264337593543950334 due to the same general precision limitations and 79228162514264337593543950333.5m rounds up to the same value (due to round to nearest, ties to even). This compounds for operations where (a + b) + c can produce a different result from a + (b + c), where every operation compounds potential error, etc.

But, developers never really ask for isClose for such base-10 floating-point types, despite them having the same issues.

---

So the general issue is that developers see a mismatch between what they think is happening and what is actually happening; they then think (due to widespread misinformation and misunderstanding of the topic) that there's this fuzziness to the computation and that they need to account for it by saying "ehh, looks close enough" when in actuality that is the wrong thing to do and will almost consistently lead to bugs and other problems. -- A common example of this is it being a cause of clipping glitches in video games, because rather than testing against a finite boundary the logic instead did a "isClose" check and mistakenly allowed something through that should have otherwise collided.

Some of this nuance misunderstanding comes from why programming languages define some EPSILON value, which is simply meant to represent the maximum error between two representable values for a given power of two. In C, this is typically the distance between 1 and the next value greater than 1, while for .NET this is the distance between 0 and the next value greater than 0. .NET's epsilon is the "fundamental" epsilon and all are multiples of this, doing Abs(x) < double.Epsilon is then incorrect because nothing can be less than this epsilon, the only possible value is 0 meaning an exact match.

Other misunderstanding comes the handling of "near zero" (subnormal) values and various good algorithms using this to handle edge cases where division by it would cause infinity to be produced, thus it being something where you want to treat the value as zero for the purposes of indicating success or failure. That is, it looks like its being used as some form of isClose but in actuality its being used as an algorithm specific check for "will this produce a non-finite result which in the context of the algorithm means the result is functionally undefined". This is commonly used to cut out unnecessary work in Matrix and Vector operations where the computed result is too small or too large to be visible, or where the results (such as for computing the Determinant or Inversing the matrix) are nonsensical.

Once the format and its guarantees are understood and algorithms account for it and the representation, then it becomes clear that there are better and more efficient ways to test for correctness, for boundary cases, and whether or not something is "close enough" that it should be considered equivalent or that the compounded error has become too large. That the naive check for abs(x-y) <= tolerance (or a more complex variation) isn't the right answer in most cases even though it often trivially appears to make things work.

[tannergooding]

when it does come to something like 'Vector' operations the 'difference' in positions (0.999999999, 0) and (1, 0) is too small when used to do things like render vertices on a mesh to even be visible so in that case is '0.999999999, 0' close enough to (1, 0)

This depends on a lot of factors, including scaling and the underlying data type used. For float, 0.999999999f is rounded to 1.0f already; However, given valid representable values, one object that might be the difference between cells in the finger, for another object that might be the difference between houses.

Because of the way floating-point is distributed where 50% of all representable values exist between [-1, +1] and the other 50% exist between [MinValue, -1]; [+1, MaxValue] it is incredibly typical for all meshes to be stored (regardless of size) in a normalized state where all vertices have been scaled to exist between [-1, +1]. This then gets scaled (typically down, but sometimes up) to fit into an again normalized world space that also exists between [-1, +1] for the current chunk your camera is in. You use features like LOD to account for scenarios where the vertices would be too close to matter and therefore where a lower poly mesh is sufficient instead, so it remains a case where "isClose" or "approximately" isn't needed. You instead simply pick a limit based on your known world scale that exists between [-1, +1] and use that as a key to determine which LOD level needs to be used; similar processes are done for texture mipmaps, this isn't an "approximate" case either, but rather a boundary where values farther away then it (simply x > limit) use the lower resolution data; values that are behind the camera aren't visible (ignoring mirrors/etc) and can simply be culled entirely but can use a similar process if you're wanting to maintain a cache in the case the camera turns.

[StellarWolfEntertainment]

I suppose that specifically mentioning 'rendering' wasn't the best option, however when generating say a procedural mesh comprised of multiple 'smaller' regions as an advised step it that mesh won't be changing post generation (or if is will only do so rarely) is to 'optimize' the mesh, which means merging vertices that either share the same location or are within some threshold of a vertex [ie if the vertices are so close they may as well be the same location, and that is an approximate case] provided obviously that the other 'parameters' of the vertex [uv, normal...] are the same (or again close enough to be, though the 'tolerance' for if 'vertex' is close enough and 'uv' is may well be different)

[DrkWzrd]

it is incredibly typical for all meshes to be stored (regardless of size) in a normalized state where all vertices have been scaled to exist between [-1, +1]. This then gets scaled (typically down, but sometimes up) to fit into an again normalized world space that also exists between

Sorry, but this is entirely not true. When you work (in my experience) in engineering-metrology-medical-3d cadcam design, you have millimeters/microns, and tolerances, and the great majority (maybe all) softwares that creates/scans/registers the data (stl, obj, ply, whatever) don't scale it to anything. They store the points in a mm space (because the rawness is valuable), with float (or double) precision.

I know the fact that the floating point numbers nature make this things less intuitive, and that is not a problem at all (or maybe I should say "it is a problem I did not choose but I have to live with").

But when you are studying superimposition differences, and making (or trying to make) automatic processes that rely in fitting algorythms (and therefore, transformations or linear applications, geometric medians, planes/circles/conicals extractions, etc...), the maths are "crystal clear", and if the numbers were made by hand, there will not be any error nor problem, but when you have to apply the known math algorythms to floating point numbers, maybe the distance between two points differing between 0.001mm and 0.0009mm it is irrelevant and comes from the nature of how the 3d world relies in floating points, but for the software "there are not the same". And thats a problem, a problem that can be seen in many libraries of managing 3d meshes, all of them giving results "similar, but not equal" when processing the same origin file.

I appreciate the answer nevertheless, and I thought there should be a way to handle this gracefully built-in in c#. But now I ask humbly, what will be the way (plausible and quick) you recommend to handle it? How will you implement a method like that if you'd have to?

[tannergooding]

Sorry, but this is entirely not true. When you work (in my experience) in engineering-metrology-medical-3d cadcam design, you have millimeters/microns, and tolerances, and the great majority (maybe all) softwares that creates/scans/registers the data (stl, obj, ply, whatever) and they don't scale it to anything. They store the points in a mm space (because the rawness is valuable), with float (or double) precision.

I can't say for certain without seeing a concrete example, but serializing precise measurements as float/double will always introduce error. That error gets greater the larger the model; additionally, the larger the entire model is relative to the unit that 1.0 represents, the greater the total error/loss of data will be.

If you're serializing where 1.0 represents a meter, then you can generally get micron accuracy provided the entire scan is less than 16 meters (for float32); any larger and micron level data starts getting lost (and there is some inherent noise regardless). On the other hand if 1.0 represents a millimeter then you can start losing relevant data much sooner, potentially even at simply 1 meter. You get the best precision retention when the majority of the mesh is normalized to fit approximately within [-1, +1] and then tracking the scale it was downsized by (there's some tricks you can do depending on precision needs to allow slightly larger spaces, such as [-2, +2], but that comes with tradeoffs).

And thats a problem, a problem that can be seen in many libraries of managing 3d meshes, all of them giving results "similar, but not equal" when processing the same origin file.

This isn't an issue with floating-point, it's likely an issue with different libraries using different algorithms. IEEE 754 floating-point (and most other floating-point) is deterministic, by design, so any number of machines running the same algorithm will always produce the same result, if they produce different results then something in the algorithm or the inputs changed.

How will you implement a method like that if you'd have to?

Personally, I wouldn't. I would adjust the algorithms to fit within the domain and general problem space given, likely using a type of "floating-origin" and general chunking of the world into many [-1, +1] constrained cubes of some quadtree (2d) or octtree (3d). I would handle comparisons to use a mix of integer based coordinates into the tree that represents the world and then accurate comparisons within that chunk for the [-1, +1] domain to find the fractional portion of the data. This ends up highly efficient and produces the least amount of error; at worst you need to compute and combine the partial result of two world chunks (representing the chunks containing the start and end points).

If you really don't want to do that though; you can roll your own equivalent to the Python method:

public static bool IsClose(double a, double b, double relativeTolerance = 1e-09, double absoluteTolerance = 0.0)
{
    Debug.Assert(double.IsPositive(absoluteTolerance));

    // These conditions should already hold true, but I didn't double check:
    // * Ensure that `NaN` always returns false
    // * Ensure that `+Inf` is only close to `+Inf`
    // * Ensure that `-Inf` is only close to `-Inf`

    return double.Abs(a - b) <= double.Max(relativeTolerance * double.Max(double.Abs(a), double.Abs(b)), absoluteTolerance);
}