HN user
I'd love to have a way to make xlsx files be git-compatible, i.e. stored in plaintext.
I realise this may be out-of-scope as it's kind of baked into the file format, but does Nobie offer any functionality in that direction?
The Tiny Pharma Company | Founding Scientist | London/Zurich
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"!
:)
I'll offer a +1 to the sibling comment here.
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.
Oh hello Thomas, fancy seeing you here :D ex-Cradlers unite!
Oh heck, this is awesome to see on the front page! I wrote the underlying Cradle-1 paper that is being discussed!
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.)
I'm not sure if I'm about to be the old man yelling at clouds, but Anthropic seem to be 'AWS-ifying'. An increasing suite of products which (at least to me) seem to undifferentiated amongst themselves, and all drawn from the same roulette wheel of words.
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.
Quick heads-up that these days I recommend https://github.com/patrick-kidger/jaxtyping over the older repository you've linked there.
I learnt a lot the first time around, so the newer one is much better :)
I think so!
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.
It also applies to any .py file. (At least in practice with e.g. pyright)
That said, the documentation on this matter is close to nonexistent.
Yup, you(/sibling comments) have it correct, it's to mark it as private.
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!
This is how static type checkers are told that an imported object is part of the public API for that file. (In addition to anything else present in that file.)
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.
Oh neat! This is my library. Happy to answer any questions.
(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 )
Went scrolling looking for this! Most of the article is about problems solved in JAX.
Also worth noting the Array API standard exists now. This is generally also trying to straighten out the sharp edges.
What open source alternatives?
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.
I have a US number and live in Switzerland. At least for me, I only receive SMS messages whenever I visit the US -- the rest of the time they're just dropped and I'll never see them.
(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.
FWIW - I used to do research in this area - PINNs are a terribly overhyped idea.
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 ;)
Likewise, spending another comment just to agree. Both on the low profile and the low travel distance.
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 :)
So why this over qutebrowser [1] ? (Which has been my go-to keyboard-first browser for a long time.) This isn't mentioned in the FAQ despite I think being the natural comparison.
You want runtime typechecking.
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/
I think a lot of the commenters here are being rather unfair.
PyTorch has better adoption / network effects. JAX has stronger underlying abstractions.
I use both. I like both :)
I was just reading this too! I think it's a really interesting choice in the design space.
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.)
IIUC then penzai is (deliberately) sacrificing support for higher-order operations like `lax.{while_loop, scan, cond}` or `diffrax.diffeqsolve`, in return for some of the other new features it is trying out (treescope, effects).
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.)
I have a Tap Strap 2. (Although only as of a couple of weeks ago, so still pretty new to it.)
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.
I wrote a JAX-based neural network library (Equinox [1]) and numerical differential equation solving library (Diffrax [2]).
At the time I was just exploring some new research ideas in numerics -- and frankly, procrastinating from writing up my PhD thesis!
But then one of the teams at Google starting using them, so they offered me a job to keep developing them for their needs. Plus I'd get to work in biotech, which was a big interest of mine. This was a clear dream job offer, so I accepted.
Since then both have grown steadily in popularity (~2.6k GitHub stars) and now see pretty widespread use! I've since started writing several other JAX libraries and we've turned this into a bit of a foundation for a JAX sciML ecosystem.
I'd like to say that I really enjoyed watching this project happen!
In particular I think this goes a long way towards rounding out the JAX scientific computing ecosystem. I'd be very curious what other sciComp/sciML folks here think.
Ah right! Actually it's a good point, the Equinox readme/etc do tend to emphasise the ML use cases -- partly this is deliberate (go where the money is)! But I should probably tweak it to emphasise more general parameterised models.
if that SciComp uses machine learning, I guess?
Not necessarily! It's perfectly possible (and quite common) to e.g. write down a traditional parameterised ODE, and then optimise its parameters via gradient descent. Compute the gradients wrt parameters using autodiff through the numerical ODE solver. All without a single neural network in sight! ;)
My usual spiel is that autodiff+autoparallel are really useful for any kind of numerical computation -- of which ML is a (popular, well funded) special case.
At least in my mini bubble, these kinds of "scipy but autodifferentiable" use-cases are fairly common.
I have read a lot of your JAX issues and libraries ;-)
Haha, that's fun to hear though! Thank you for sharing that.
You can do that too! That will disable every JIT though. In practice you might only want to disable just one.
To add some colour to my answer. When writing a library, it's typical to a put a JIT statement on everything in the public API. This means you get the benefits of JIT compilation even when you're just hacking around in the REPL, and mitigates the new-user-footgun in which they forget to use JIT themselves.
Meanwhile, good practice is always to JIT your whole computation.
Combined, this mean that it's fairly common to go jit (at the top level) -> grad (of your operation) -> jit (of some library call).
When debugging your code, the JIT'd library call is _probably_ not the culprit. So you only want to disable the top-level JIT when stepping through, and still take advantage of JIT compilation where you can. Overall one obtains a composition of the form grad(jit(...)).
TL;DR: even if use case doesn't come up super frequently, it's more user-friendly to support grad(jit(...)) than it is to just crash.
If you like PyTorch then you might like Equinox, by the way. (https://github.com/patrick-kidger/equinox ; 1.4k GitHub stars now!) Basically designed to offer PyTorch-like syntax for working with JAX. The latter is excellent for the reasons the sibling replies have stated, but PyTorch absolutely got the usability story correct.
You can do JAX->TF->ONNX I believe: https://github.com/patrick-kidger/equinox/blob/main/equinox/...