blocks|key|1958925|text|math.h函数是GNU+C库的一部分，而不是GCC编译器。它们的准确性是作为GNU+C+Library+manual的一部分记录在here中的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1958926|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gnu.org/software/libc/manual/|1|http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions^0|0|6|13|K|0|1U|4|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@$9|S|A|T|1|U]|$9|V|A|W|1|X]]|E|$]]|$1|F|3|-4|5|6|7|Y|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

The <code>math.h</code> functions are part of the GNU C Library, not the GCC compiler. Their accuracy is documented <a href="http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions" rel="noreferrer">here</a>, as part of the <a href="http://www.gnu.org/software/libc/manual/" rel="noreferrer">GNU C Library manual</a>.

blocks|key|3948785|text|唯一安全的假设是glibc数学精度图表中的'-‘字符：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3948786|http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions|offset|length|3948787|意思是“未测试”，因为缺乏官方文件表明不是这样的。|3948788|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|2W|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

The only safe thing to assume is that the '-' characters in the glibc math accuracy chart:

<a href="http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions" rel="nofollow">http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html#Errors-in-Math-Functions</a>

mean "not tested", given the lack of official documentation suggesting otherwise.

blocks|key|3948815|text|错误确实列出了here，但我认为"-“意味着”正确四舍五入“的假设(即1/2ULP)几乎肯定会被页面顶部的声明驳斥|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3948816|3948817|+GNU库的目标不是数学库中函数的正确舍入结果...相反，没有完全指定结果的函数的准确性目标如下；一些函数有bug，这意味着它们在所有情况下都不能满足这些目标。将来，GNU+C库可能会提供一些其他正确的四舍五入函数，例如建议对ISO+C进行扩展的crsin。|blockquote|3948818|3948819|3948820|在研究了一下源代码之后，我发现似乎是the+results+of+a+ulp+test+(针对x86-64)。看起来，对于默认的舍入模式(四舍五入到最近，平局到偶数)，他们只在long+double+(80位IEEE)的ULP值比float差时才显式测试double。隐含的假设似乎是double不会比long+double更糟糕。对于定向舍入模式，它们似乎总是显式地测试float和double。|style|CODE|3948821|不过，也有一些奇怪的地方。|3948822|3948823|没有列出exp.|unordered-list-item|3948824|For+cos和tan的测试结果，它们只测试真实/复杂的测试结果|3948825|3948826|entityMap|0|LINK|mutability|MUTABLE|url|http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html|1|https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/fpu/libm-test-ulps;hb=HEAD^0|7|4|0|0|0|0|0|0|2G|B|37|5|3J|6|3Y|6|47|B|56|5|5C|6|I|P|1|0|0|0|4|3|0|4|3|8|3|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@$A|17|B|18|1|19]]|C|$]]|$1|D|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1B|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1E|8|@$A|1F|B|1G|L|M]|$A|1H|B|1I|L|M]|$A|1J|B|1K|L|M]|$A|1L|B|1M|L|M]|$A|1N|B|1O|L|M]|$A|1P|B|1Q|L|M]|$A|1R|B|1S|L|M]]|9|@$A|1T|B|1U|1|1V]]|C|$]]|$1|N|3|O|5|6|7|1W|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1X|8|@]|9|@]|C|$]]|$1|Q|3|R|5|S|7|1Y|8|@$A|1Z|B|20|L|M]]|9|@]|C|$]]|$1|T|3|U|5|S|7|21|8|@$A|22|B|23|L|M]|$A|24|B|25|L|M]]|9|@]|C|$]]|$1|V|3|-4|5|6|7|26|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|27|8|@]|9|@]|C|$]]]|X|$Y|$5|Z|10|11|C|$12|13]]|14|$5|Z|10|11|C|$12|15]]]]

The errors are indeed listed <a href="http://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html" rel="nofollow">here</a>, but IMHO the assumption that "-" means "correctly rounded" (i.e. 1/2 ulp) is almost certainly refuted by the statement at the top of the page

<blockquote>
 [T]he GNU C Library does not aim for correctly rounded results for
 functions in the math library ... Instead, the goals for accuracy of
 functions without fully specified results are as follows; some
 functions have bugs meaning they do not meet these goals in all cases.
 In future, the GNU C Library may provide some other correctly rounding
 functions under the names such as crsin proposed for an extension to
 ISO C.
</blockquote>

After researching the source code a bit, I found what appears to be <a href="https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/fpu/libm-test-ulps;hb=HEAD" rel="nofollow">the results of a ulp test</a> (for x86-64). It looks like, for the default rounding mode (round to nearest, ties go to even), they only explicitly test <code>double</code> when the ulp of <code>long double</code> (80 bit IEEE) is worse than <code>float</code>. The implicit assumption seems to be that <code>double</code> can't be worse than <code>long double</code>. For the directed rounding modes, they seem to always test both <code>float</code> and <code>double</code> explicitly.

There is some weirdness, though.

<ul>
<li>There are no test results listed for <code>exp</code>.</li>
<li>For <code>cos</code> and <code>tan</code>, they only test real/complex <code>long double</code>.</li>
</ul>

I have tried in vain for several days to find the accuracy of Math functions(in math.h) of GNU GCC compiler. C99 standard says that the accuracy requirement of Math functions in math.h is implementation defined. I could not find any mention about this in the GNU GCC compiler manuals.
Does anyone have a answer to this ?

Accuracy requirement of GNU GCC math functions?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我已经尝试了几天，徒劳地寻找GNU GCC编译器的Math函数(在math.h中)的准确性。C99标准指出，math.h中数学函数的精度要求是由实现定义的。我在GNU GCC的编译器手册中找不到任何关于这方面的内容。有人能回答这个问题吗？

问GNU GCC数学函数的精度要求？
EN

回答 3

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GNU GCC数学函数的精度要求？EN

回答 3

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问GNU GCC数学函数的精度要求？
EN