<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The pitfalls of verifying floating-point computations · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/cs_0701192/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/cs_0701192/feed.xml" rel="self" type="application/rss+xml" /><item><title>The pitfalls of verifying floating-point computations — mentioned by pascal_cuoq</title><link>https://news.ycombinator.com/item?id=7479681</link><guid isPermaLink="false">urn:hackerpapers:mention:cs_0701192:7479681</guid><pubDate>Thu, 27 Mar 2014 11:30:41 GMT</pubDate><description>&lt;p&gt;In the case of C compilers, they get floating-point right by re-defining what the language definition means: http://arxiv.org/abs/cs/0701192 There has been some progress since the time this report was an accurate description of the situation, but the situation is still mostly terrible: http://stackoverflow.com/questions/17663780/is-there-a-docum... And soon, fused-multiply-add will be common enough that compilers will start generating by default the instruction for code that contains addiction and multiplications, causing a regression with respect to the current situation.&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/cs_0701192/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.PL</category></item></channel></rss>
