23:10: "Cancer is not one specific disease. Cancer is actually many diseases put together. In fact, cancer is many rare diseases -- if you take cancer to the limit, it's likely the case that the same cancer has never occurred twice.
"If you look at the genetic footprint of cancer, even within the same patient -- as I'll explain in just a moment -- you get very different cancers from the same originating source. And I'll explain why that is. That's why this sort of very information-driven approach to curing cancer is absolutely critical."
26:29: "... the genome has syntax. And in fact, it has a semantics. And beyond that, it has an instruction set too."
30:00: "So when you're fighting cancer, you're fighting evolution itself inside your own body."
Talking about that, I feel obliged again to mention the work of Damien Woods, Yannick Rondelez and Nicolas Schabanel who are actually assembling DNA tiles implementing wang tile gliders (a la game of life) and then "higher" primitives up to a nano Turing complete machine.
An odd feeling to watch his slides (I don't have them as of now sadly)
The talk I saw was from Nicolas Schabanel only, and his presentation was aimed at undergrad so the content has a smaller scope. But I recognized some fundamentals in this (213 pages!) PDF.
I was at Curry On! but missed that talked. Everyone kept telling how good it was so I watched it as soon as it was put online.
While Matt's (medical) story is truly inspiring, the link with the other (CS) part is really dubious to say the least.
Still, it shows how transposing ideas from a discipline to another can yield leap and bounds advances, although in this particular case it was fortunate that this happened very quickly after the technology to do this became available.
Yeah, the 'real engineers build sturdy bridges' argument falls down when you realize that there aren't hundreds of malicious adversaries trying to blow up the bridge at every hour of the day...
A fun recent example mitigating the halting problem came from an affectionate troll level(o) in mario maker
I'm unsure whether the underlying implementation uses approximation techniques, as the op suggests, or if Nintendo simply identified potential halting offenders and added a layer of checks to overcome the intractable issue
note: the clip is loud and includes the player yelling fuck; in case that offends.. that said, the whole level playthrough is a lot of fun
Yeah, but this is about player death stead level completion
In the clip the level maker cleverly constructed a trap wherein the player gets stuck between two blocked doors which creates an infinite loop passing Mario back and forth
The game engine realises what is happening after the second pass and just kills Mario closing the loop
You can solve this sort of thing relatively easily by checking if the player keeps entering the same position with no change in state (and no user interaction).
Vim does the same sort of thing when you do 999999j (or more sophisticated things like repeating a macro a billion times).
"If you look at the genetic footprint of cancer, even within the same patient -- as I'll explain in just a moment -- you get very different cancers from the same originating source. And I'll explain why that is. That's why this sort of very information-driven approach to curing cancer is absolutely critical."
26:29: "... the genome has syntax. And in fact, it has a semantics. And beyond that, it has an instruction set too."
30:00: "So when you're fighting cancer, you're fighting evolution itself inside your own body."