Objective c CGAffineTransformMakeRotation对CGPoint的意外值

我使用CGAffineTransformRotation旋转CG点

执行此代码：

double degToRad(double degrees) {
  return ((degrees) * (M_PI / 180.0));
}

CGAffineTransform rotate = CGAffineTransformMakeRotation(degToRad(-90.0));

NSLog(@"before n.nP %@",NSStringFromCGPoint(node.nodePoint));

node.nodePoint = CGPointApplyAffineTransform(node.nodePoint, rotate);

NSLog(@"after  n.nP %@",NSStringFromCGPoint(node.nodePoint));

给出了以下结果：

before n.nP {96, 196}
after n.nP  {196, -95.999999999999986}

before n.nP {0, 768}
after n.nP  {768, 4.702643708725836e-14}

这是可以理解的,-95.999... 与-96相反，是由于一些内部舍入/对

M_PI

的表达程度的限制。这种情况下的差异程度可以忽略不计

但这些结果：

before n.nP {96, 196}
after n.nP  {196, -95.999999999999986}

before n.nP {0, 768}
after n.nP  {768, 4.702643708725836e-14}

---

…是什么让我困惑。我期望

{768，0}

或pretty dang close作为返回值。为什么这种情况下的差异程度如此之大？

所以差异并没有那么大。事实上，它非常小！在我们开始讨论为什么会有这种差异之前，让我们解释一下这种差异的含义：

在n.np{768，4.702643708725836e-14}之后

注意末尾的

e-14

。这意味着

4.702643708725836 x 10^-14

，或

0000000000000 4702643708725836

，非常接近于0。要了解更多有关E表示法的信息

---

现在，为什么会发生这种情况，是因为M_π和。浮点数（float）是C语言（以及许多其他语言）表示非整数（int）的方式。它使用一种基于近似的方法，因为不可能用真实的位数来表示所有的数字。double与float类似，但使用两倍的位（因此是double）来表示实数，因此具有更高的精度。但它们仍然是近似值，有时会有一些不准确的小瑕疵，因此。

哦，天哪，我当然知道E符号，我只是搞错了，忽略了它！你的回答被接受了，特别是因为它没有引起太多的注意我的草率愚蠢。。。FWIW，我添加了一个floorf（）post计算，因为在某些情况下，我需要4.702643708725836e-14精确为0