https://tinypharma.bio/jobs/

AI+pharma startup, and each person owns a program, from concept to clinic. (Further details omitted, still in stealth.) We hire anyone exceptional in AIxBio, we don't look to fill defined roles.

Founding team (including me! https://kidger.site) are ex-{Cradle, Google, Oxford, ETH}, backgrounds in protein language models, antibody design, JAX scientific ecosystem, neural differential equations.

"RenTech of pharma"!

:)

Yeah it's totally true you can't build a one-size-fits-all foundation model, the data just isn't there. But also... no-one needs that. It's totally fine to tweak a foundation model for any individual problem, and that's the bulk of what is being described in the linked blog post / in the underlying paper.

FWIW whilst at Cradle we had a lot of doubts going into this. Like, thermostability is clearly evolutionarily correlated so it was always pretty likely that by hook or by crook the models could do that correctly. But, binding? Aggregation? Not at all clear that the same principles should hold. And the exciting finding was that yes, yes they do.

I used to work for Cradle and writing this paper was the last thing I did before leaving – on good terms – to found my own startup. :D And we'll 100% be using Cradle for our lead optimization.

(On the off-chance: I'm at PEGS Boston this week chatting all things AI+antibodies, in particular for rare diseases. If this topic is of interest to any other protein+tech geeks here then send me an email, let's grab coffee.)

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