We've got Claude Managed Agents, Claude Agent SDK, Claude API, Claude Code, Claude Platform, Claude Cowork, Claude Enterprise, and plain old 'Claude'. And honourable mention to Claude Haiku/Sonnet/Opus 4.{whatever} as yet another thing with the same prefix. I feel like it's about once a week I see a new announcement here on HN about some new agentic Claude whatever-it-is.

I have pretty much retreated in the face of this to 'just the API + `pi` + Claude Opus 4.{most recent minor release}', as a surface area I can understand.

I learnt a lot the first time around, so the newer one is much better :)

I've not tried a couple of things you mention (e.g. background images) but e.g. for dynamic placing there are libraries like https://typst.app/universe/package/meander

The core of Typst is a pretty featureful well-thought-out FP language. This makes expressing libraries for any piece of functionality very pleasant.

That said, the documentation on this matter is close to nonexistent.

Not sure where I got it from, it just seems clean. I don't think I see this super frequently in the ecosystem at large, although anything I've had a hand in will tend to use this style!

C.f. "the intention here is that only names imported using the form X as X will be exported" from PEP484. [1]

I'm generally a fan of the style of putting all the implementation in private modules (whose names start with an underscore) and then using __init__.py files solely to declare the public API.

[1] https://peps.python.org/pep-0484/

(Though it's really a pretty tiny library that just does what it says on the tin, not sure how many questions there can be. :D )

Comments URL: https://news.ycombinator.com/item?id=44193887

Points: 3

# Comments: 0

Also worth noting the Array API standard exists now. This is generally also trying to straighten out the sharp edges.

Helix:

https://github.com/helix-editor/helix/

Like vim, but already has an LSP etc out of the box. Things are already there so the config files are minimal.

(Doesn't really bother me, my friends and I all use WhatsApp/etc. anyway.)

n=1 though, maybe this is some quirk of my phone provider.

See for example https://www.nature.com/articles/s42256-024-00897-5

Classical solvers are very very good at solving PDEs. In contrast PINNs solve PDEs by... training a neural network. Not once, that can be used again later. But every single time you solve a new PDE!

You can vary this idea to try to fix it, but it's still really hard to make it better than any classical method.

As such the main use cases for PINNs -- they do have them! -- is to solve awkward stuff like high-dimensional PDEs or nonlocal operators or something. Here it's not that the PINNs got any better, it's just that all the classical solvers fall off a cliff.

---

Importantly -- none of the above applies to stuff like neural differential equations or neural closure models. These are genuinely really cool and have wide-ranging applications.! The difference is that PINNs are numerical solvers, whilst NDEs/NCMs are techniques for modelling data.

/rant ;)

Comments URL: https://news.ycombinator.com/item?id=42710816

Points: 2

# Comments: 0

I've tried low-profile chocs and they still have too much travel! But I'm stuck with them as split keyboards are important for me just for the usual collection of wrist health reasons.

So I'm just waiting for Apple to make a split keyboard I guess :)

[1] https://github.com/qutebrowser/qutebrowser

See either beartype [1] or typeguard [2]. And if you're doing any kind of array-based programming (JAX or not), then jaxtyping [3].

[1] https://github.com/beartype/beartype/

[2] https://github.com/agronholm/typeguard

[3] https://github.com/patrick-kidger/jaxtyping

PyTorch has better adoption / network effects. JAX has stronger underlying abstractions.

I use both. I like both :)

So to elucidate this a little bit, the trade-off is that this is now incompatible with e.g. `jax.grad` or `lax.scan`: you can't compose things in the order `discharge_effect(jax.grad(your_model_here))`, or put an effectful `lax.scan` inside your forward pass, etc. The effect-discharging process only knows how to handle traversing pytree structures. (And they do mention this at the end of their docs.)

This kind of thing was actually something I explicitly considered later on in Equinox, but in part decided against as I couldn't see a way to make that work either. The goal of Equinox was always absolute compatibility with arbitrary JAX code.

Now, none of that should be taken as a bash at Penzai! They've made a different set of trade-offs, and if the above incompatibility doesn't affect your goals then indeed their effect system is incredibly elegant, so certainly give it a try. (Seriously, it's been pretty cool to see the release of Penzai, which explicitly acknowledges how much it's inspired by Equinox.)

So it's slightly more framework-y than Equinox and will not be completely compatible with arbitrary JAX code. However I have already had a collaborator demonstrate that as long as you don't use any higher-order operations, then treescope will actually work out-of-the-box with Equinox modules!

So I think the answer to your question is "sort of":

* As long as you only try to inspect things that are happening outside of your `diffrax.diffeqsolve` then you should be good to go. And moreover can probably do this simply by using e.g. Penzai's treescope directly alongside your existing Equinox code, without needing to move things over wholesale.

* But anything inside probably isn't supported + if I understand their setup correctly can never be supported. (Not bashing Penzai there, which I think genuinely looks excellent -- I think it's just fundamentally tricky at a technical level.)

Answering your questions, split into pros and cons:

## Pros

You can customise the layout, including meta keys like control/alt/windows. I think the "more advanced mode" is basically just designing your own layout.

It's honestly very accurate for a keyboard that is basically just tapping your figures against a table. It definitely misreads the odd input (or perhaps more accurately, it is sufficiently easy for me to waggle my fingers wrong), but it doesn't make so many that I'm really bothered by it.

I had an issue with the firmware on mine when I first got it, and the support team were super responsive. I really appreciated this.

The Android/iOS app is well designed for learning how to use it -- it comes with an excellently pedagogical typing tutor.

If you're curious, I'd definitely recommend giving it a go. IIUC the WPM most folks get with it is about equivalent to to other one-handed-keyboards, ~50 or so. I've found learning it to be pretty easy. (Substantially easier than learning a new layout on a regular keyboard, for some reason.)

It connects as a bluetooth keyboard, no special software required.

## Cons

Customising layouts is unfortunately a bit of a chore, being both tied-to-the-company and requiring additional devices. The layout must first be designed through a webpage on their site, which you need to log in to using your account. Then you need an Android/iOS device to actually connect to the TS2 and push the layout.

## Worth knowing

You have essentially five layers: default, double tap, triple tap, shift, and switch. Shift and switch are pretty similar to layers as you'll find them on most ergomech keyboards. However, the double and triple tap layers work by inputting the key corresponding to that chord on the default layer, then detecting that you're doing a double/triple tap, then inputting backspace, and then inputting the key corresponding to the chord on the double/triple tap layer. So if you'd like to use it for something like vim, then that first input might actually mean something! If that will affect you, then in practice you can't use the double/triple tap layers, and you only have 60% of the real estate to fit your custom layout into. That is just enough to fit basically a whole keyboard -- I've got a custom layout that does this -- but it took me some careful thought for how to cram all those keys into such little space in a logical way.