"What Elon Musk think or at least pretend to think" is indeed an useful/interesting piece of information, and I don’t see why a commentary on it is necessary or particularly useful ?
I mean, I can do the "critical reading of CEO claim" part myself, thank you very much.
And it’s not just CEOs. Politicians, spokepersons of foreign nations, academics, journalists also do that "X said a thing" thing. It’s perfectly fine. I don’t need or desire the personal take of the journalist on that declaration. They have opinion pieces for that.
You’re just doing brute force, but with extra steps. It turns out that partial collisions are more common than you think, and it’s not particularly hard to find some.
Here, a 186-bits partial collision, found in less than two minutes on my CPU, by brute force :
Operational concerns trumps raw performances most of the time. Stored procedures live in a different CI/CD environment, with a different testing framework (if there’s even one), on a different deployment lifecycle, using a different language than my main code. It is also essentially an un-pinnable dependency. Too much pain for the gain.
Now, give me ephemeral, per-connection procedures (call them unstored procedures for fun) that I can write in the language I want but that run on provider side, sure I’ll happily use them.
They failed hard with Claude 4 IMO. I just can't have any feedback other than "What a fascinating insight" followed by a reformulation (and, to be generous, an exploration) of what I said, even when Opus 3 has no trouble finding limitations.
By comparison o3 is brutally honest (I regularly flatly get answers starting with "No, that’s wrong") and it’s awesome.
Mostly males. I’m French and "Claude can be female" is a almost a TIL thing (wikipedia says ~5% of Claudes are women in 2022 — and apparently this 5% is counting Claudia).
Yes. This is partly why this article is crap. k*G is never defined, and is the core operation in ECC (also: the article insist on using an elliptic curve in R, but you need to do it on a finite field, because on a smooth curve you can just use a smooth interpolation to solve the logarithm — and obviously once you go on a finite field the curve no longer looks nice, it’s just a seemingly random cloud of points).
Very roughly speaking, putting the complication of "point at infinity" problem under the rug, a characteristic feature of a EC is that a straight line passing through two points on the curve will pass through a third point on the curve (yes, unless you take a vertical line, point at infinity). So you can define an "addition of points on the curve" : take two points A and B, draw a straight line passing through them, name the third intersection point between the line and the curve C, declare A + B = C (actually there’s a symmetry around the x axis involved for the usual properties of addition to hold, another complication, let's sweep it under the rug too).
(for A = B, take the tangent of the curve at A ; in R you can see that it works because you can take the limit as B goes arbitrarily close to A : that gives you the tangent ; in a finite field that’s less obvious but the algebraic proof is the same)
So k*G is just G + G + ... + G, k times.
If you want more details, your favorite reasoning LLM can do a better job explaining what I’ve swept under the rug.
Remember that input tokens are quadratic with the length of the conversation, since you re-upload the n previous messages to get the (n+1)-nth message. When Claude completes a task in 3-4 shots, that’s cents. When he goes down in a rabbit hole, however…
2200 lines. Half of them unit tests I would probably have been too lazy to write myself even for a "more real" project. Yes, I consider $20 cheap for that, considering:
1. It’s a learning experience
2. Looking at the chat transcripts, many of those dollars are burned for stupid reasons (Claude often fails with the insertLines/replaceLines functions and break files due to miss-by-1 offset) that are probably fixable
3. Remember that Claude started from a really rudimentary base with few tools — the bootstrapping was especially inefficient
Next experiment will be on an existing codebase, but that’s probably for next weekend.
I decided to try seriously the Sonnet 3.7. I started with a simple prompt on claude.ai ("Do you know claude code ? Can you do a simple implementation for me ?"). After minimal tweaking from me, it gave me this : https://gist.github.com/sloonz/3eb7d7582c33e95f2b000a0920016...
After interacting with this tool, I decided it would be nice if the tool could edit itself, so I asked (him ? it ?) to create its next version. It came up with a non-working version of this https://gist.github.com/sloonz/3eb7d7582c33e95f2b000a0920016.... I fixed the bug manually, but it started an interactive loop : I could now describe what I wanted, describe the bugs, and the tool will add the features/fix the bugs itself.
In one day (and $20), I essentially had recreated claude-code. That I could improve just by asking "Please add feature XXX". $2 a feature, with unit tests, on average.
Ironically, you exemplify the standard of discourse that the rationalist spaces of discussion like lesswrong strives to go above, which is what makes them so valuable.
Loaded question (well, affirmation), on a confident sneery tone while using poorly defined terms ("essential humanity") and very poor comprehension of object-level facts of the ground ("Markov chains"). And no sign of even trying to understand the other side, just trying to score rhetoric points on a internet board.
You average grad student in physics is less wrong than Newton in physics (he knows about special relativity for example). It’s not "smugness", of course building on the shoulders of those who comes before means building better than them.
I love chaining because it reduce the number of occurrences of that problem.