Thread

Loading the complete thread in the background. This saved snapshot is available now. Refresh

1. DreamOfXM · 1790223247 · focus · HN ↗

   [dead]

2. gleenn · 1790223915 · focus · HN ↗

   This seems extremely cool, but man does it also sound complicated. The write up was thorough but the algorithm seems so complicated that the author can't even write good tests for it is concerning. I would be very concerned their algorithm might accidentally skip something important accidentally given they are dealing with dynamically combining large binary expressions. You can make it fast, but if you can't prove it and it's security related that probably needs to be proved out more, even if SHA1 is already compromised.

   1. bawolff · 1790231573 · focus · HN ↗

      Why do you conclude the author cannot write good tests for it?

      1. gleenn · 1790798701 · focus · HN ↗

         They stated they had trouble.
   2. ted_dunning · 1790236799 · focus · HN ↗

      Fuzz tests with tailored random distributions and good logical property tests are excellent tests.

      What would you do better?

      Also, the author didn't say that there were no other tests. They just said that they use fuzz + property tests a fair bit.

3. someonebaggy · 1790228278 · focus · HN ↗

   This writing almost feels AI, but it's not AI. Why is that?

   1. bawolff · 1790231321 · focus · HN ↗

      This reads like a totally normal article to me. At some point these AI accusations feel like a witch hunt.

      1. entrope · 1790240417 · focus · HN ↗

         I thought it was a really good, clear write-up of a very nice engineering discovery and optimization. If anything, I think an LLM would generate native superscript for the `2^(-r)` expression, so I didn't have an impression of LLM authorship.

         Maybe an LLM did the search for what expressions to put in the blocks vs tail of the vectorized collision detection, but that seems like a good place to use an LLM as long as all of the expected bit relations are verified as checked properly.

         1. srijs · 1790242576 · focus · HN ↗

            Hi, author here.

            What goes into head vs. tail is actually fully deterministically decided by the solver based on a P(tail) gradient, so expressions that are more effective in filtering out blocks before they can hit the (slower) tail are preferred in the prefix.

      2. Obscurity4340 · 1790259442 · focus · HN ↗

         Its seriously such a cheap, easy, and lazy accusation to make by just accusing it of being slop, I actualky hate the slop-accusing more then any slop. Any bot can just randomly say slop and in at least someones eyes a whole writeup will have been discredited thru tho fault of the author.

         It needs to stop, if people have a factual or actual valid criticism of the facts or claims then by all means, go to town. But Im done with the slop screamers, its a downvote and scorn all the way down for those

         1. cindyllm · 1790263602 · focus · HN ↗

            [dead]

4. rurban · 1790229137 · focus · HN ↗

   Does git proper already accepts rust? 2x faster pack checks would be worthwhile, as it affects everybody

   1. masklinn · 1790232751 · focus · HN ↗

      Git proper has had rust code in it since 2025 or thereabouts, but as an optional dependency. There are plans to make it required in git 3.

Unofficial Hacker News client; not affiliated with Y Combinator.