TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Elementary Functions and Not Following IEEE754 Floating-Point Standard (2020)

60 点作者 dreamer_soul3 个月前

6 条评论

jcranmer3 个月前
It&#x27;s worth noting that the C standard explicitly disclaims correct rounding for these IEEE 754 functions (C23§F.3¶20).<p>Also, there&#x27;s a group of people who have been running tests on common libms, reporting their current accuracy states here: <a href="https:&#x2F;&#x2F;members.loria.fr&#x2F;PZimmermann&#x2F;papers&#x2F;accuracy.pdf" rel="nofollow">https:&#x2F;&#x2F;members.loria.fr&#x2F;PZimmermann&#x2F;papers&#x2F;accuracy.pdf</a> (that paper is updated ~monthly).
评论 #43011440 未加载
评论 #43010448 未加载
lifthrasiir3 个月前
&gt; All the standard Maths libraries which claim to be IEEE complaint I have tested are not compliant with this constraint.<p>It is possible to read the standard in the way that they still remain compliant. The standard, as of IEEE 754-2019, does not require recommended operations to be implemented <i>in accordance to</i> the standard in my understanding; implementations are merely recommended to (&quot;should&quot;) define recommended operations with the required (&quot;shall&quot;) semantics. So if an implementation doesn&#x27;t claim that given recommended operation is indeed compliant, the implementation remains complaint in my understanding.<p>One reason for which I think this might be the case is that not all recommended operations have a known correctly rounded algorithm, in particular bivariate functions like pow (in fact, pow is the only remaining one at the moment IIRC). Otherwise no implementations would ever be complaint as long as those operations are defined!
评论 #43013166 未加载
adgjlsfhk13 个月前
It&#x27;s really hard for me to think that this is a good solution. Normal users should be using Float64 (where there is no similar solution), and Float32 should only be used when Float64 computation is too expensive (e.g. GPUs). In such cases, it&#x27;s hard to believe that doing the math in Float64 and converting will make anyone happy.
评论 #43011892 未加载
评论 #43010215 未加载
评论 #43009753 未加载
dzaima3 个月前
For 32-bit float single-operand ops it&#x27;s simple enough to rely on a brute-force check. For 64-bit floats, though, while the goal of &quot;sin(x) in library A really should match sin(x) in library B&quot; is nice, it essentially ends up as &quot;sin(x) in library A really should match... ...well, there&#x27;s no option other than library A if I want sin(x) to not take multiple microseconds of bigint logic&quot;.<p>Though, a potentially-useful note is that for two-argument functions is that a correctly-rounded implementation means that it&#x27;s possible to specialize certain constant operands to a much better implementations while preserving the same result (log(2,x), log(10,x), pow(x, 0.5), pow(x, 2), pow(x, 3), etc; floor(log(int,x)) being potentially especially useful if an int log isn&#x27;t available).
vogu663 个月前
Would working with unums side-step the issue for math problems?
评论 #43012583 未加载
stncls3 个月前
Floating-point is hard, and standards seem like they cater to lawyers rather than devs. But a few things are slightly misleading in the post.<p>1. It correctly quotes the IEEE754-2008 standard:<p>&gt; A conforming function shall return results correctly rounded for the applicable rounding direction for all operands in its domain<p>and even points out that the citation is from &quot;Section 9. *Recommended* operations&quot; (emphasis mine). But then it goes on to describes this as a &quot;*requirement*&quot; of the standard (it is not). This is not just a mistype, the post actually implies that implementations not following this recommendation are wrong:<p>&gt; [...] none of the major mathematical libraries that are used throughout computing are actually rounding correctly as demanded in any version of IEEE 754 after the original 1985 release.<p>or:<p>&gt; [...] ranging from benign disregard for the standard to placing the burden of correctness on the user who should know that the functions are wrong: “It is following the specification people believe it’s following.”<p>As far as I know, IEEE754 mandates correct rounding for elementary operations and sqrt(), and only for those.<p>2. All the mentions of 1 ULP in the beginning are a red herring. As the article itself mentions later, the standard never cares about 1 ULP. Some people do care about 1 ULP, just because it is something that can be achieved at a reasonable cost for transcendentals, so why not do it. But not the standard.<p>3. The author seems to believe that 0.5 ULP would be better than 1 ULP for numerical accuracy reasons:<p>&gt; I was resounding told that the absolute error in the numbers are too small to be a problem. Frankly, I did not believe this.<p>I would personally also tell that to the author. But there is a much more important reason why correct rounding would be a tremendous advantage: reproducibility. There is always only one correct rounding. As a consequence, with correct rounding, different implementations return bit-for-bit identical results. The author even mentions falling victim to FP non-reproducibility in another part of the article.<p>4. This last point is excusable because the article is from 2020, but &quot;solving&quot; the fp32 incorrect-rounding problem by using fp64 is naive (not guaranteed to always work, although it will with high probability) and inefficient. It also does not say what to do for fp64. We can do correct rounding <i>much</i> faster now [1, 2]. So much faster that it is getting really close to non-correctly-rounded, so some libm may one day decide to switch to that.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;rutgers-apl&#x2F;rlibm">https:&#x2F;&#x2F;github.com&#x2F;rutgers-apl&#x2F;rlibm</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;taschini&#x2F;crlibm">https:&#x2F;&#x2F;github.com&#x2F;taschini&#x2F;crlibm</a>
评论 #43010702 未加载
评论 #43011909 未加载