C 中的舍入快捷键
我正在用 C 语言实现伪代码：
delay = ROUND(64*(floatDelay - intDelay))
where intDelay = (int) floatDelay
floatDelay 将始终为正。 使用 math.h 中的舍入函数是否有优势：
#inlcude <math.h>
delay=(int) round(64*(floatDelay-intDelay));
或者我可以使用：
delay=(int)(64*(floatDelay - intDelay) + 0.5))
I am working in C to implement pseudo-code that says:
delay = ROUND(64*(floatDelay - intDelay))
where intDelay = (int) floatDelay
The floatDelay will always be positive. Is there an advantage to using the round function from math.h:
#inlcude <math.h>
delay=(int) round(64*(floatDelay-intDelay));
or can I use:
delay=(int)(64*(floatDelay - intDelay) + 0.5))
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
据我所知，除了强制转换为 int 对于其他程序员来说可能不会立即明显看出它像 trunc 一样工作之外，没有任何优点...
而对于 round 函数，您的意图很明确。
There isn't any advantages that I know of, other than the fact that the cast to int may not be immediately obvious to other programmers that it works like a trunc...
Whereas with the round function, your intentions are clear.
处理浮点数时，您应该始终使用适当的数学库。 浮点数可能只是实际值的非常接近的近似值，这可能会导致奇怪的情况。
例如，5f 可能近似于 4.9999999...如果您尝试直接转换为 int，它将被截断为 4。
要深入了解原因，您应该在维基百科上查找浮点数。 但简而言之，它不是像 int 那样将数字存储为一系列连续的位，而是存储为两部分。 有一个“分数”和一个指数，其中浮点数的最终值为分数*（基数^指数）。
You should always use the appropriate math libs when dealing with floating point numbers. A float may be only a very close approximation of the actual value, and that can cause weirdness.
For instance, 5f might be approximated to 4.9999999... and if you try to cast directly to int it will be truncated to 4.
To see why in depth, you should look up floating point numbers on wikipedia. But in short instead of storing the number as a straight series of bits like an int, it's stored in two parts. There's a "fraction" and an exponent, where the final value of the float is fraction * (base ^ exponent).
两者都可以，只要你说
floatDelay是正值。一个可能比另一个快一点，但考虑到 round() 很可能是作为编译器内在函数实现的，如果不进行基准测试就很难区分哪个。 更有可能的是，任何速度差异都是极其不重要的，因此使用您认为更清晰的那个。
Either is fine, provided as you say
floatDelayis positive.It's possible that one is marginally faster than the other, though it would be hard to tell which without benchmarking, given that
round()is quite possibly implemented as a compiler intrinsic. It's even more likely that any speed difference is overwhelmingly unimportant, so use whichever you feel is clearer.这是真的吗？
如果您确保在截断为 int 之前添加 0.5，
4.9999确实是个问题。
我是说：
4.9999+0.5=5.4999→ 5
/约翰
Is this really true?
If you make sure the you add the 0.5 before you truncate to int,
is really 4.9999 a problem.
I mean:
4.9999+0.5=5.4999 -> 5
/Johan