"The Gender Gap in Math" presented by the Harvard Undergraduate Mathematics Association

Panel: Gigliola Staffilani (Professor, MIT Math), Rediet Adebe '13 (PhD, Harvard SEAS), Hilary Finucane '09 (PhD, MIT), Alison Miller '08 (Postdoc, Harvard Math)
Moderator: Sarah Richardson (Professor, Harvard Social Studies)

HUMS: Some Numbers

The Harvard Undergraduate Math Survey (May 2014) was organized by Meena Boppana, Kate Donahue, Domniki Georgopoulou, and Caitlin Stanton, with contributions by Rahul Dalal, Ellen Robo, and Isabel Vogt, and advised by Prof. Benedict Gross. It had 130 responses, 55 from math concentrators (1/3 of math undergrads); here are a few of the findings.

Are you made uncomfortable by the gender gap in math?

• 3% of male responents
• 54% of female respondents

How many professors do you believe you can ask for a letter of recommendation?

• Female respondents: 1.0
• Male respondents: 1.6

Did you compete in math competitions in high school?

• 80% of male respondents
• 75% of female respondents

Are you planning on writing a thesis in pure mathematics?

• 25% of female respondents
• 50% of male respondents

Are you planning on grad school in mathematics?

• 65% of male respondents
• 25% of female respondents

Panel Discussion

Moderated by: Professor Sarah Richardson, Professor of popular gen-ed "Gender and Science: From Marie Curie to Gamergate"

Richardson: Let's get a

Languages and concurrent programs

Zac Kinkaid -- U. Toronto

Automatic analysis of algorithms

We'd like to know things like "What numeric types are used here? Are these array accesses in-bounds?"

Today: Proving the absence of faults in multi-threaded programs.
Multi-threaded programs are a great target for automated analysis, since they're so notoriously difficult for humans to reason about.

History:

• Floyd -- program invariants
• Ashcroft, Manna -- extended Floyd to multithreaded programs by treating a multiprogram as a nondeterministic single-threaded program -- difficulty: doesn't scale in #threads
• ??, Reese -- (for data-independent threads) Prove each thread correct individually; then check that the reasoning doesn't interfere across threads -- difficulty extending to data-dependent threads, which requires some cleverness, which is difficult to automate

in common: attempts to reason about multi-threaded code using (extensions of) sequential reasoning

The big problem

Given (program, property), does property(program) hold?

Problem!

Turing: Halting indeterminacy
Rice's Theorem: Every nontrivial property is undecideable

Solution

Allow either one-sided error or indeterminacy/divergence

Example

x = 2; y = 1
while(y != 0):
    y = randInt() mod x
    x = y + 2

Consider let the set of reachable states be points on the integral lattice; while we can't compute anything meaningful on all of them, we can reason about geometric supersets of them (here, the set \(y-x\leq1\))

Invariants from Constraints

Write a constraint system defined by program structure; prove by induction that the invariants continue to hold

Again, this extends badly

Data-flow graphs

Draw some sequential graphs side-by-side; add additional cross-thread dataflow links (aware of active synchronization). Think: When you're imposing synchronization on your programs, you're really pruning unwanted dataflow.

Multiple-threading: Need to add data-flow links within threads

The State of Progress

Chrome, Opera isolate the renderer in separate processes -- this allows tabs to crash on their own. ...but the issue is that the browswer is still a monolithic kernel.

Servo -- extra threading! ...but still monolithic.

The problem: Browser developers take the monolithic design as a given, and tinker around the edges.

The Problem

What is a browser trying to do? Provide services for origins -- render, computation, i/o + messaging

• It provides
  origin = <protocol, host, port>

Render: HTML CSS MathML Aria WebGL video canvas images

IO: XHR DOM IndexedDB Cookies FileReader BrowserCache AppCache

Currently: providing services for origins, but they're high-level and complex. You wouldn't ask your operating system to implement Emacs in the kernel. ...well, you might. That was a test; I've already called the police on you.

Kernel: network, UI, storage (concurrency)

Usercode: rendering, javascript, parser

Atlantis

Taglines: security, performance, robustness

But first, some depressing things...

Browsers offer many opportunities for parallelism! ex: HTML parsing, rendering, network and disk IO. But current architectures limit concurrency, suffer from races.

But the DOM model says: JS is single-threaded, and cannot see browser locks. So: JS execution should biglock the DOM. What does happen: NOT THAT.

But in reality, there's just no concurrency re: the DOM. None. more at: Race Detection for Web Applications -- Petrov et al., PLDI '12

idiosyncratic abstraction (n.) an abstraction that is inconsistently applied throughout an application.

HTML5 screen-sharing attacks: SOP should prevent attacker.com from opening and screen-scraping bank.