6 ms·

Does this sound like something out of Dirk Gently to anyone else? > Now the Stanford engineers believe they've broken that bottleneck by inventing what they ca

by bostik 11y ago

Does this sound like something out of Dirk Gently to anyone else? > Now the Stanford engineers believe they've broken that bottleneck by inventing what they call an inverse design algorithm. > It works as the name suggests: the engineers specify what they want the optical circuit to do, and the software provides the details of how to fabricate a silicon structure to perform the task. I'm quite sure the first novel, Holistic Detective Agency described a computer program that could do that. (In the novel it was of course sold to a governmental body, maybe military.)

aristus 11y ago
The software took in the thing the user wanted to do as input, and made up plausible excuses for why it should be done. A rationalization engine, as it were. This is a bit different, more of a constraints optimization problem. If you want a really weird story about that, here's one about the evolved FPGA: http://archive.bcs.org/bulletin/jan98/leading.htm http://archive.bcs.org/bulletin/jan98/leading.htm
- duaneb 11y ago
  > A rationalization engine, as it were...This is a bit different, more of a constraints optimization problem. How is this any different? An argument from fulfilling constraints optimally is very, very rational.
- deleted 11y ago
  [deleted]
- Thimothy 11y ago
  What that article says is incredible, awesome and I wonder if I could replicate it. It probably uses some Xilinx proprietary info about the bitstream though.
loarake 11y ago
This is actually what we do in radiotherapy nowadays, it's even called "inverse treatment planning". Basically a radio-oncologist or a dosimetrist contours (manually, with a pen) organs on every slice of a CT scan and then we just say "We want this much radiation in the tumour, and less than Y units in surrounding healthy tissues". Treatment planning software then simulates dose distributions from a bunch of possible radiation beam collimations and adjusts the amount of radiation coming out of each radiation "field" to minimize a cost function penalizing overdosing healthy tissue and underdosing the tumour(s).
- deleted 11y ago
  [deleted]
