PhD Dissertation Defense

Independent Vector Analysis:
Theory, Algorithms, and Applications

Matthew Anderson

1:45pm Wednesday, 17 April 2013, ITE 325B

The field of blind source separation (BSS) is a well studied discipline within the signal processing community due to its applicability to a variety of problems when the data observation model is poorly known or difficult to model. For example, in the study of the human brain with functional magnetic resonance imaging (fMRI), a neuroimaging sensor, BSS algorithms are able to provide medical researchers and practitioners with a decomposition of a three-dimensional ‘movie’ of the brain that is amenable to analysis. BSS algorithms achieve this decomposition with only a few justifiable assumptions; this is contrary to methods based on the general linear model, which require prespecified models of the expected or desired response to achieve analysis of fMRI data.

Most BSS algorithms consider just a single dataset, but it also desirable to have methods that can analyze multiple subjects or data collections in fMRI jointly, so as to provide insights beyond that achieved with individual analysis of single datasets. Several frameworks for using BSS on multiple datasets jointly have been proposed. The subject of this dissertation is the study of one of these frameworks, which has been termed independent vector analysis (IVA). IVA is a recent extension of the classical independent component analysis (ICA) model to BSS of multiple datasets and it has been the subject of significant research interest. In this dissertation, we provide a formulation of IVA that accounts for sources which possess properties such as a) following Gaussian or non-Gaussian distributions; b) samples are independently and identically distributed (iid) or are dependent; and c) having either linear or nonlinear dependence of sources between datasets. The proposed IVA formulation utilizes the likelihood to define the objective function. This formulation admits to theoretical analysis. In particular, we provide the identification conditions, i.e., we determine when the sources can be ‘blindly’ recovered by IVA, and give a lower bound on the source separation performance.

Several algorithms exist for achieving IVA. We provide several new approaches to developing IVA algorithms and apply these approaches using a Gaussian distribution source model and a more general Kotz distribution model. The former, in addition to leading to efficient IVA algorithms, serves as the distribution model that directly connects canonical correlation analysis (CCA) and ICA.  

Committee: Dr. Tulay Adali (Chair), Dr. Joel Morris, Dr. Aninyda Roy, Dr. Ronald Phlypo, and Dr. Mike Novey

With widespread adoption of HTML5 standards, browsers are taking SVG in new directions, such as emphasizing the <svg> tag for inline SVG, using CSS for styling, and opening up the DOM so that SVG images can be created or manipulated on the client side with JavaScript. Part-1 of this two part article will discuss these methods in detail.

After releasing our new coding interface, a number of users have had difficulty running code and loading exercises over the past week. I apologize for this. These issues are not related to the new interface, but instead are deeper issues with how we evaluate code submissions. I wanted to share the background of what is happening and what we are doing to build a stronger code evaluation platform going forward.

Background

It is possible, but not at all easy to run languages like Ruby, Python, and PHP directly in the browser. In fact we used to do this by serving an interpreter for each language, compiled to JavaScript, to your browser!

We ultimately found this approach to be too fragile to use in production, and last summer we launched the Python language track on top of a server-side code evaluation service that we call Codex. Codex was originally designed to run Python code in a secure environment. As we added new language tracks like Ruby and PHP, we began to push it to its limit.

When we designed the new interface, we built it to be more responsive. Unfortunately this strained Codex in ways it wasn't intended to be used, resulting in spotty performance. Making Codex more robust will let the new interface deliver on its promise.

What we're doing about it

Codex has gone through some significant growing pains as we've rapidly expanded both our user base and the ways we use the service.

We pushed a series of fixes to take it off life-support and are doubling down our investment in it as the backbone of our coding experience. We are refactoring core aspects of the service to handle much larger loads and adding support for multi-process environments (i.e. running mongodb, node.js, and redis together in a single app).

This will ensure that Codex is prepared to grow with users as they tackle an ever increasing variety of topics and technologies. Thank you for your patience, and we're excited to see what you build!

If you are experiencing these issues, please see our support article here.

After releasing our new coding interface, a number of users have had difficulty running code and loading exercises over the past week. I apologize for this. These issues are not related to the new interface, but instead are deeper issues with how we evaluate code submissions. I wanted to share the background of what is happening and what we are doing to build a stronger code evaluation platform going forward.

Background

It is possible, but not at all easy to run languages like Ruby, Python, and PHP directly in the browser. In fact we used to do this by serving an interpreter for each language, compiled to JavaScript, to your browser!

We ultimately found this approach to be too fragile to use in production, and last summer we launched the Python language track on top of a server-side code evaluation service that we call Codex. Codex was originally designed to run Python code in a secure environment. As we added new language tracks like Ruby and PHP, we began to push it to its limit.

When we designed the new interface, we built it to be more responsive. Unfortunately this strained Codex in ways it wasn't intended to be used, resulting in spotty performance. Making Codex more robust will let the new interface deliver on its promise.

What we're doing about it

Codex has gone through some significant growing pains as we've rapidly expanded both our user base and the ways we use the service.

We pushed a series of fixes to take it off life-support and are doubling down our investment in it as the backbone of our coding experience. We are refactoring core aspects of the service to handle much larger loads and adding support for multi-process environments (i.e. running mongodb, node.js, and redis together in a single app).

This will ensure that Codex is prepared to grow with users as they tackle an ever increasing variety of topics and technologies. Thank you for your patience, and we're excited to see what you build!

If you are experiencing these issues, please see our support article here.