<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: shawntan</title><link>https://news.ycombinator.com/user?id=shawntan</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 04 May 2026 17:26:19 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=shawntan" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>The question I keep coming back to is whether ARC-AGI is intended to evaluate generalisation to the task at hand. This would then mean that the test data has a meaningful distribution shift from the training data, and only a model that can perform said generalisation can do well.<p>This would all go out the window if the model being evaluated can _see_ the type of distribution shift it would encounter during test time. And it's unclear whether the shift is the same in the hidden set.<p>There are questions about the evaluations that arise from the large model performance against the smaller models, especially given the ablation studies.
Are the large models trained on the same data as these tiny models? Should they be? If they shouldn't, then why are we allowing these small models access to these in their training data?</p>
]]></description><pubDate>Tue, 14 Oct 2025 02:06:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=45575496</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45575496</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45575496</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>This would not help if no proper constraints are established on what data can and cannot be trained on. And maybe just figuring out what the goal of the benchmark is.<p>If it is to test generalisation capability, then what data the model being evaluated is trained on is crucial to making any conclusions.<p>Look at the construction of this synthetic dataset for example: <a href="https://arxiv.org/pdf/1711.00350" rel="nofollow">https://arxiv.org/pdf/1711.00350</a></p>
]]></description><pubDate>Tue, 14 Oct 2025 02:00:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=45575458</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45575458</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45575458</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>You can have benchmarks with specifically constructed train-test splits for task-specific models. Train only on the train,  then your results on test should be what is reported.<p>You can still game those benchmarks (tune your hyperparameters after looking at test results), but that setting measures for generalisation on the test set _given_ the training set specified. Using any additional data should be going against the benchmark rules, and should not be compared on the same lines.</p>
]]></description><pubDate>Tue, 14 Oct 2025 01:55:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=45575425</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45575425</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45575425</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>This is a point I wish more people would recognise.</p>
]]></description><pubDate>Thu, 09 Oct 2025 17:50:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=45530855</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45530855</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45530855</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>I should probably also add: It's long been known that Universal / Recursive Transformers are able to solve _simple_ synthetic tasks that vanilla transformers cannot.<p>Just check out the original UT paper, or some of it's follow ups: Neural Data Router, <a href="https://arxiv.org/abs/2110.07732" rel="nofollow">https://arxiv.org/abs/2110.07732</a>; Sparse Universal Transformers (SUT), <a href="https://arxiv.org/abs/2310.07096" rel="nofollow">https://arxiv.org/abs/2310.07096</a>.<p>There is even theoretical justification for why: <a href="https://arxiv.org/abs/2503.03961" rel="nofollow">https://arxiv.org/abs/2503.03961</a><p>The challenge is actually scaling them up to be useful as LLMs as well (I describe why it's a challenge in the SUT paper).<p>It's hard to say with the way ARC-AGI is allowed to be evaluated if this is actually what is at play. My gut tells me, given the type of data that's been allowed in the training set, that some leakage of the evaluation has happened in both HRM and TRM.<p>But because as a field we've given up on actually carefully ensuring training and test don't contaminate, we just decide it's fine and the effect is minimal. Especially considering LLMs, the test set example leaking into the dataset is merely a drop in the bucket (I don't believe we should be dismissing it this way, but that's a whole 'nother conversation).<p>With these models that are challenge-targeted, it becomes a much larger proportion of what influences the model behaviour, especially if the open evaluation sets are there for everyone to look at and simply generate more.  Now we don't know if we're generalising or memorising.</p>
]]></description><pubDate>Wed, 08 Oct 2025 04:23:47 +0000</pubDate><link>https://news.ycombinator.com/item?id=45512041</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45512041</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45512041</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>> Do you mean that HRM and TRM are specifically trained on a small dataset of ARC-AGI samples, while LLMs are not? Or which difference exactly do hint at?<p>Yes, precisely this. The question is really what is ARC-AGI evaluating for?<p>1. If the goal is to see if models can generalise to the ARC-AGI evals, then models being evaluated on it should not be trained on the tasks. Especially IF ARC-AGI evaluations are constructed to be OOD from the ARC-AGI training data. I don't know if they are. Further, there seems to be usage of the few-shot examples in the evals to construct more training data in the HRM case. TRM may do this via the training data via other means.<p>2. If the goal is that even _having seen_ the training examples, and creating more training examples (after having peeked at the test set), these evaluations should still be difficult, then the ablations show that you can get pretty far without universal/recurrent Transformers.<p>If 1, then I think the ARC-prize organisers should have better rules laid out for the challenge. From the blog post, I do wonder how far people will push the boundary (how much can I look at the test data to 'augment' my training data?) before the organisers say "This is explicitly not allowed for this challenge."<p>If 2, the organisers of the challenge should have evaluated how much of a challenge it would actually have been allowing extreme 'data augmentation', and maybe realised it wasn't that much of a challenge to begin with.<p>I tend to agree that, given the outcome of both the HRM and this paper, is that the ARC-AGI folks do seem to allow this setting, _and_ that the task isn't as "AGI complete" as it sets out to be.</p>
]]></description><pubDate>Wed, 08 Oct 2025 03:44:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=45511840</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45511840</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45511840</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>Right. There should really be a vanilla Transformer baseline.<p>With recurrence: The idea has been around: <a href="https://arxiv.org/abs/1807.03819" rel="nofollow">https://arxiv.org/abs/1807.03819</a><p>There are reasons why it hasn't really been picked up at scale, and the method tends to do well on synthetic tasks.</p>
]]></description><pubDate>Tue, 07 Oct 2025 20:08:31 +0000</pubDate><link>https://news.ycombinator.com/item?id=45508175</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45508175</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45508175</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>That analysis provided a very non-abrasive wording of their evaluation of HRM and its contributions. The comparison with a recursive / universal transformer on the same settings is telling.<p>"These results suggest that the performance on ARC-AGI is not an effect of the HRM architecture. While it does provide a small benefit, a replacement baseline transformer in the HRM training pipeline achieves comparable performance."</p>
]]></description><pubDate>Tue, 07 Oct 2025 20:00:01 +0000</pubDate><link>https://news.ycombinator.com/item?id=45508077</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45508077</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45508077</guid></item><item><title><![CDATA[New comment by shawntan in "Less is more: Recursive reasoning with tiny networks"]]></title><description><![CDATA[
<p>I think everyone should read the post from ARC-AGI organisers about HRM carefully: <a href="https://arcprize.org/blog/hrm-analysis" rel="nofollow">https://arcprize.org/blog/hrm-analysis</a><p>With the same data augmentation / 'test time training' setting, the vanilla Transformers do pretty well, close to the "breakthrough" HRM reported. From a brief skim, this paper is using similar settings to compare itself on ARC-AGI.<p>I too, want to believe in smaller models with excellent reasoning performance. But first understand what ARC-AGI tests for, what the general setting is -- the one that commercial LLMs use to compare against each other -- and what the specialised setting HRM and this paper uses as evaluation.<p>The naming of that benchmark lends itself to hype, as we've seen in both HRM and this paper.</p>
]]></description><pubDate>Tue, 07 Oct 2025 19:51:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=45507970</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45507970</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45507970</guid></item><item><title><![CDATA[New comment by shawntan in "LLM-Deflate: Extracting LLMs into Datasets"]]></title><description><![CDATA[
<p>Not sure if you mean in general, but I'll answer both branches of the question.<p>In general:
Depending on the method of compression, you can have lossy or non-lossy compression. Using 7zip on a bunch of text files can lossless-ly compress that data. Briefly, you calculate the statistics of the data you want to compress (the dictionary), and then make the commonly re-occuring chunks describable with fewer bits (encoding). The compressed file basically contains the dictionary and the encoding.<p>For LLMs:
There are ways to use an LLM (or any statistical model of text) to compress text data. But the techniques use similar settings as the above, with a dictionary and an encoding, with the LLM taking the function of a dictionary. When "extracting" data from the dictionary alone, you're basically sampling from the dictionary distribution.<p>Quantitatively, the "loss" in "lossy" being described is literally the number of bits used for the encoding.<p>I wrote a brief description here of techniques from an undergrad CS course that can be used: <a href="https://blog.wtf.sg/posts/2023-06-05-yes-its-just-doing-compression.-no-its-not-the-diss-you-think-it-is./" rel="nofollow">https://blog.wtf.sg/posts/2023-06-05-yes-its-just-doing-comp...</a></p>
]]></description><pubDate>Sat, 20 Sep 2025 17:00:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=45315073</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45315073</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45315073</guid></item><item><title><![CDATA[New comment by shawntan in "LLM-Deflate: Extracting LLMs into Datasets"]]></title><description><![CDATA[
<p>The compression is lossy.</p>
]]></description><pubDate>Sat, 20 Sep 2025 16:50:05 +0000</pubDate><link>https://news.ycombinator.com/item?id=45314969</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=45314969</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45314969</guid></item><item><title><![CDATA[New comment by shawntan in "Launch HN: Channel3 (YC S25) – A database of every product on the internet"]]></title><description><![CDATA[
<p>Sup!</p>
]]></description><pubDate>Thu, 21 Aug 2025 13:02:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=44972249</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=44972249</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44972249</guid></item><item><title><![CDATA[New comment by shawntan in "Launch HN: Channel3 (YC S25) – A database of every product on the internet"]]></title><description><![CDATA[
<p>2nd employee at Semantics3 here. Considering all the AI available today I think things like product disambiguation becomes wayyy easier. We were trying many tricks and heuristics to identify the same products across sites.</p>
]]></description><pubDate>Thu, 21 Aug 2025 03:06:40 +0000</pubDate><link>https://news.ycombinator.com/item?id=44968668</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=44968668</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44968668</guid></item><item><title><![CDATA[New comment by shawntan in "Compiling LLMs into a MegaKernel: A path to low-latency inference"]]></title><description><![CDATA[
<p>Systems might want to anticipate changes in LLM architectures (even small changes can make a big difference kernel wise), so it's good to not "bake" too much in ahead of time.<p>That said, at some point it just depends where the costs lie and it might make sense hiring some GPU engineers to do what they did here for whatever architecture you're optimising for.<p>Not as low-hanging as you might imagine.</p>
]]></description><pubDate>Thu, 19 Jun 2025 20:48:38 +0000</pubDate><link>https://news.ycombinator.com/item?id=44322413</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=44322413</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44322413</guid></item><item><title><![CDATA[New comment by shawntan in "Gemini Diffusion"]]></title><description><![CDATA[
<p>I'm curious how the speed is achieved is this is the technique used. Generally I expected this "masked language model" technique to be far slower since the full vocab projection needs to be computed every iteration.<p>I always thought the eventual technique would be some form of diffusion in continuous space, then decoding into the discrete tokens.<p>Also I'm guessing this is  a "best guess" of how Gemini Diffusion is done?</p>
]]></description><pubDate>Thu, 22 May 2025 17:08:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=44064148</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=44064148</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=44064148</guid></item><item><title><![CDATA[New comment by shawntan in "RWKV Language Model"]]></title><description><![CDATA[
<p>The formulations in attention as rnn have similar issues as rwkv. Fundamentally it's a question of what we call an RNN.<p>Personally I think it's important not to call some of these recent architectures RNNs because they have theoretical properties that do not match (read: they're worse) what we've "classically" called RNNs.<p>Ref: <a href="https://arxiv.org/abs/2404.08819" rel="nofollow">https://arxiv.org/abs/2404.08819</a><p>As a rule of thumb: you generally don't get parallelism for free, you pay for it with poorer expressivity.</p>
]]></description><pubDate>Thu, 02 Jan 2025 19:04:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=42577558</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=42577558</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42577558</guid></item><item><title><![CDATA[New comment by shawntan in "RWKV Language Model"]]></title><description><![CDATA[
<p>Although marketed as such, RWKV isn't really an RNN.<p>In the recent RWKV7 incarnation, you could argue it's a type of Linear RNN, but past versions had an issue of taking its previous state from a lower layer, allowing for parallelism, but makes it closer to a convolution than a recurrent computation.<p>As for 1), I'd like to believe so, but it's hard to get people away from the addictive drug that is the easily parallelised transformer, 2) (actual) RNNs  and attention mechanisms to me seem fairly powerful (expressivity wise) and perhaps most acceptable by the community.</p>
]]></description><pubDate>Thu, 02 Jan 2025 14:55:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=42574924</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=42574924</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=42574924</guid></item><item><title><![CDATA[New comment by shawntan in "Chain of Thought empowers transformers to solve inherently serial problems"]]></title><description><![CDATA[
<p>> The actual result of the paper is that any poly-time computable function can be computed with poly-many tokens.<p>You're right.<p>Re: NAND of two inputs. Isn't this doable even by a single layer (no hidden layers) neural network?<p>Re: Polynomial computable function. I'm assuming this makes no assumption of constant-depth.<p>Because my entire point was that the result of this paper is not actually impressive AND covered by a previous paper. Hopefully that's clearer.</p>
]]></description><pubDate>Tue, 17 Sep 2024 03:43:57 +0000</pubDate><link>https://news.ycombinator.com/item?id=41563892</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=41563892</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41563892</guid></item><item><title><![CDATA[New comment by shawntan in "Chain of Thought empowers transformers to solve inherently serial problems"]]></title><description><![CDATA[
<p>If a "problem we care about" is not stated as a formal language, does it mean it does not exist in the hierarchy of formal languages? Or is it just as yet unclassified?</p>
]]></description><pubDate>Tue, 17 Sep 2024 02:44:34 +0000</pubDate><link>https://news.ycombinator.com/item?id=41563527</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=41563527</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41563527</guid></item><item><title><![CDATA[New comment by shawntan in "Chain of Thought empowers transformers to solve inherently serial problems"]]></title><description><![CDATA[
<p>Using CoT implicitly increases the depth of the circuit. But yes, poorly worded.</p>
]]></description><pubDate>Tue, 17 Sep 2024 02:35:46 +0000</pubDate><link>https://news.ycombinator.com/item?id=41563474</link><dc:creator>shawntan</dc:creator><comments>https://news.ycombinator.com/item?id=41563474</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=41563474</guid></item></channel></rss>