Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alphafold

github.com

Post reply on HN
Print view View original

151–160 of 170 posts

Re: Alphafold

#151

Post by unholiness »

AnimalMuppet wrote: post #73
COGlory wrote: post #24

I am a structural biologist. This is one of the handful of topics that overlaps with my field here. I'm very excited to play with this, although it might eventually put me out of a job.

Here's where I think we need to be going: You go to a doctor's office, sick. 1) They take a blood sample. 2) They find the malignant bacteria and DNA sequence it. 3) If it's a known strain, they know what antibiotics to use on it. 4) If not, they solve protein folding on the genes. 5) From that, they see which existing antibiotics would kill it. 6) If none will, then given the proteins, they have to derive a new anti…

> The sequencing part is pretty much solved.

DNA sequencing is still slow and very expensive. On the scales you're talking about it's just not worth it.

I think I agree at a high-level that there is a huge reservoir of demand for this technology. But it's also possible that solving protein folding and similar research will simply cease to be a bottleneck for that demand, and people will be out of jobs.

Re: Alphafold

#152

Post by dmos62 »

dekhn wrote: post #150
dmos62 wrote: post #140

Earlier quoted context omitted.

Unit testing usually isn't easily replaced by manual testing. If you have, for example, 3 units that can be in 2 different modes each, that's 2^3 different combinations, but only 2*3 unit modes. Testing the end result is more work than testing the units.

