Interesting to see it mention quantum chemistry, could anyone familiar with the field chimu in on whether it is viable to get accurate bond energies? It mentions Hartree-Fock, but I thought that that wasn't accurate enough to find transition states.
HN user
smj-edison
Email is: stephen dot mason dot jones at the big alphabet company.
Github is https://github.com/smj-edison/
you can use their LLM to trivially clone their software.
Perhaps, but what you can't clone is familiarity, polish, integration, and network effects. These companies desperately need a moat, and so for example all the new additions to Claude's web interface are becoming the products that the vast majority of people will use and be locked into (if it goes according to their plan).
Dynamicland hasn't published any of their code, while folk computer priorizes being open source. So yes, a lot of the ideas come from Dynamicland, but there's the important detail that you can actually use folk computer.
Yes and no. If we could "just" run full QM, there's still the issue of building abstractions regarding the emergent behavior. A full system is still useless if you can't describe things like ligands, carbon rings, etc. So regardless of whether we can simulate it, we still need terms for higher level concepts.
But yes, nano and even femtosecond level second stuff is pretty mind bending.
Thank you for the kind words! I've been wanting to do this research precisely because of firsthand experience with how hard chronic illness can be, and I'm hoping to attack it with a systems approach.
I haven't seen that website before, but it sounds pretty accurate from what I've heard. It's insane how high of a mountain needs to be climbed just to catch up to the state-of-the-art, and how much work is needed to push through to figure out something truly new.
Here's to making the world a better place!
Disclaimer: I'm only a freshman, so there's still a ton I don't know :)
Right now the lab is having me get comfortable using software like Gaussian and ORCA by simulating a bifurcating reaction. This is a reaction that, depending on the catalyst's momentum, will change what site it bonds to (it makes either a 6-membered or 7-membered ring). I'm finding the intermediate states (where the molecule is most stable) and transition states (the tipping point), and then running trajectories to see which output is more likely.
Once I've finished simulating that, I should be comfortable enough with the process to jump on the bigger project, which is machine learning interatomic potential (MLIP) model distillation. There's a lot of exciting work around speeding up DFT methods by using machine learning (note this is not generative AI, it's merely predicting the molecule energy based on atomic positions). So my one year goal is to get on that project and start contributing.
My five year goal is to, well, graduate. But then I'll probably do a PhD in computational chemistry, since I'm really interested in ways to speed up and scale existing methods. My big dream is to simulate large biological systems while still having bond formation and breaking, to automatically elucidate biochemical pathways, but there's still a lot of steps in-between.
I'm only a freshman, so I don't feel very qualified to comment on that :) I hope so though!
And also emergent behavior means that at each level, we need different abstractions to deal with the problem. Even with chemistry, there's ideas like benzene rings that are aromatic, that you couldn't predict that from particle-particle interactions. So it's not just that it's hard to understand quantum mechanics, it's that understanding QM doesn't mean you'll understand the problems that chemistry deals with.
Depends what level of accuracy you want. I just started in a computational chemistry lab so I'll probably get some details wrong, but for small systems, you can use a method called CCSD(T) for up to ~20 atoms, but it scales O(N^7). I've been mainly using DFT for the systems I've been simulating, which scales O(N^3). I've been running a system with about 50 atoms with a decent basis set (how the orbitals are modelled), and it takes about 30 minutes for each optimization step with 24 cores and 48 GB of RAM.
DFT works in many cases, but in some cases it doesn't estimate the energy right, due to how it bypasses some correlation calculations. Bonds are extremely sensitive to energy calculations, so you need to get super close to the actual energy in order to get useful results.
Anyways, someone with more experience here could probably add more, but that's what I've picked up so far.
Have you looked at Metamath Zero[1] before? You mentioned using sorts which is what reminded me of it. Just thought I'd point to some additional interesting work :)
The one plus I'll give reference counting is it still takes the cake for interoperability with C. Which is only important if you need good interoperability, but when you do, tracing GCs don't play nice.
Gilad Bracha wrote a fascinating piece on how tail call optimization could be implemented with periodic collection instead of immediately reusing the call frame, it's a fascinating piece: https://gbracha.blogspot.com/2009/12/chased-by-ones-own-tail...
I use Zig, which has slices, so so far none. But man, it can't get ref counting right to save its life. There have been remarkably few times it's gotten it right on the first try. My codebase considers OOM recoverable, so it keeps forgetting to clean up memory when OOM is raised. Even in the happy path though it still messes up ref counting. I use Kimi k2.6.
I feel like chemistry is one thing that current models will struggle with for the next while, because it's inherently 3D. In the micro world, shape = function. Maybe enough textual patterns will let it under chemistry, but like how do you describe a hydrogen shift without showing how it moves positions and rebalances bonds?
Overloadable operators are not an instance of hidden control flow.
In general perhaps not, but in Zig it definitely does. Zig considers calling a function to change control flow, because it's no longer just an operator but something that can cause side effects, includinh mutating in place. Perhaps control flow isn't the right term, maybe non-trivial would be better?
With regard to wrappers, I personally find them ugly since 1. They bring in indirection, and I have a personal vendetta against unnecessary indirection, 2. Wrapping doesn't compose well and is a pain to shephard between representations, 3. It's harder to make a function generic across different representations, and 4. Wrappers often don't re-export everything available to their underlying value.
At first I was going to say that I disagreed since you couldn't choose what implementation of addition you wanted, but now that I've read your comment where you import the type of addition used, it's growing on me. Would you have operator precedence, or would it be more like Smalltalk's binary operators?
I didn't realize compile time reflection was back on track, that's really exciting!
Andrew talks about it because it introduces hidden control flow where you're expecting simple operators. In Zig anything that deals with control flow is a keyword (including short circuiting and, which is `and` instead of `&&`).
I'd argue though that the real disadvantage to having overloadable arithmetic is that you're limited to one implementation. This is actually my biggest beef with Rust, namely traits/type classes. It locks you into a single implementation when you may want to do something different based on the context. Zig pushes the dispatch decision to the callsite, not a trait subsystem (see how Zig implements hash mays for example). So I'd personally prefer to use a DSL, since it lets me specify what type of dispatch to use.
That's the other great thing about using comptime, is you can specify which DSL you want to use for which scenario. You're not locked into one implementation.
I've been thinking about a way around this, and I'd be interested to see if comptime with a DSL wouldn't be too unwieldy. Something like
math("(v + Ω * c) * Δt", .{ .v = physics_data.velocity, .@"Ω" = omega, .c = change, .@"Δt" = frame_delta_time})
I know this is already possible with comptime, though I haven't implemented it yet since I haven't needed vector math in what I'm working on currently. Can't decide whether using math names is better or worse than using the full variable names though.It sounds like they're interested in the concept though, just not that specific implementation.
Yeah, I think that's closer to what I'm looking for. I'm actually looking into scaling up chemical simulation, so hopefully simulating it is feasible in the near future!
This has been my experience. After not getting answers for a long time from conventional doctors, I went to a naturopath out of desperation. I was diagnosed with "mold toxicity", and took a bunch of supplements to boost all the low levels I had (B12 and cortisol). I also took flax seeds to help with "detox". All the stuff helped a bit, but only a bit. It was still just symptom fighting.
Now to be fair, there are people whose lives have been changed by these treatments, because in some cases someone just happens to be low in some essential micronutrient, and seeing a naturopath solves that when a traditional doctor didn't do a broad assay. But it still doesn't help people like me where whatever is happening can't be described by surface level blood tests and treatments. Naturopaths talk about "wholistic health", but if it's so wholistic, why don't they consider intermediate reactions? So it's become a life goal of mine to build a quantitative metabolic reaction database. I'm currently a applied math major with a chemistry minor, so in a couple years I hope to be able to make some headway on this.
I've heard things hypothesized to be either differences in hormone levels, or the one that's more fascinating to me is it could be because an issue came up with suppressing the second X chromezone.
Source? Never heard of this before.
Thanks for the link! I looked over it, but I'm not seeing quantitative levels of reactions. That's been my biggest issue with current pathway databases. It's great to know what's connected to what, but very quickly it becomes everything connected to everything. And unfortunately everything doesn't reduce the problem space.
Maybe a bit of a strange take, but after having dealt with chronic illness personally and talked with a lot of others with chronic illness, I don't think classifying chronic illness by symptoms will help with curing, and in fact I don't think categorizing works at all for chronic illness. We've been trying to classify chronic illnesses for so long, and yet in most cases no pattern emerges.
This has led me to conclude that perhaps in most cases chronic illness is an emergent behavior from a complex system, namely our body. Now tbh this is kind of a cheap take, because it's not that hard to conclude. But gosh darn it, we're programmers and we deal with complex systems all the time! What I want to see is a complete quantitative mapping of human metabolism, so that we can see all the in-between steps, not just the surface levels. That way curing chronic illness is more about comparing metabolite levels against known pathways and seeing what's regulated incorrectly. There's just not enough introspective capability currently.
My vision is some day a person who's been chronically ill can walk into a clinic, take a blood test, and with mass spectrometry get the level of the around 1800 different intermediate metabolites. That gets mapped to a known good metabolic graph, and it's optimized to find what in-between step is off kilter. They're then prescribed a drug that resets the bad state, and it 6 weeks they're back to normal.
I also doubt that AI will substantially help either. It still doesn't bring any more introspection capability, and if we can't figure out why someone is sick, I have little faith that a predictive AI can figure it out either.
Oh, is it not a specific keyword? I thought they were thinking of it being a keyword so you could be sure that it was restricted, in case a variable or function was exported that took in a foreign pointer.
I can tell you a bit about my own experience, as I've I used Rust for two years, but have now transitioned to Zig. I started working on a modular synthesis engine, and I realized that Javascript wouldn't give me the granular control I needed. So I decided to use Rust. This was my first foray into low level programming, so learning Rust first was great because I internalized their ownership rules. However, I started to realize that Rust was doing quite a bit of stuff behind my back, like freeing objects when dropped, or making allocations when I inserted an item. This is a big no-no for realtime programming, and Rust didn't help me understand what was happening. It was then that I read matklad's blog post on rust hard mode, https://matklad.github.io/2022/10/06/hard-mode-rust.html. I looked at some of his other blog posts too, and saw Zig. So Zig had been in the back of my mind for a while, when I decided to port a Tcl interpreter to Zig. I've been about 7 months in now making my own interpreter, and it's been a delightful language. Yes, I've had my share of memory leaks and double frees, but the debugging trace lets me capture a stack track at each reference count increment and decrement, so I'm able to hunt them down pretty well. I'm also hyper aware of memory layout and allocation failure, because allocation is fallible in Zig. The error union handling makes it pretty easy to propagate OOM though, so it's not hard to make code that's resilient to OOM. If I had tried to make this in Rust, I would have been fighting the standard library, ecosystem, and borrow checker constantly, because high level programming languages have non-trivial ownership semantics, and a lot of optimizations like epoch based variable caching just don't play nicely with references as trees.
I believe their plan is using "restricted function pointers", where you can specify that a pointer will only ever be to a function defined in the codebase. I'm pretty sure they also have plans for devirtualization, but I haven't followed super closely.