- colinthompson 11y ago
  As a computer graphics professional, this fascinates me. The integrals you describe are remarkably similar to a large variety of solutions we employ for area estimation and integration in general. For example, in a path-tracing paradigm, I would (naively probably) consider radiation beam collimation similar to what we call the "cone-angle" of a particular integration method, particularly WRT calculating illumination response for a given surface, etc. Can you describe in more detail what kind of calculations your treatment planning software does? It sounds fascinatingly similar to the advanced physically based rendering algorithms that are in common use in computer graphics these days. For example, I am guessing that radiation "fields" are akin to "light sources"? If so, I would guess that your planning software is doing all sorts of importance sampling of all these sources across a given domain. Anyway, I was an art major so all my jargon is probably off, but nevertheless I find your post fascinating.
  - loarake 11y ago
    I'm not super familiar with computer graphics, so you'll have to let me know if my description fits what you guys do ;) I found a youtube video (https://www.youtube.com/watch?v=msX1ypCjkK4 https://www.youtube.com/watch?v=msX1ypCjkK4) that should give you an idea of what I'm describing actually looks like. Specifically it introduces the concept of a multi-leaf collimator which serves as the main collimating device in modern radiotherapy. The other degree of freedom is the angle of the gantry you see rotating around the patient. Typically for every gantry angle, the treatment planning software would split up an open field (no collimation) into a bunch of 1x1 cm^2 "beamlets" and would simulate what kind of dose distribution you would get inside the patient from each beamlet (you turn the patient CT into a big 3D grid of voxels to simulate dose in). You then throw all those dose distributions into an optimiser, and you do what's called a fluence map optimisation which gives you the amount of radiation you want to deliver out of each beamlet. This is the optimisation step I described earlier where the cost function is basically a square difference between the dose in each organ from a given set of beamlet weights and what you want the dose to actually be. Healthy tissue is the limiting factor so you give as much as you can to the tumour while making sure that less than X% of the volume of a nearby organ gets more than Y units of radiation. There's a final step at the end that turns the fluence maps into actual deliverable apertures shaped by the multi leaf collimator. There's a huge amount of work that goes into the simulation aspect. You can't just model the radiation beam as pure light sources that attenuate in the body via some exponential decay because the high energy photons scatter off electrons which themselves scatter around while depositing energy (radiation dose) away from the point of interaction. The gold standard is Monte Carlo simulations (which is my area of research) since you can model the actual physics of particle transport but in practice most clinics will use a faster engine to generate dose distributions. The faster engines typically superpose a primary component (a pure exponential decay) convolved with a kernel representing the energy that gets deposited away from the point of interaction. That's probably way more information than you wanted ;)
coldtea 11y ago
>Does this sound like something out of Dirk Gently to anyone else? No, it sounds like bog standard declarative programming applied to hardware design.
copperx 11y ago
Program synthesis, applied to hardware?

by bostik 11y ago

aristus 11y ago

The software took in the thing the user wanted to do as input, and made up plausible excuses for why it should be done. A rationalization engine, as it were. This is a bit different, more of a constraints optimization problem. If you want a really weird story about that, here's one about the evolved FPGA: http://archive.bcs.org/bulletin/jan98/leading.htm http://archive.bcs.org/bulletin/jan98/leading.htm

duaneb 11y ago
> A rationalization engine, as it were...This is a bit different, more of a constraints optimization problem. How is this any different? An argument from fulfilling constraints optimally is very, very rational.
deleted 11y ago
[deleted]
Thimothy 11y ago
What that article says is incredible, awesome and I wonder if I could replicate it. It probably uses some Xilinx proprietary info about the bitstream though.

loarake 11y ago

This is actually what we do in radiotherapy nowadays, it's even called "inverse treatment planning". Basically a radio-oncologist or a dosimetrist contours (manually, with a pen) organs on every slice of a CT scan and then we just say "We want this much radiation in the tumour, and less than Y units in surrounding healthy tissues". Treatment planning software then simulates dose distributions from a bunch of possible radiation beam collimations and adjusts the amount of radiation coming out of each radiation "field" to minimize a cost function penalizing overdosing healthy tissue and underdosing the tumour(s).

deleted 11y ago
[deleted]
colinthompson 11y ago
As a computer graphics professional, this fascinates me. The integrals you describe are remarkably similar to a large variety of solutions we employ for area estimation and integration in general. For example, in a path-tracing paradigm, I would (naively probably) consider radiation beam collimation similar to what we call the "cone-angle" of a particular integration method, particularly WRT calculating illumination response for a given surface, etc. Can you describe in more detail what kind of calculations your treatment planning software does? It sounds fascinatingly similar to the advanced physically based rendering algorithms that are in common use in computer graphics these days. For example, I am guessing that radiation "fields" are akin to "light sources"? If so, I would guess that your planning software is doing all sorts of importance sampling of all these sources across a given domain. Anyway, I was an art major so all my jargon is probably off, but nevertheless I find your post fascinating.
- loarake 11y ago
  I'm not super familiar with computer graphics, so you'll have to let me know if my description fits what you guys do ;) I found a youtube video (https://www.youtube.com/watch?v=msX1ypCjkK4 https://www.youtube.com/watch?v=msX1ypCjkK4) that should give you an idea of what I'm describing actually looks like. Specifically it introduces the concept of a multi-leaf collimator which serves as the main collimating device in modern radiotherapy. The other degree of freedom is the angle of the gantry you see rotating around the patient. Typically for every gantry angle, the treatment planning software would split up an open field (no collimation) into a bunch of 1x1 cm^2 "beamlets" and would simulate what kind of dose distribution you would get inside the patient from each beamlet (you turn the patient CT into a big 3D grid of voxels to simulate dose in). You then throw all those dose distributions into an optimiser, and you do what's called a fluence map optimisation which gives you the amount of radiation you want to deliver out of each beamlet. This is the optimisation step I described earlier where the cost function is basically a square difference between the dose in each organ from a given set of beamlet weights and what you want the dose to actually be. Healthy tissue is the limiting factor so you give as much as you can to the tumour while making sure that less than X% of the volume of a nearby organ gets more than Y units of radiation. There's a final step at the end that turns the fluence maps into actual deliverable apertures shaped by the multi leaf collimator. There's a huge amount of work that goes into the simulation aspect. You can't just model the radiation beam as pure light sources that attenuate in the body via some exponential decay because the high energy photons scatter off electrons which themselves scatter around while depositing energy (radiation dose) away from the point of interaction. The gold standard is Monte Carlo simulations (which is my area of research) since you can model the actual physics of particle transport but in practice most clinics will use a faster engine to generate dose distributions. The faster engines typically superpose a primary component (a pure exponential decay) convolved with a kernel representing the energy that gets deposited away from the point of interaction. That's probably way more information than you wanted ;)

coldtea 11y ago

>Does this sound like something out of Dirk Gently to anyone else? No, it sounds like bog standard declarative programming applied to hardware design.

copperx 11y ago

Program synthesis, applied to hardware?