<story><title>Boosting zopfli performance</title><url>http://roartindon.blogspot.com/2016/04/boosting-zopfli-performance.html</url></story><parent_chain></parent_chain><comment><author>lifthrasiir</author><text>&amp;gt; Now that I have a 32-bit floating point representation to compare to, I can go one step further: Since mincostaddcostj is always greater than or equal to 0, and because non-negative floats are monotonically ascending when the bits are interpreted as an integer, I can use an &lt;i&gt;integer comparison&lt;/i&gt; to do the check!&lt;p&gt;Good points. It exactly sounds like that we can benefit from specialized &amp;quot;non-negative&amp;quot; or &amp;quot;non-NaN&amp;quot; types, either implemented in the library (with a limited operator overloading) or in the compiler level (via static range analyses).</text></comment>
<story><title>Boosting zopfli performance</title><url>http://roartindon.blogspot.com/2016/04/boosting-zopfli-performance.html</url></story><parent_chain></parent_chain><comment><author>hannob</author><text>Very interesting, unfortunately he doesn&amp;#x27;t say if he has submitted these improvements to the upstream developers so that other users of zopfli will benefit from them.</text></comment>