Pamela Toman

My final project for Stanford CS 224U was on automatically assessing integrative complexity. I drew on work I’d previously done that demonstrated ongoing value from this political psychology construct, but I had not previously tried to automatically code for this construct. The code is available on github.

Integrative complexity is a construct from political psychology that measures semantic complexity in discourse. Although this metric has been shown useful in predicting violence and understanding elections, it is very time-consuming for analysts to assess. We describe a theory-driven automated system that improves the state-of-the-art for this task from Pearson’s r = 0.57 to r = 0.73 through framing the task as ordinal regression, leveraging dense vector representations of words, and developing syntactic and semantic features that go beyond lexical phrase matching. Our approach is less labor-intensive and more transferable than the previous state-of-the-art for this task.

Convolutional neural networks transformed computer vision from “extremely hard” to “trivially achievable after a few weeks of coursework” between 2012 and 2016.

I prepared a talk for technical professional audiences that describes how neural networks extend linear classification, intuitions behind why convolutional neural networks work well for vision, and the circumstances in which they’re worth consideration. I used the “Intro to CNNs for Computer Vision” materials at two different employers in 2016, and also with the high schoolers who participated in SAIL ON in 2017. (SAIL ON extended a Stanford summer program in AI that captured underrepresented minorities; I led the summer program and extended it to two years of follow-up monthly outreach.)

My final project for Stanford CS 231N was on automatically identifying sign languages from publicly licensed YouTube clips. For this project I learned from scratch about working with neural networks, computer vision, and video data.

Automatic processing of sign languages can only recently potentially advance beyond the toy problem of fingerspelling recognition. In just the last few years, we have leaped forward in our understanding of sign language theory, effective computer vision practices, and large-scale availability of data. This project achieves better-than-human performance on sign language identification, and it releases a dataset and benchmark for future work on the topic. It is intended as a precursor to sign language machine translation.

As I haven’t yet created a permanent place to hold the dataset I collected for my most recent class project, I’m hanging it here for now.  SLANG-3k is an uncurated corpus of 3000 clips of 15 seconds each of people signing in American Sign Language, British Sign Language, and German Sign Language, intended as a public benchmark dataset for sign language identification in the wild.  Using 5 frames, I was able to achieve accuracies bounded around 0.66/0.67.  More details can be found in the paper and poster created for CS 231N, Convolutional Neural Networks for Visual Recognition.

Many thanks to everyone who helped with this project — and most especially to the anonymous survey respondents who received only warm fuzzies as compensation for taking the time to help with this early-stage research.

Some experimentation on constraints in Grails 2.4.4 (based on the constraint documentation) leads me to the following conclusions:

• Use “nullable” instead of “blank”. The documentation says that “blank” is for strings, but Grails 2.4.4 doesn’t seem to pay any attention to that keyword.  Setting “nullable” always works.
• If the field can be null, you can’t specify other constraints for when it is non-null.  The logic is “null or must conform to set of standards X” is not supported through combinations of nullable and other constraints.  You could get around this with custom validation or even regular expressions (using the constraints ‘validator’ or ‘matches’) if you wanted. (Perhaps there is another way to get around this – if so please share it!)
• All missingness is the same. All three missingness versions (empty string, null, and a missing parameter) have the same behavior.  This is in contrast to some of the things I had been reading about empty strings in HTML forms being treated differently in Grails from actual null values, so I wonder if this is one of the pieces that has changed over time.
• “Optionals” is no longer supported. Testing suggested this, and it is backed up by this JIRA report.

The chart below gives the specifics as well as the take-aways.

Input for all tests was a String variable.  When the string value “abc” was used, all tests pass.  I excluded all the attempts with “optionals”, because all of those failed and the keyword is no longer supported.