我知道UIKit使用CGFloat，因为它是分辨率无关的坐标系。
但每次我想检查frame.origin.x是否为0时，我都觉得很恶心:
if (theView.frame.origin.x == 0) {
// do important operation
}
当与==，<=，>=，<，>比较时，CGFloat是否容易出现假阳性? 它是一个浮点数，它们有不精确的问题:例如0.0000000000041。
Objective-C在比较时是否会在内部处理这个或者是否会发生原点。读作0的X不与0比较为真?
当前回答
我使用下面的比较函数来比较小数点后的数位:
bool compare(const double value1, const double value2, const int precision)
{
int64_t magnitude = static_cast<int64_t>(std::pow(10, precision));
int64_t intValue1 = static_cast<int64_t>(value1 * magnitude);
int64_t intValue2 = static_cast<int64_t>(value2 * magnitude);
return intValue1 == intValue2;
}
// Compare 9 decimal places:
if (compare(theView.frame.origin.x, 0, 9)) {
// do important operation
}
其他回答
我认为正确的做法是将每个数字声明为一个对象，然后在该对象中定义三个东西:1)相等运算符。2)一个setAcceptableDifference方法。3)价值本身。如果两个值的绝对差小于设置为可接受的值，则相等运算符返回true。
您可以对对象进行子类化以适应该问题。例如，如果1到2英寸之间的圆金属棒的直径相差小于0.0001英寸，则可以认为它们的直径相等。因此，您可以使用参数0.0001调用setAcceptableDifference，然后放心地使用相等操作符。
因为0完全可以表示为一个IEEE754浮点数(或者使用我曾经使用过的任何其他f-p数字实现)，与0比较可能是安全的。然而，如果你的程序计算了一个值(比如theView.frame.origin.x)，你有理由相信它应该是0，但你的计算不能保证它是0，你可能会被咬。
为了澄清一点，计算如下:
areal = 0.0
会(除非你的语言或系统坏了)创建一个值(areal==0.0)返回true，但另一个计算，如
areal = 1.386 - 2.1*(0.66)
可能不会。
如果你能保证你的计算产生的值是0(而不仅仅是它们产生的值应该是0)，那么你可以继续将f-p值与0进行比较。如果你不能保证自己达到要求的程度，最好坚持通常的“宽容平等”方法。
在最坏的情况下，不小心比较f-p值可能是极其危险的:想想航空电子设备、武器制导、发电厂操作、车辆导航，几乎所有计算与现实世界相结合的应用。
对《愤怒的小鸟》来说，没有那么危险。
-(BOOL)isFloatEqual:(CGFloat)firstValue secondValue:(CGFloat)secondValue{
BOOL isEqual = NO;
NSNumber *firstValueNumber = [NSNumber numberWithDouble:firstValue];
NSNumber *secondValueNumber = [NSNumber numberWithDouble:secondValue];
isEqual = [firstValueNumber isEqualToNumber:secondValueNumber];
return isEqual;
}
The last time I checked the C standard, there was no requirement for floating point operations on doubles (64 bits total, 53 bit mantissa) to be accurate to more than that precision. However, some hardware might do the operations in registers of greater precision, and the requirement was interpreted to mean no requirement to clear lower order bits (beyond the precision of the numbers being loaded into the registers). So you could get unexpected results of comparisons like this depending on what was left over in the registers from whoever slept there last.
也就是说，尽管我一看到它就努力删除它，但我工作的机构有大量使用gcc编译并运行在linux上的C代码，我们已经很长时间没有注意到这些意想不到的结果了。我不知道这是否是因为gcc为我们清除了低阶位，80位寄存器在现代计算机上不用于这些操作，标准已经改变了，还是什么。我想知道是否有人可以引用章节和诗句。
我想给出一个和其他人不一样的答案。他们很好地回答了你的问题，但可能不是你需要知道的或你真正的问题是什么。
图形中的浮点数很好!但是几乎没有必要直接比较浮点数。你为什么要这么做?图形使用浮点数来定义间隔。比较浮动是否在浮动所定义的区间内总是定义良好的，只需要保持一致，而不需要精确或精确!只要可以分配一个像素(这也是一个间隔!)，这就是所有的图形需求。
所以如果你想测试你的点是否在a [0..]宽度[范围，这很好。只要确保你对包含的定义是一致的。例如，总是定义内部是(x>=0 && x < width)。这同样适用于交叉测试或命中测试。
但是，如果您滥用图形坐标作为某种标志，例如查看窗口是否停靠，则不应该这样做。使用一个独立于图形表示层的布尔标志。
