anematode

Do you think there is such a thing as perfect security? No one can "get it right" in the face of arbitrarily high intelligence

Why didn't they run the model against the sandbox first? They have effectively unlimited spend.

Disgusting.

Same observation. One thing you can do is close out the session and `claude --resume`

It's a "democracy", in which some people (Anthropic and co., and anyone willing to suck up to them) are more equal than others...

Demis sold out. "Harnessing AI safely" means nothing when your technology is used to help the US government kill and surveil people.

Brilliant! Hadn't seen this technique before.

Sure, but you'd use a low-precision approximation for that; you don't need full double precision

Agreed, correctly rounded libm functions are great, as long as they don't have miserable worse case behavior (as was famously the case with glibc's pow at one point).

One thing I was thinking of doing is manually SLP-vectorizing the high-precision fallbacks that they use when they're close to a rounding boundary, so that you can get better worst-case behavior – but obviously it's good enough already for most purposes.

I'm honestly surprised though that JS engines don't just keep using fdlibm though. The ECMAScript spec explicitly encourages it iirc. And if Math.tanh is on your hot path in JavaScript then you're doing something quite bizarre...

As someone who has no dog in this race (er, well, I'd like to see both companies crumble!), I think this is a natural response to Anthropic's paternalism, which has always been there but has lately been much more apparent.

Exactly!

You can continue to enjoy the books and articles etc

Except for the books that Anthropic bought and destroyed?

There's also the cultural displacement element: while yes, some people (including me) would seek out original content, AI slop is drowning it out. This is decreasing my and others' enjoyment.

They're stealing, eh?

Greediest, perhaps?

There are indeed scrapers which use tens of thousands of distinct IPs, and so rate limiting them isn't a solution.

Should be `dogs[0].bark()`

It also contextualizes the urgency of their attempts at regulatory capture. Once Chinese models have the same capabilities, there's almost no reason not to use them.

It's fantastic to publish these. Otherwise Anthropic's commitment to "AI safety" is Emperor Dario's new clothes, its failure unacknowledged.

An easy alternative is to switch to a Chinese open-weights model, adjust your workflows for its different capabilities, and carry on.

I know (via probing these models) that some of my work is in the training data. My mailbox is open.

Yup, it's hard to take seriously any complaint about "stealing" Anthropic's services, when their entire business is based on massive theft.

It's obviously an error, but I'm going to assume you are larping and move on

What?

The honest answer:

Utter dysfunction. I ripped out bun from my projects after the vibe Rust rewrite, but seems like the problem has existed much longer...

Why the snark? wasmtime is a (pretty popular) Rust project which uses a JIT, demonstrating that it's not incompatible with Rust. Obviously a proper VM wouldn't depend on wasmtime, but implement its own JIT and paraphernalia.

wasmtime exists

I'd actually love to see a relatively high-performance (i.e., including a decent JIT) runtime for a dynamic language that's written in Rust. There's a lot of implementations like Rust Python, the Boa JS engine, etc. that are purely interpreted – and fun! – but I haven't seen a proper, high-performance VM yet.

I considered writing such a JVM in Rust, following writing one in C (https://github.com/anematode/b-jvm) that could JIT WebAssembly code and run in the browser, but decided it would be too time-consuming.

Obviously such a VM would involve a lot of unsafe, but I'm wondering if you could establish some proper, compile-time-checked invariants that make things a lot safer, without the complicated sandboxing that modern JS runtimes use to make it harder for JIT bugs to escalate into full blown RCE.

Thanks, fixed

This is terrifying. Evidently based on prior art by Mr. Pizlo – indeed, where's the acknowledgement of that?? (edit: I missed it) – but I'm assuming that was never translated into code.

I love the idea of experimentation and innovation; I abhor the idea of it being dependent on Anthropic and their theft. I've never rooted for the Chinese labs more strongly than after seeing this.

Thanks for the link, a good read

One thing that stuck out to me is that deals with a lot more data formats, in particular, low-precision formats like FP4, FP6 and FP8. Manipulating those formats can take a lot of annoying effort; in general, x86 (until AVX-512, at least) has unconvincing support for so-called "lane-crossing" instructions that move data across 16-byte boundaries within a vector. So you can imagine unpacking, e.g., tightly packed 7-bit data to 8-bit data is a real slog.

I can already immediately think of a use case for vunpackb in some of the stuff I'm working on, where we'd like to efficiently unpack weights from the high half of a vector.

Separately, adding all signed–unsigned variants of the VNNI dot product instructions is a welcome (albeit niche) change. There was an annoying divergence here between major ISAs: x86 added vpdpbusd which computed a dot product between u8 and i8, while ARM added vdotq, which computes a dot product either between u8 and u8 elements, or i8 and i8. So for broad compatibility, you generally had to restrict one of your inputs to [0,127]. This difference shows in the design of (for example) WASM relaxed SIMD, where the result of wasm.dot.i8x16.i7x16.add.signed is implementation-defined if you exceed the [0,127] range. ARM later added mixed-sign variants, and now x86 consummates it.