<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Conic Optimization Theory: Convexification Techniques and Numerical Algorithms · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1709.08841/</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/1709.08841/feed.xml" rel="self" type="application/rss+xml" /><item><title>Conic Optimization Theory: Convexification Techniques and Numerical Algorithms — mentioned by kragen</title><link>https://news.ycombinator.com/item?id=28179010</link><guid isPermaLink="false">urn:hackerpapers:mention:1709.08841:28179010</guid><pubDate>Sat, 14 Aug 2021 08:19:16 GMT</pubDate><description>&lt;p&gt;I&amp;#x27;m so ignorant about modern graphics programming that I don&amp;#x27;t know what backing layers are or why they should be tiled. Googling doesn&amp;#x27;t help. Maybe they&amp;#x27;re offscreen pixel buffers you draw into? I guess VBOs are vertex buffer objects? How can a web developer create a rasterized document fragment at all, much less one ten thousand pixels high? Do you mean, like, creating a huge offscreen &amp;lt;canvas&amp;gt; and drawing stuff on it? (But in that case how would CSS layout be involved at all?) I think TeX typically takes in the ballpark of ten million machine instructions per page of text (say, 256-1024…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1709.08841/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>math.OC</category></item><item><title>Conic Optimization Theory: Convexification Techniques and Numerical Algorithms — mentioned by kragen</title><link>https://news.ycombinator.com/item?id=28174070</link><guid isPermaLink="false">urn:hackerpapers:mention:1709.08841:28174070</guid><pubDate>Fri, 13 Aug 2021 20:27:37 GMT</pubDate><description>&lt;p&gt;Which same thing do you mean? I read your very interesting longer comment below, and you mentioned a lot of differences, and it&amp;#x27;s not clear which of them you mean arbitrary UI element sizes with scrollable overflow requires you to do. Do you mean that it requires you to use very slow layout algorithms? Maybe the problem there is that CSS wasn&amp;#x27;t designed to be efficiently implementable; I feel like CSS doesn&amp;#x27;t usually give me better layouts than LaTeX, which runs orders of magnitude faster than any CSS engine. Is there a specific reason that scrollable overflow (rather than visible or hidden…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1709.08841/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>math.OC</category></item></channel></rss>
