Hacker Newsnew | past | comments | ask | show | jobs | submit | awanderingmind's commentslogin

My personal site where I post essays about various things - generated using hakyll: https://www.awanderingmind.blog/


I found the writing, and the descriptions of the types of trisectors, strangely poignant. Most of us do not attempt to trisect an angle with straightedge and compass; but surely many of us have other irrational obsessions with which we waste our time (I have certainly been guilty of this). I hope people can find time to look up from their interactions with social media and LLMs for enough healthy introspection to avoid these traps.


This is a strange analogy. The policy saves people money on their power bill. The backyward furnaces are considered a disaster because, among other things, they produced low quality steel, and diverted labour from agriculture and other things, none of which is the case here - people pay for solar panels and install them once, and then achieve savings.


There is a lot of focus in the comments on the authors' credentials and, apparently, their writing style. It is a pity, because I think their discussion of scaling is interesting, even if comparing LLMs to grid-based differential equation solvers might be unconventional (I haven't convinced myself whether the analogy is entirely apt/valid yet, but it could conceivably be).


According to the actual paper (https://arxiv.org/pdf/2506.24088), it has been an open conjecture since at least 1977. The quote:

> Unknotting number has long been conjectured to be additive under connected sum; this conjecture is implicit in the work of Wendt, in one of the first systematic studies of unknotting number [37]. It is unclear when and where this was first explicitly stated; most references to it call it an ‘old conjecture’. It can be found in the problem list of Gordon [13] from 1977 and in Kirby’s list [16].

'Additive' here means that if u(K1) is defined as the unknotting number of the knot K1, and u(K1#K2) the unknotting number of the knots K1 and K2 joined together, then u(K1#K2) = u(K1) + u(K2). It is this that has (assuming the paper is correct) been proven false. A deceptively simple property!

edit: I initially incorrectly had a ≤ sign instead of =


> 'Additive' here means that if u(K1) is defined as the unknotting number of the knot K1, and u(K1#K2) the unknotting number of the knots K1 and K2 joined together, then u(K1#K2) ≤ u(K1) + u(K2).

Kinda like the triangle inequality[1] of knots?

I recall the triangle inequality was useful for several cases in Uni, if so I guess I can see it might be a similarity useful inequality in knot theory.

[1]: https://en.wikipedia.org/wiki/Triangle_inequality


I incorrectly had a ≤ instead of =, my apologies.


Ah, no worries. So strictly additive.


Cool example in that link, thanks!


Cool study. I really want to believe the results, but the effect on life extension is so large (see figure 2B) that I find it hard to. Maybe there was some uncontrolled confounding factor? It is noted in the 'Methods' section that 'Researchers were not blinded to group allocation [...]', which is unfortunate.


This perspective is addressed in the article... TLDR; that doesn't seem to be where this is going.


This is a rare type of article - a concrete analysis of different approaches to programming (that are arguably themselves reflections of different cognitive styles), that outlines the shortcomings of one approach in a specific domain, without generalising too much.



Oh wait, I just realized what I said was probably very stupid: I was thinking of some computational complexity theorem that links memory and runtime complexity classes in the same way that the "speed of light" sets an ultimate bound on the relation between actual space and actual time.

But the speed of light is the maximum space in the smallest time, which computationally would correspond to filling the largest amount of memory in the shortest time :facepalm: (and thanks for the links!)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: