<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>The Distribution of Program Sizes and Its Implications: An Eclipse Case Study · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/0905.2288/</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/0905.2288/feed.xml" rel="self" type="application/rss+xml" /><item><title>The Distribution of Program Sizes and Its Implications: An Eclipse Case Study — HN submission</title><link>https://news.ycombinator.com/item?id=621807</link><guid isPermaLink="false">urn:hackerpapers:submission:0905.2288:621807</guid><pubDate>Fri, 22 May 2009 10:03:16 GMT</pubDate><description>&lt;p&gt;Ask HN: Seeking reference or paper on Unit Testing for Large Programs / Codes&lt;/p&gt;&lt;p&gt;One of my interest is finding sparsity in large sets so that it can eventually be detected using compressive sensing. An example of that for instance is bugs in software as shown in this paper: http://arxiv.org/abs/0905.2288 as mentioned in http://www.technologyreview.com/blog/arxiv/23548/ I have seen several times, that in order to catch errors, some folks seem to go through what I have seen defined as unit testing. With programs getting larger and larger, one is obviously looking at a combinatorial process eventually (which would explain why there would be more errors in larger codes, as…&lt;/p&gt;&lt;p&gt;3 points; 0 discussion replies on HN. &lt;a href="https://hackerpaper.kaipfister.de/p/0905.2288/"&gt;Paper and source history&lt;/a&gt;. A submission is not an endorsement.&lt;/p&gt;</description><category>cs.SE</category></item></channel></rss>
