abefetterman

Looks very cool, congrats on the launch!

From The Information interview:

You can tell what the pool of potential startup founders looks like. There's a bunch of ways you can do it. You can go on Google and search for audience photos of PyCon, for example, which is this big Python conference.

That's a self-selected group of people. Anybody who wants to apply can go to that thing. They're not discriminating for or against anyone. If you want to see what a cross section of programmers looks like, just go look at that or any other conference, doesn't have to be PyCon specifically.

I think journalists are snakes in general, but I don't see PG's argument that his statement is not sexist. His expanded argument seems to be:

1. A hacker ethos from a decade of programming is required to start a company like Facebook.

2. There are few women who have the hacker ethos already

3. YC can objectively determine who has a hacker ethos

4. YC cannot teach the hacker ethos in 3 months

5. This is the main reason YC does not accept many women

I think that there are a number of problems with this series of arguments, some of which are rooted in systemic sexism:

1. There are many great companies started by non-programmers. What PG calls a "hacker ethos" and his decision that it is necessary are both based on observing the output of a biased system that favors white males.

2. This doesn't seem to line up to me. >20% of CS grads are female yet <10% of YC founders are female (lower rate in early classes).

3. We know this is not true, as we all have cognitive biases. Some adjustment for this bias should be implemented if we want to have a fair system.

4. Maybe. But why not even try?

5. See #2. Maybe there is another reason, but this doesn't explain the very small number of female founders on its own.

Reading their actual paper further, it seems I read a bit too much into the original article. However, as their paper mentions:

> The parameter space of C-2U has over one thousand dimensions. Quantities of interest are almost certainly not convex functions of this space. Furthermore, machine performance is strongly affected by uncontrolled time-dependent factors such as vacuum impurities and electrode wear.

I'm not aware of DOE procedures that are robust to these types of issues, and would certainly appreciate any literature you have on the subject.

Regardless of theoretical literature, this procedure has enabled a dramatic shift in how these scientists think about their experiment. Furthermore it has enabled them to achieve results much faster than before (if you have been following Tri Alpha, it has been a real slog). Both of these are exciting to me even if they don't break new ground in the design of experiments.

Basically nobody was using automated gradient descent / etc because of the proclivity of these algorithms to get stuck on a boundary. The problem is the boundaries are not well defined. One example might be a catastrophic instability. If it gets triggered it has the potential to damage the machine. But the exact parameters in which the instability occurs are not well known. So with this algorithm you mix the best of both worlds: the human can guide away from the areas where we think instabilities are, the machine can do it's optimization thing. It's pretty simple overall but enables a big shift in how experiments are run.

Edit to add: these instabilities often look just like better performance on a shot-to-shot basis, which makes the algos especially tricky. Using a human we could say "this parameter change is just feeding the instability" vs "oh this is interesting go here"

This is actually a really exciting development to me. (Note, what is exciting is the "optometrist algorithm" from the paper [1] not necessarily googles involvement as pitched in the guardian). Typically a day of shots would need to be programmed out in advance, typically scanning over one dimension (out of hundreds) at a time. It would then take at least a week to analyze the results and create an updated research plan. The result is poor utilization of each experiment in optimizing performance. The 50% reduction in losses is a big deal for Tri Alpha.

I can see this being coupled with simulations as well to understand sources of systematic errors, create better simulations which can then be used as a stronger source of truth for "offline" (computation-only) experiments.

The biggest challenge of course becomes interpreting the results. So you got better performance, what parameters really made a difference and why? But that is at least a more tractable problem than "how do we make this better in the first place?"

[1] http://www.nature.com/articles/s41598-017-06645-7

The most interesting thing for these is liquid lithium metal--especially a great solution on diverter. For the wall neutron flux this is unfortunately seen as a "materials issue" (someone else's problem). It is a bit stalled out until we can build something with high enough neutron flux for testing.

Overall this is presenting a smaller university-class tokamak with advanced superconductors to try to reach Q>2 (scientific breakeven). One of the big advantages of higher fields is that the fusion power goes like B^4. I think this is an interesting idea, but it's hard to imagine the US funding something like this at the same time as ITER. Last year's talk [1] suggests "alternative funding," pointing to other private fusion research, which I am dubious of. There is a mindset that "if these bad ideas get funded, our good idea should get funded more," which we know is not how funding works.

As a former researcher of alternative magnetic confinement schemes, I'm disappointed the latest research in FRCs and mirrors didn't make it into this talk. Viewers should take into account that this, like most talks, is pushing an agenda, in this case a new device called SPARC. It appears to also be a way of using the incredibly talented tokamak researchers at MIT now that Alcator C-Mod is not operating.

[1] http://library.psfc.mit.edu/catalog/online_pubs/iap/iap2016/...

More descriptive is Tokamak rather than ITER, since ITER is still going to have burning DT plasma in 2035 (at the earliest, according to article).

ARC is not designed to be cheaper or faster to build than ITER. Its purpose is closer to that of DEMO (engineering breakeven). ITER data will be critical for verifying the ARC design.

The other efforts you mention are much further from having Q>1 (energy producing) fusion. FRCs and focus have not even reached Q=0.000001 and have little theoretical basis for being power producing. Stellerators have their own problems as well. Tokamaks have achieved Q=0.69, and so ITER has very little risk of missing its goal of Q>1 if it does get constructed and run DT.

I agree that fusion is severely underfunded, and that it is dangerous for us to put all our eggs in the Tokamak basket. And this article is pretty strange for its fixation on DEMO which at this point might as well be made of unicorn horns. But ITER was proposed and is supported by a huge number of scientists for a good reason: it's the best way for us to hit a goal that fusion science has been dreaming of for 50 years, that is key to understanding and designing real fusion reactors.

We used graphcool for our latest launch and it probably saved hundreds of back end dev hours. The team is really responsive on slack and intercom, the interface is great and really robust with query permissions and flexible mutation callbacks. The pricing is more than fair.

They've been a bit slow to implement new features for production, but I understand development timelines are hard to predict.

I think the product is in a pretty good place for a limited release right now. We are really looking forward to synchronous mutation callbacks and multi-region replication (currently only eu in production, us-west-2 and asia-pac are in beta). We're using lambda functions as in-betweens while we wait on synchronous callbacks and it's been totally fine, it just breaks the "GraphQL fits all your server api needs" paradigm.

Edit: it looks like today they just released "request pipeline" which is actually a pretty robust synchronous callback. Impressed at the thought that went into this. -- https://www.graph.cool/blog/2017-05-16-introducing-a-cli-fun...

There's a really great interactive nuclear energy cost calculator produced by Bulletin of the Atomic Scientists: http://thebulletin.org/nuclear-fuel-cycle-cost-calculator

Nomiku YCW15 made this.