Floating-point comparisons are native widths on all OSX and iOS architectures.
For a float that comes to:
i386, x86_64:
- 32-bit XMM register (or memory for the second operand)
- using instructions in the
ucomiss family
ARM:
- 32-bit register
- using instructions in the same family as
vcmp
Some floating point comparison problems have been removed by restricting storage to 32/64 for these types. Other platforms can often use their own 80-bit FPU (example). In OS X, SSE instructions are preferred and they use natural width. Thus, it reduces many floating point comparison problems.
But there is still room for error or times when you prefer the approximation. One hidden piece of information about CGGeometry type values is that they can be rounded to the nearest integer (you can do this yourself in some cases).
Given the CGFloat range ( float or double -x86_64) and typical values, it is reasonable to assume that rounded values are usually represented fairly accurately, so that the results will be comparable in most cases. Thus, it is “fairly safe,” “fairly accurate,” and “pretty fast” within these limits.
There are still moments when you may prefer approximate comparisons in geometric calculations, but the apple implementation is what I consider closest to the reference implementation for a general purpose solution in this context.