Discovery science is different from web software engineering. Most discovery scientists use manual testing, not unit testing. Very few actually do integration tests or system tests (this is something I'm trying to change). And, given the external results of the application, it's unclear to me how much additional value would come from a rigorous testing system.

> Very few actually do integration tests or system tests (this is something I'm trying to change).

Care to expand on what you're trying to do?

Re: Alphafold

#153

Post by plankers »

pelorat wrote: post #144
boublepop wrote: post #141

Earlier quoted context omitted.

True, and Tesla is so far behind competitors when it comes to self driving that they knowingly push the envelope, because either they succeed, or they kill their customers but hurt all self-driving companies. So both scenarios work to their advantage and they just pay the minor fines and compensations to the people the kill in the process. And the Elon posts some Tweets blaming the people who got killed and his fando…

Teslas philosophy is that self driving is useless if it can't handle every road and route out there, while Waymo who already has a ride hailing service, relies on pre-mapped routes and databases. Both have their advantages and disadvantages. Waymo requires huge databases and a constant network connection. But it's good enough to be used in real-life without a backup driver, in certain select locations that is. If the…

Tesla's approach, however, kills people. Waymo's has not as of yet.

Re: Alphafold

#154

Post by dekhn »

dmos62 wrote: post #152
dekhn wrote: post #150

Earlier quoted context omitted.

Discovery science is different from web software engineering. Most discovery scientists use manual testing, not unit testing. Very few actually do integration tests or system tests (this is something I'm trying to change). And, given the external results of the application, it's unclear to me how much additional value would come from a rigorous testing system.

> Very few actually do integration tests or system tests (this is something I'm trying to change). Care to expand on what you're trying to do?

Sure, I'm trying to take the idea of merging continuous integration with workflow/pipelines. It's all stuff that I learned at Google and is non-proprietary. The idea is have presubmit checks that invoke a full instance of a complex pipeline, but on canned (synthetic or pseudoanonymized or somehow not directly connected to the prod system) data, as an integration test. This catches many errors that would be hard to debug later in a prod workfflow.

In a sense, I see software testing/big web data and modern large scale data processing in science as a continuum and I want to bring the practices from the big web data and testing fields to bear on science pipelines.

Re: Alphafold

#155

Post by ericd »

plankers wrote: post #153
pelorat wrote: post #144

Earlier quoted context omitted.

Teslas philosophy is that self driving is useless if it can't handle every road and route out there, while Waymo who already has a ride hailing service, relies on pre-mapped routes and databases. Both have their advantages and disadvantages. Waymo requires huge databases and a constant network connection. But it's good enough to be used in real-life without a backup driver, in certain select locations that is. If the…

Tesla's approach, however, kills people. Waymo's has not as of yet.

Going slowly may mean fewer people die directly. But I think it’s useful to remember that every year we delay being able to replace human drivers means that roughly a million lose their lives worldwide in auto accidents, and many more are maimed, many permanently.

It’s obviously complex, though, bad PR likely delays things as well.

Re: Alphafold

#156

Post by miltondts »

tdfirth wrote: post #129

This isn't a criticism - I'm just curious to hear people's thoughts on this. When I look at this code, one of my initial reactions is that it does not seem to be very thoroughly tested. Sure, certain modules have been tested (e.g. `model.quat_affine`) but it's not clear how completely. Meanwhile, other modules, for example `model.folding`, have not been tested at all, despite containing large amounts of complex logic…

Research code is highly volatile: the details and architecture changes a lot. It is much more important to invest the time into writing more experimental code and validate it with e2e functional tests that don't need to change, than to constantly having to rewrite the code and the tests.

Re: Alphafold

#157

Post by dmos62 »

dekhn wrote: post #154
dmos62 wrote: post #152

Earlier quoted context omitted.

> Very few actually do integration tests or system tests (this is something I'm trying to change). Care to expand on what you're trying to do?

Sure, I'm trying to take the idea of merging continuous integration with workflow/pipelines. It's all stuff that I learned at Google and is non-proprietary. The idea is have presubmit checks that invoke a full instance of a complex pipeline, but on canned (synthetic or pseudoanonymized or somehow not directly connected to the prod system) data, as an integration test. This catches many errors that would be hard to de…

Apart from a shift in mental attitude, is it primarily about getting a dataset for the integration test?

Re: Alphafold

#158

Post by dm319 »

feanaro wrote: post #128
timr wrote: post #81

Earlier quoted context omitted.

Dunno yet. MSAs were always a key input to Rosetta (previous best method). How they were used was very different. Fundamentally, everything in this space (= non-physical methods) is about inferring structure from things that are closely related. And you can't solve the problem at all for non-trivial proteins using physics, so here we are.

> And you can't solve the problem at all for non-trivial proteins using physics, so here we are. I'd appreciate if you could expand a bit on what you meant here, sounded interesting.

I guess poster is referring to purely using physics to work out the structure - i.e. no more knowledge than how atoms/molecules move and the sequence. At the moment knowledge is gleaned from evolution by virtue of evolutionary conservancy.

Re: Alphafold

#159

Post by dekhn »

dmos62 wrote: post #157
dekhn wrote: post #154

Earlier quoted context omitted.

Sure, I'm trying to take the idea of merging continuous integration with workflow/pipelines. It's all stuff that I learned at Google and is non-proprietary. The idea is have presubmit checks that invoke a full instance of a complex pipeline, but on canned (synthetic or pseudoanonymized or somehow not directly connected to the prod system) data, as an integration test. This catches many errors that would be hard to de…

Apart from a shift in mental attitude, is it primarily about getting a dataset for the integration test?

also making sure the testing is hermetic (not breaking prod) and all the components are actually reproducible.

Re: Alphafold

#160

Post by timr »

l33tman wrote: post #139
timr wrote: post #26

Earlier quoted context omitted.

> Could you give an overview of how people can leverage this (or how you might?). Short answer: nobody knows. Traditionally, protein folding is a solution in search of a problem, but that's largely because the predictions were...unusably bad. This was always more of a super-difficult validation problem for the force fields and simulation methods, which could then be used for other problems of greater value (such as r…

I do agree with this but would add that you wouldn't want to do static docking to a single protein and sidechain configuration anyway so you're bound to find a usable forcefield. The incoming structure (ideally!) only needs to fall into the right energy landscape valley. If your forcefield and MD simulation can't keep this stable within the natural protein's configuration space you are probably not going to make prog…

I think we largely agree.

Any drug target of any real-world interest is going to have local motion (i.e. floppiness that is dependent on circumstance and time) that matters at least as much to the finding of a drug than the fold of the protein itself.

One place I hesitate here is that step 0 to doing that kind of a simulation is having a decent starting structure. So maybe protein folding can help there. But I'm also skeptical, because the quality of the structure matters a great deal to getting a good simulation. A bad/blurry structure is of marginal use.

Post reply on HN