@@ -51,6 +55,10 @@
{% include meet-the-team.html %}
+
+ {% include submissions.html %}
+
+
@@ -87,29 +95,11 @@
+
+
Submissions
+
+
+ {% include submissions.html %}
+
+
-
- {% assign i = 1 %}
- {% for chapter in chapter_titles %}
- {% if chapter[0] == 'profiles and interviews' %}
- {% assign i = i | minus: 1 %}
- {% else %}
-
-
{{ chapter[0] }}
- {% for abstracts in chapter %}
- {% if forloop.first == false %}
- {% for abstract in abstracts %}
-
- {% include marginless_card_panel.html %}
-
- {% endfor %}
- {% endif %}
- {% endfor %}
-
- {% endif %}
- {% assign i = i | plus: i %}
- {% endfor %}
-
-
-
-
diff --git a/_posts/2017/2017-03-24-A-Choi.md b/_posts/2017/2017-03-24-A-Choi.md
new file mode 100644
index 0000000..7314eb5
--- /dev/null
+++ b/_posts/2017/2017-03-24-A-Choi.md
@@ -0,0 +1,99 @@
+---
+layout: post
+title: "A Feed-Forward Algorithm for Arithmetic Circuits"
+author: "Andrew Jemin Choi"
+supervisors: "Professor Guy Van den Broeck"
+category: "Artificial Intelligence"
+permalink: /a-feed-forward-algorithm-for-arithmetic-circuits
+year: "2017"
+
+---
+
+1 Introduction
+============
+
+Probabilistic queries are a foundation to many machine learning problems. We often query probabilistic models, such as Bayesian networks, to gain information about the variables in a system and make an Indians, Canadians, Brazilians, etc. Foreign students pay the full ride, so yes they are often upper middinferences about them. However, even the simplest queries in these networks, such as finding marginal probabilities of the input, come at an exponential cost. In fact, the problem of exact inference and making such queries in these probabilistic models is NP-hard [1].
+An effective approach for making exact inferences in networks is to construct an Arithmetic Circuit (AC) from the network polynomial. The network polynomial is a linear function that outputs the probability of an event given the input parameters of the network. Although building the AC from a network takes exponential time and space, queries can be executed linearly, i.e. $O(n)$, where n is the size of the circuit [2]. Therefore, compiling or learning ACs from networks provides an efficient alternative to making exact inferences [3].
+The state-of-the-art method uses a software algorithm to backpropagate the marginal probabilities of the network using bit-encoding[4]. We propose a new algorithm that will calculate marginal probabilities by using feed-forward ACs. The advantage of using strictly feed-forward ACs is that the entire circuit can be built in hardware, which can drastically reduce inference time and consume significantly less power compared to software implementations.
+
+2 Background
+==========
+
+An arithmetic circuit is a directed acyclic graph (DAG) with leaves that are variables or constants and interior nodes that are addition or multiplication operations. An arithmetic circuit can calculate the output value of a polynomial in linear size, where size is defined as the number of edges in the circuit.
+
+
+
+
+
+
Figure 1: A binary arithmetic circuit that expresses the linear polynomial: $f = (y) + (0.5(x) + 1$)
+
+By using ACs, we can calculate the partial derivatives and find the marginal probabilities in linear size, i.e. $O(n)$ edges [2]. This process is called backpropagation because we start calculating derivatives from the root (output) node and work our way backwards to the leaf (input) nodes to find the partial derivatives. The state-of- the-art uses bit-encoding backpropagation and a series of divisions in order to find partial derivatives in one pass. We began this project in hopes of finding a way to calculate the partial derivatives in a feed-forward network, in linear size.
+
+3 Approach
+========
+
+We can fundamentally calculate partial derivatives by calculating the products of
+all sibling nodes of a child node, where the derivative of a child node is defined as:
+
+$dr(c) = dr(p) \times \pi_{c \neq c\prime} vr(c\prime) [4]$
+
+This “naive” method requires $O(n^2)$ number of edges in the circuit.
+
+Our approach to finding marginal probabilities involves only using product nodes in a feed-forward circuit. We achieve this by applying memoization to cache previously computed products. By caching the products into a register to calculate partial derivatives, backpropagation can be done in $O(n)$ edges.
+
+This cache-based algorithm has two apparent advantages:
+
+1. The partial derivatives can be calculated linearly, i.e. $O(n)$ edges, regardless of the DAG structure. The algorithm works correctly for non-alternating trees, which is a feature absent from bit-encoded backpropagation.
+
+2. The algorithm can be implemented into a feed-forward arithmetic circuit using
+hardware.
+
+Figure 2 and 3 below outlines the forward pass and backward pass of the algorithm, respectively. In the forward pass, the number of child node accesses is bound by a constant (number of parent nodes). Similarly, in the backward pass, the edges needed to evaluate the derivative of a multiplication node is bounded by a constant number of operations (two products and one sum). Since every node operation is bound by a constant, we can see that the algorithm is $O(n)$.
+
+
+
+
+
+
Figure 2:Algorithm for computing circuit output and initializing the product caches
+
+
+
+
+
+
+
Figure 3:Feed-forward algorithm to calculate marginals
+
+
+4 Analysis
+========
+
+We compared the performance of three algorithms, written in C, on three different data sets. For the cache-based algorithm, we generated a feed-forward arithmetic circuit and compiled the circuit into C code. Then, we measured the CPU time needed to find the marginal probability of one variable from the initialized circuit structures.
+
+
+Test Set (nodes) | Bit-encoded (s) | Compiled-Cache (s) | Naive (s) |
+|:---------------:|:--------:|:--------:|:--------:|:--------:|
+**Verysimple.ac** (20) | 0.01994 | **0.00504** | 0.01921 |
+**Voting.ac** (12468) [5] | 2.29930 | **0.34500** | 6.85860
+**Movie.ac** (21714) [5] | 0.84004 | **0.18353** | 1.31189
+
+Table 1: CPU times (in seconds) of 10000 iterations of bit-encoded, cache, and naive algorithms. The values were averaged from 3 trials.
+
+The CPU times show that the compiled cache-based method is 4 to 5 times faster on simple circuit structures (verysimple.ac and movie.ac) and about 8 times faster for more complex structures (voting.ac) compared to bit-encoded backpropagation. We can attribute the improvement in performance to the simpler output circuit structure of the compiled code, and better performance in the forward pass compared to backpropagation. The cache-based algorithm was found to give correct results even for non-alternating circuits, which makes this algorithm suitable for a wider range of applications. In addition, it can be used into a hardware circuit, leading to faster and energy efficient inferences. We hope to compare the differences between a software and hardware implementation in future work.
+
+5 Conclusion
+==========
+
+We proposed a new algorithm to find the marginal probabilities in an arithmetic circuit in linear size using a cache-based feed-forward algorithm. We found that finding the marginal probabilities by compiling the feed-forward circuit significantly reduces inference time. The algorithm can also be used for a wider range of circuits, and it can be implemented in hardware, potentially using much less resources.
+
+### Acknowledgement
+
+I would like to thank Prof. Guy Van den Broeck for his brilliant insight and mentorship during this project. I am also grateful to his students in the StarAI Lab for their enlightening discussions during my stay at UCLA.
+
+### References
+
+1. Cooper, G. F., 1990. The computational complexity of probabilistic inference using Bayesian belief networks. Artif. Intell. 42, pp. 393-405.
+2. Darwiche, A., 2003. A Differential Approach to Inference in Bayesian Networks. J. ACM 50, pp. 280-305.
+3. Chavira, M. and Darwiche, A., 2005. Compiling Bayesian networks with local structure. In Proceedings of the 19th International Joint Conference on Artificial Intelligence (IJCAI), pp. 13061312.
+4. Darwiche, A., 2009. Modeling and Reasoning with Bayesian Networks. Cambridge University Press, Chapter 12.
+5. Bekker, J., Davis, J., Choi, A., Darwiche, A., and Van den Broeck, G., 2015. Tractable Learning for Complex Probability Queries. Advances in Neural Information Processing Systems 28 (NIPS).
+
diff --git a/_posts/2017/2017-03-28-A-Yasodhara.md b/_posts/2017/2017-03-28-A-Yasodhara.md
new file mode 100644
index 0000000..bfe0b04
--- /dev/null
+++ b/_posts/2017/2017-03-28-A-Yasodhara.md
@@ -0,0 +1,97 @@
+---
+layout: post
+title: "Uncovering predisposition to COPD with predicted gene expression"
+author: "Angeline Yasodhara"
+supervisors: "Aziz Mezlini and Anna Goldenberg"
+category: "Computational Biology"
+permalink: /uncovering-predisposition-to-copd-with-predicted-gene-expression
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+Chronic Obstructive Pulmonary Disease (COPD) is a term used to describe various lung diseases characterized by airflow limitation, including emphysema, chronic bronchitis, refractory (non-reversible) asthma, and certain forms of bronchiectasis. COPD is one of the leading causes of death worldwide, causing an estimate of 3 million deaths in 2015, and is hypothesized to be associated with heritable genetic factors as well as environmental exposures (e.g., smoking).
+
+One of the conventional ways to uncover genes associated with diseases is through a genome-wide association study (GWAS). This method examines the whole genome to find positions (loci) where patients suffering from COPD (cases) and those who do not (controls) differ significantly in nucleotides proportion, suggesting that it may influence the risk of the disease.
+
+Through GWAS, 836 loci have been discovered to be associated with COPD [1],[2]. However, these discovered loci do not provide information on how these loci affect lung function; for example, these loci may regulate the expression of the closest gene, or it could be distantly affecting other genes. For more insight, we can examine transcriptome data, which provides information on levels of messenger RNA that were transcribed from genes. The challenge with this approach is that there is a smaller number of individuals with observed transcriptome data than genotype data. To overcome these challenges, this project seeks to identify COPD-associated genes by looking at the predicted gene expression that was calculated from the larger genotype dataset.
+
+In this project, we explored different association tests to find genes associated with COPD. We used a novel statistical test, developed by Aziz Mezlini, one of the co-authors of this paper.
+
+2 Approach
+===
+
+We were provided with transcriptome and genotype datasets from populations of two ethnicities: African-American and Non-Hispanic White.
+
+
+
+
+
+
+
Figure 1:Number of individuals in given dataset. A Comparison between the total number of individuals with genotype and transcriptome data. B The exact numbers of individuals in dataset grouped by ethnicity and status
+
+The core of the approach was to apply machine learning methodologies to predict the genetically-regulated component of the gene expression; this was achieved by incorporating regions of the genome which have been known to influence the expression level of one or more genes, regions known as expression quantitative trait loci (eQTL). These eQTL regions serve as our predictor variables in the predictive model. There have been two new tools that attempt to predict gene expression using eQTL, namely PrediXcan [3] and fQTL [4]. These two tools approach the problem from a slightly different angle; while PrediXcan adopts an elastic net model, training on different tissue type datasets separately, fQTL takes a multi-tissue, multivariate approach, in which the eQTL effects are decomposed into tissue-specific and loci-specific components. For this project, we predicted gene expression using PrediXcan and fQTL for whole-blood and lung tissues.
+
+
+
+
+
+
+
Figure 2: The number of genes predicted by fQTL and PrediXcan models.
+
+After predicting gene expression using PrediXcan and fQTL, we performed association tests through different hypothesis-driven approaches, integrating transcriptome information with predicted expression.
+
+We used the following statistical tests during association analysis:
+1. T-test
+2. Logistic regression of gene expression values on case/control status
+3. Logistic regression of gene expression values on case/control status and smoking duration
+4. Mezlini’s test
+
+Mezlini’s test is a new statistical test developed by Aziz Mezlini to analyze if two populations are different by looking for enrichment close to the end of a distribution, as depicted by Figure 3.
+
+
+
+
+
+
+
+
Figure 3: Mezlini’s test looks for enrichment at the tail of a distribution. This figure depicts distribution of cases (target phenotype) and controls, where it is deemed as not associated by t-test but deemed as associated by Mezlini’s test.
+
+
+We identified 15 statistically-significant genes, 2 of which were previously discovered by GWAS. These genes genetically interacted and are located in the vicinity of previously GWAS-discovered loci.
+
+
+
+
+
+
+
+
+
Figure 4: List of genes discovered to be associated with COPD with its function and ethnicity. HYKK and PSMA4 were previously reported (by GWAS) to be associated with COPD.
+
+
+
+
+
+
Figure 5: Locations of previously published loci (in grey) and discovered genes (in black). As can be seen from the figure, the discovered genes are located near previously published loci. We can also observe that Mezlini’s test discover genes overlooked by T-test and logistic regression.
+Conclusion.
+
+
+Through this project, we have shown that Mezlini’s test is able to detect associations overlooked by other statistical tests, as shown in Fig. 5. Notably,, we have also found different genes associated with COPD in African-American and Non-Hispanic White datasets. This may be due partly to the difference in the numbers of individuals (AA:NHW = 2801 :5982). Additionally, it suggests that genes have varying degrees of predisposition (to COPD) among ethnicities.
+
+This project also shows that GWAS is insufficient in providing insight on the genetics behind COPD; inspecting predicted expression provides such insight on how these genes influence certain traits.
+
+### Acknowledgements
+Thank you to Dr. Anna Goldenberg and Aziz Mezlini for the continuous guidance and support! Special thanks to our collaborators from Brigham and Women’s Hospital, Harvard Medical School who have provided us with the COPD datasets: Michael Cho and Craig Hersh.
+
+Shoutout to all the lab members for all the help, discussions, and brainstorming sessions: Ben, Lauren, Daniel H., Ladislav, Shems, Mingjie, Kingsley, Daniel C., Lebo, Jaryd, Mohamed, and Walter.
+
+### Citations
+===
+
+1. K. Probert et al., “Developmental genetics of the COPD lung,” COPD Research and Practice, vol. 1, no. 1, pp. 10, Nov. 2015. doi: 10.1186/s40749-015-0014-x
+2. T. Burdett et al. (2017, August 14). The NHGRI-EBI Catalog of published genome-wide association studies [Online]. Available: http://www.ebi.ac.uk/gwas
+3. E. Gamazon et al., “A gene-based association method for mapping traits using reference transcriptome data,” Nat. Gen., vol. 47, no. 9, pp. 1091-1098, Sep. 2015. doi: 10.1038/ng.3367
+4. Y. Park et al., “Multi-tissue polygenic models for transcriptome-wide association studies,” bioRxiv, 2017. doi: 10.1101/107623
diff --git a/_posts/2017/2017-03-28-C-Herng-Yi.md b/_posts/2017/2017-03-28-C-Herng-Yi.md
new file mode 100644
index 0000000..093509b
--- /dev/null
+++ b/_posts/2017/2017-03-28-C-Herng-Yi.md
@@ -0,0 +1,119 @@
+---
+layout: post
+title: "Solving PDEs on Deconstructed Domains for Geometry Processing"
+author: "Herng Yi Cheng, Mitchell Dembowski, Silvia González Sellán and Christine Ma"
+supervisors: "Professor Alec Jacobson"
+category: "Scientific Computing/Numerical Analysis"
+permalink: /solving-pdes-on-deconstructed-domains-for-geometry-processing
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+The Laplace equation and Possion equation are partial differential equations (PDEs) which arise naturally from analyzing heat flow, Maxwell's equations of electromagnetism, and shape recognition in computer graphics [?]. We studied a new way to solve these equations on overlapping triangular mesh domains, in order to smoothen the computer animation of objects that are represented using those meshes. We designed several variants of a divide-and-conquer solution method, and tested them against each other for accuracy.
+
+2 Background
+===
+
+The Laplace equation models the steady-state distribution of heat on a domain $A \subset \mathbb{R}^2$ with each point $(p_1,p_2)$ on its boundary $\partial A$ held at a fixed temperature $g(p_1,p_2)$. The steady-state temperature distribution $u(x,y) : A \to \mathbb{R}$ must satisfy
+
+
+$\Delta u(x, y) = 0$ for all $(x, y) \in A \backslash \partial \mathbb{A}, (2.1) $
+$ u(p_1, p_2) = g(p_1, p_2) $ for all $(p_1, p_2) \in \partial \mathbb{A}, (2.2) $
+
+
+where (2.1) is the Laplace equation, $ \Delta = \frac{\partial^2}{\partial x^2} + \frac{\partial^2}{\partial y^2}$ is the Laplace operator and (2.2) is the boundary condition. (2.1) can be generalized to the Poisson equation.
+
+\begin{equation}
+\Delta u = h \text{ for constant } h \in \mathbb{R}. (2.3)
+\end{equation}
+
+The usual method for solving these PDEs numerically, known as finite element discretization, consists in approximating $A$ using a triangle mesh with vertices $v_1,\dotsc,v_n$ and substituting every function $f$ defined on $A$ by the vector of its finite evaluations $f_i=f(v_i)$. From this discrete perspective, solving either of the equations above becomes an optimization problem over a finite number of variables. The solutions to these optimization problems approximate the smooth solutions of the original PDE.
+
+In the case of the Laplace and Poisson equations, this optimization problem amounts to minimizing the discrete Dirichlet energy function, which has the form
+
+\begin{equation}\label{Eq:DirichletEnergy}
+E(u) = \frac{1}{2}{u^T}_A Qu_A + {c^T}u_A \text{, where } u_A =
+ (2.4)
+\end{equation}
+
+for some constant vector $c \in \mathbb{R}^n$. The $n \times n$ cotangent matrix $Q$ is ubiquitous in geometry processing and serves as the discrete equivalent of the continuous Laplace operator seen above; its derivation can be found in [?. ]. This energy is to be minimized over all $u_A \in \mathbb{R}^n$, subject to the boundary condition that fixes the entries of $u_A$ that correspond to vertices on $\partial A$. Expanding the matrix products in (2.4) shows that the right-hand-side is quadratic in the entries of $u_A$, therefore standard techniques of quadratic programming that minimize quadratic functions subject to constraints yield the energy minimizer, or the vector $u_A$ that minimizes (2.4). However, the precise method by which these optimization problems are solved will not be a concern throughout the paper.
+
+3 Domain Decomposition
+===
+
+How well the energy minimizers approximate solutions to the smooth PDEs depends on the quality of the mesh. Two important parameters of a mesh that determine its quality are its coarseness, as measured by the average lengths of edges (segments connecting vertices), and its regularity, as measured by the aspect ratios of its triangles. Very regular meshes have triangles that are roughly equilateral, while long and thin triangles make an irregular mesh. As mesh quality improves, the energy minimizers should converge to solutions to the PDEs.
+
+Generating quality meshes that represent complex shapes is an active field of research. In 3D, it is often much easier to decompose complex 3D shapes into the union of simpler domains, and then generate quality meshes for those domains. Thus, we study a divide-and-conquer approach to minimize the Dirichlet energy over the union of many domains by minimizing parts of that energy over each individual domain, while demanding that the minimizers agree wherever the domains overlap, to ensure a compatible combined minimizer. We will refer to this as the consistency requirement (formalized below). We implemented this approach to handle general pairs of overlapping 2D domains $A$ and $B$, with corresponding meshes.
+
+However, functions over $A$ and $B$ cannot be compared because they are represented, respectively, by vectors $u_A$ and $u_B$, whose entries are values on different sets of vertices. In order to formulate that consistency requirement, we linearly interpolate from $u_A$ over the triangles of $A$'s mesh to reconstruct a function $u_A : A \to \mathbb{R}$; this is to say, we take $u_A$ to be the only function which is linear on every triangle of $A$'s mesh while taking the values of $u_A$ at its vertices.
+Similarly, we reconstruct $u_B : B \to \mathbb{R}$. This reconstruction can be plotted out, as in Figure 1. Our contribution is to analyze the following two formulations of the consistency requirement as the linear constraints of quadratic programs, in the hopes that they can be generalized to 3D.
+
+**_Overlap sampling constraint (OSC)_** $u_A$ and $u_B$ must agree at the combined vertices of both meshes.
+
+**_Dirichlet sampling constraint (DSC)_** $u_A$ and $u_B$ must agree at the vertices of both meshes that lie on $\partial(A \cap B)$ (a small subset of the overlap sampling constraint).
+
+
+
+
+
+
+
+
+
Figure 1: Energy minimizers for the OSC (left) and the DSC (right), subject to the same boundary condition $g(x,y) = (x+0.3)^2y^2$. Note how the two generate virtually identical solutions, even though the second one is only enforcing equality on a much smaller number of vertices.
+
+4 Experiments and results
+===
+
+From each constraint we derived a quadratic program to solve the Laplace or Poisson equation over $A \cup B$, subject to a boundary condition $g : \partial(A \cup B) \to \mathbb{R}$. Namely, we minimized a weighted combination of $E(u_A)$ and $E(u_B)$, such that $u_A$ and $u_B$ satisfy that constraint, and take values on vertices in $\partial(A \cup B)$ as dictated by $g$. We subjected each type of quadratic program to a convergence test over two annular domains with annular union (see figure 1), and measured the maximum of the distance of the approximations provided by each method to the known analytical solution. We repeated this test for $\Delta u=0$, $\Delta u=1$ and for different levels of mesh regularity. $\Delta u = 1$ was chosen for a simple nonzero right-hand side; using any other nonzero constant would have simply scaled $u$.
+
+
+We concurrently tested the "ideal" method: combining the meshes of $A$ and $B$ into a combined mesh for $A \cup B$, and treating the minimizer of the Dirichlet energy over that combined mesh as a ground truth (GT) proxy to the analytic solution, when the latter is unknown. This ground truth would be unavailable in 3D where combining meshes is far more difficult, but it serves as a useful benchmark of our quadratic programs in 2D.
+
+
+
+
+
+
+
Figure 2: A pair of annular domains, in blue and red.
+
+Our results, presented in Figure 3, show the Dirichlet sampling constraint to be clearly superior. While the overlap constraint appears to be accurate when solving $\Delta u=0$ on regular meshes, it fails and does not even converge to the analytical solution for $\Delta u = 1$, or when the meshes become increasingly irregular. As expected, the ground truth deviates the least from the analytic solution and converges to it the fastest.
+
+We performed similar tests on different domain shapes, which can be seen in Figure 4. Since no analytical solution is available for these pairs of meshes, we simply measured the error between our methods and the co-refined ground truth (yellow line in figure 3), safely assuming that this last one will surely converge to the smooth solution of the PDE. The results obtained from these experiments agreed completely with those observed for the pair of annular domains.
+
+
+
+
+
+
+
+
Figure 3: Convergence of our methods for annular domains. The top row shows the results for regular meshes, while the bottom one shows the results for irregular meshes. The left column contains results for the equation $\Delta u=0$, while the right one does so for $\Delta u=1$.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Figure 4: Examples of pairs of meshes over which we have tested convergences
b) Two discretizations of an object that can be used for simulation.
+
+
+
+
+
Figure 1: Two discretizations of an object that can be used for simulation.
+
+
+An important distinction between point cloud and polygon mesh representations is the point cloud's lack of connectivity information. Elasticity requires a notion of connectivity to determine how applying a force to one point affects the points connected to it. Most meshfree methods simply take the set of all points in a certain radius $h$ around a given point to be connected to it (Figure 2). [?]
+
+This radial approach is problematic if two points are close to each other in space but have a large geodesic distance. Geodesic distance is the shortest distance between two points when taking paths that stay on the object (Figure 3). An incorrect interpretation of the topology will result in "invisible connections" that incorrectly constrain the movement of the object (Figure 4). The goal of our paper is to enhance the interpretation of the topology using point cloud geodesics. If you think of the point cloud as approximating a 2D shape, then a point cloud geodesic between two points is the geodesic distance between the points lying that 2D shape.
+
+
+
+
+
+
(a) All points in a radius $h$ are connected.
+
+
+
+
+
(b) A case where the radial approach connects across a gap.
+
+
+
+
+
Figure 2: The radial approach in meshfree methods
+
+
+
+
+
+
(a) Euclidean distance cuts through space.
+
+
+
+
+
(b) Geodesic distance stays on the object.
+
+
+
+
+
Figure 3: The Euclidean distance vs. geodesic distance distance between two points on a circle.
+
+2 Approach
+===
+
+We combine meshfree methods with point cloud geodesics to more accurately simulate point cloud data. The core of our approach is to use shortest-path graph searches to compute point cloud geodesic distances, then simulating the particles using those geodesic distances rather than standard Euclidean distances.
+
+To compute these point cloud geodesic distances, we represent the point cloud as a weighted graph with edge weights equal to the Euclidean distance between points (Figure 5). By exponentiating the weights we penalize large jumps. With sufficiently large exponent, the shortest-path graph distance approximates the geodesic distance.
+
+We define our graph as follows: given points $x_i$ and $x_j$, $(x_i, x_j)$ is an edge if and only if $\|x_i - x_j\| \leq h$, where $\|\cdot\|$ is the Euclidean norm. While our methods work if the graph is complete, we only connect points in a small radius to increase efficiency. Denote the edge weights by $w(x_i,x_j)$.
+
+We define a parameter, the $geodesicness$, which represents the extent to which our method avoids large jumps while searching for a geodesic path between points. Let $\gamma \geq 1.0$ denote the geodesicness. Different point clouds may require different values of $\gamma$ since there will be different sized jumps in the data. This parameter is tuned by the user.
+
+
+
+
+
+
+
+
+
+
Figure 4: Due to an "invisible connection" in (a) the movement of the object is incorrectly constrained in (b). We expect the elastic lower bar to bend downwards.
+
+
+
+
+
+
Figure 5: A graph defined over a point cloud. Two points are connected by an edge when their Euclidean distance is less than or equal to $h$. Edge weights are not represented in this figure
+
+
+Our geodesic approach uses $w(x_i, x_j) = \|x_i - x_j\|^\gamma$. As a result, large jumps in the data are expensive for the shortest-path graph search. With a sufficiently large $\gamma$, the path will walk around gaps and take a point cloud geodesic path (Figure 7). It can be seen that letting $\gamma = 1.0$ is equivalent to the traditional approach. The geodesicness required to get an improved simulation result depends on the size of the gaps in the data, the number of points along the geodesic paths, and the distance between each point along the geodesic paths.
+
+3 Results
+===
+
+We demonstrate our method's effectiveness by applying it to several point cloud data sets. Our simulations were done using a linear elastic material model, although our method works independently of the material model.
+
+Figure 8 uses a point cloud of two bars connected only on the left. We fix the top bar in place and leave the bottom bar free to deform under gravity. With the traditional radial approach, the bottom bar does not deform, since it is incorrectly connected to the fixed top bar. With our geodesic approach, the bottom bar is free to bend downwards.
+
+Figure 9 demonstrates our approach in the case of a user interacting with a pair of point cloud pants. We begin by fixing the top of the pants in place and allow the legs to deform freely. Next, a user attempts to pull the right leg to the right. With the traditional radial approach, the legs are incorrectly connected together and both pant legs deform. With our geodesic approach, the legs can move independently of each other as expected.
+
+Figure 10 demonstrates an application of our approach to character animation. We begin by fixing the head of the octopus in place and allow the arms to deform freely. With the traditional approach, the animator can't wiggle the arms around as they are stuck together. With our geodesic approach, the arms can move independently, allowing the octopus to wave hello.
+
+4 Limitations
+===
+
+Unfortunately, the quality of a simulation produced using this method does not gracefully degrade as the geodesicness decreases. If the geodesicness falls below a certain threshold, the close points that are far geodesically will immediately connect and the simulation will behave as in the traditional radial approach.
+
+
+
+
+
+
+
(a) An undeformed point cloud.
+
+
+
+
+
+
+
+
+
+
+
(b) Traditional radial approach: No visible deformation.
+
+
+
+
+
(c) Our geodesic approach: The bar bends downwards as expected. Uses $\gamma = 15$ .
+
+
+
+
+
+
Figure 8:
+The upper bar is held in place while an elastic lower bar should bend down due to gravity. Colour denotes displacement from original position.
+
+
+5 Conlusion
+===
+
+Since point clouds have no connectivity information it's easy to incorrectly interpret the topology when simulating elasticity. We introduced a method which combines meshfree methods with point cloud geodesics to help interpret the topology in cases where points are close in space but far geodesically. Future work includes generalizing to three dimensions and investigating a gracefully degrading point cloud geodesic distance.
+
+### Acknowledgement
+I would like to acknowledge David Levin and Alec Jacobson, my supervisors, and Tim Jeruzalski, my mentor, for their support and ideas throughout this project.
+
+
+
+
+
+
+
(a) An undeformed point cloud of a pair of pants.
+
+
+
+
+
+
+
+
+
+
+
(b) Traditional radial approach: The legs are stuck together.
+
+
+
+
+
(c) Our geodesic approach: The artifical constraint is not present. Uses $\gamma = 15$ .
+
+
+
+
+
+
Figure 9:
+A user deforms a pair of pants by pulling the black particle to the right. Colour denotes displacement from original position.
+
+
+
+
+
+
+
+
(a) An undeformed octopus bandit.
+
+
+
+
+
+
+
+
+
(b) Traditional radial approach: The arms are stuck together.
+
+
+
+
+
(c) Our geodesic approach: The arms may move freely. Uses $\gamma = 15$ .
+
+
+
+
+
+
Figure 10:
+An artist attempts to animate the octopus bandit waving hello
diff --git a/_posts/2017/2017-03-30-R-An.md b/_posts/2017/2017-03-30-R-An.md
new file mode 100644
index 0000000..a0a6a34
--- /dev/null
+++ b/_posts/2017/2017-03-30-R-An.md
@@ -0,0 +1,76 @@
+---
+layout: post
+title: "Parallel approach to single-source shortest path problem on large complete graphs"
+author: "Ruijian An"
+supervisors: ""
+category: "Computer Systems/Software Engineering"
+permalink: /parallel-approach-to-single-source-shortest-path-problem-on-large-complete-graphs
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+The single-source shortest path (SSSP) problem is a fundamental part of graph theory, with applications in transportation theory, road networks, DNA micro-arrays and many others. Given a weighted graph $G = (V, E)$ and a source vertex $v$, the SSSP problem computes the shortest paths from $v$ to all other vertices.
+
+There are many efficient sequential solutions to this problem, such as Dijkstra's algorithm and the Bellman-Ford algorithm [corman]. To maximize the work efficiency, Dijkstra's algorithm, which runs in O($\|E\| + \|V\|log\|V\|$), utilizes a greedy strategy, processing vertices one by one. On the other hand, the Bellman-Ford algorithm, which runs in O($\|E\|\|V\|$), processes all vertices in every stage. Nevertheless, for large complete graphs, these sequential algorithms take a prohibitive amount of time for time-sensitive applications.
+
+Although Dijkstra's algorithm is sequential in nature, the Bellman-Ford algorithm contains a lot of parallelism which can be exploited to speed up the processing of large graphs. Our goal is to parallelize the latter algorithm, by utilizing the massively parallel architecture of Graphics Processing Units(GPUs) on large complete graphs. By efficiently implementing the algorithm on a GPU, our implementation gains a speedup of 167x over the naive parallel GPU version and 10.6x over the optimized parallel CPU version for large graphs with up to 20000 vertices.
+
+
+
+
+2 Background
+===
+
+
+
+In the Bellman-Ford algorithm, each vertex in the graph has an attribute $d$, which records the tentative distance from source vertex to itself. The algorithm also employs a technique called $relaxation$ to process edges. If an edge $(u,v)$ with weight $w(u,v)$ is relaxed, $v.d$ is replaced by $min(v.d, u.d + w(u,v))$. The Bellman-Ford algorithm relaxes each edge for $\left|V\right|$ - 1 times, resulting in a time complexity of O($\left|V\right|$$\left|E\right|$).
+
+3 Approach
+===
+
+Our goal is to exploit the inherent data parallelism from the Bellman-Ford algorithm and accelerate it using parallelization techniques. First, we implement a straightforward naive parallelization, both on the CPU and on the GPU. Next, we optimize both implementations by improving work efficiency. Finally, we leverage GPU-specific features and mitigate the overheads of transferring data between main memory and device memory.
+
+The straightforward naive parallelization takes advantage of the inherent data parallelism. First, the shortest path estimate can be initialized in parallel. Secondly, edge relaxation, the most expensive step in the algorithm, can be parallelized. In existing parallel Bellman-Ford algorithms, each thread gets assigned a set of vertices and is responsible for relaxing either all the incoming or outgoing edges from its vertices [Busato2016AnEI] [Harish2007]. This approach uses adjacency lists and is well-suited for sparse graphs where $\|V\|$ is much larger than $\|E\|$. We use this as our naive multithreaded CPU implementation and naive GPU implementation.
+
+We observe that for complete graphs, partitioning work based on edges instead of vertices can exploit a higher degree of parallelism. While this approach is not straightforward to implement on the CPU, GPUs provide the ability to structure computations in a two-dimensional grid, where partitioning work by edges comes naturally. We use this observation as the baseline for our optimized GPU implementation and employ an adjacency matrix representation to better enable parallel edge relaxation on the GPU in an efficient manner.
+
+Next, we implement the optimized versions of the parallel CPU and GPU algorithms, which provide better work efficiency. We take advantage of two techniques, to discard unnecessary work. In the basic algorithm, all edges are required to be relaxed in each iteration, but not all relaxations are useful. For edge $(u, v)$, the key of $relaxation$ is to compare $v.d$ with $u.d + w(u,v)$, so the relaxation is useful only if the $v.d$ is updated in the previous iteration. Otherwise, the relaxation of $(u, v)$ involves redundant work. In the improved implementation, a bit $mask$ is used to record whether vertices are active. If a vertex's attribute $d$ is modified, then the corresponding bit indicates it is an active vertex. In the subsequent iterations, only edges whose starting vertex is active will be relaxed.
+
+Building on our previous observation, we can also reduce the number of iterations that the basic algorithm executes ($\|V\|-1$). The program can terminate once all shortest path distances converge, so instead of stopping at $\|V\|$-1, we can terminate early in an iteration when there are no more active vertices. We maintain a $flag$ to indicate if any vertices are active during the current iteration, and once the flag becomes unset, we skip the remaining iterations and terminate the execution early.
+
+
+Finally, a serialization bottleneck in our naive GPU implementation is the data transfer to device memory. In the optimized GPU algorithm, we restructure the code to leverage streams, which enable pipelining data transfers with computations.
+We create two streams $(stream1, stream2)$ and partition the adjacency matrix equally between them. Each part of the matrix is transferred to the device and processes in a different stream. Consequently, computations on the first part of the matrix can be carried out concurrently with transferring the second part of the matrix to the device, thus reducing the transfer time in half. We can further reduce this by similarly using more streams.
+
+4 Analysis
+===
+
+We conduct two sets of experiments (using randomly-generated complete graphs): first, we compare a
+sequential CPU implementation, a naive multithreaded CPU version (by doing edge relaxation in parallel over 4 physical cores on a Core i7 6700HQ @ 2.6Ghz), and a naive GPU-based algorithm(on an NVIDIA Geforce GTX750 Ti, 640 cores, @ 1100MHz), all of which are unoptimized. The second graph compares the optimized multithreaded CPU implementation with the optimized GPU algorithm as described in Section 3. We include the basic (unoptimized) _parallel_ CPU and GPU implementations as a reference point in the second graph. Both optimized versions enforce the aforementioned work efficiency optimizations, and the latter also leverages GPU streams for overlapping data transfers with computations.
+
+
+
+
+
+
Figure 1: Straightforward (work inefficient) parallelization on the CPU and GPU (log scale on y axis)
+
+
+
+
+
+
Figure 2: Work ineffcient vs. optimized algorithm implementations (log scale on y axis)
+
+In the first comparison, the naive GPU implementation outperforms both sequential CPU and naive multithreaded CPU versions. All implementations perform unnecessary computations, and the GPU implementation also suffers from high data transfer overheads to device memory. Consequently, we restructure parallel algorithms to reduce work inefficiencies, and use GPU streams to overlap memory transfers.
+
+Our results from Figure 2 show that the optimized GPU algorithm outperforms its optimized CPU counterpart, achieving a 10.6x speedup for a large graph with 20000 vertices. When the graph is small, the difference between the two implementations is not significant because only a subset of GPU cores are utilized and CPU cores operate at a much higher clock rate. However, the gap increases with input size, as more GPU cores actively participate in computations, while the same number of CPU cores process increasingly larger tasks. Although our testing limitations did not permit testing with larger graphs (e.g., millions of vertices), we expect this gap will increase even further.
+
+The optimizations and use of streams in the GPU implementation reduce the execution time by 167x compared to the work inefficient GPU version, while the optimized CPU implementation achieves up to 334x speedup over the work inefficient multithreaded CPU implementation, on large graphs.
+
+5 Conclusion
+===
+
+Our work proposes an improved parallel Bellman-Ford algorithm implementation. By reworking the algorithm to leverage GPU-specific optimizations, reduce work inefficiencies, and deal with the data transfer overheads using streams, the proposed implementation is 167x faster than a naive GPU implementation, and 10.6x faster than an optimized parallel CPU implementation, on large graphs.
+
diff --git a/_posts/2017/2017-03-30-Z-Zhou.md b/_posts/2017/2017-03-30-Z-Zhou.md
new file mode 100644
index 0000000..61e88da
--- /dev/null
+++ b/_posts/2017/2017-03-30-Z-Zhou.md
@@ -0,0 +1,65 @@
+---
+layout: post
+title: "User Customization of Caregiving Robots that Support Older Adults with Dementia"
+author: "Zehui (Joyce) Zhou"
+supervisors: "Professor Sheila McIlraith, Dr.Steven Shapiro, and Dr.Richard Valenzano"
+category: "Artificial Intelligence"
+permalink: /parallel-approach-to-single-source-shortest-path-problem-on-large-complete-graphs
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+Dementia affects more than 35 million people worldwide, and the number is still growing dramatically. Dementia affects people's ability to live independently, thus many dementia patients face the prospect of being institutionalized. As home care is often costly, we are investigating the development of an affordable socially assistive robot to support cognitively impaired older adults with daily living activities, which will potentially extend their time living at home.
+
+To communicate with patients effectively, a caregiving robot should tailor its interactions to its interlocutors, taking into account the nature and degree of cognitive impairment, other health issues, and individual preferences.
+
+
+2 Approach
+===
+
+We equipped the robot with a knowledge base embodying "best practices" for communicating with different classes of individuals [practice1,practice2, rochon, web1, web2, web3]. Upon delivery, the knowledge base can be augmented with (some) information about the people with whom the robot is expected to interact. When communicating with an individual, the robot uses the knowledge base to determine a customized strategy.
+
+People with dementia often have difficulty completing daily tasks.
+In this work, we customized the interactions of the robot with users of the COACH system, which provides assistance to complete the task of handwashing~[COACH].
+COACH tracks the user's hand positions to ensure that he or she is following a proper sequence to wash their hands.
+If COACH determines that the user is having difficulty, it will provide audio or video instructions, called $prompts$. These prompts are then customized by our system.
+
+3 Implementation
+===
+
+COACH uses a POMDP-based $Task Manager$ to estimate the user's progress and determine the next prompt.
+The prompt is then processed by the $Executor$ which plays a pre-recorded audio or video clip
+(see Fig. 1).
+
+To customize the behaviour of COACH, we deployed a $Prompter$ which reasons using features stored in the knowledge base to adapt the prompt for the user.
+We also modified the Executor so that it could use the output of the Prompter to dynamically generate an appropriate audio clip, rather than simply using a pre-recorded one (see Fig. 2).
+
+
+
+
+
+
Figure 1: The original COACH system.
+
+
+
+
+
+
+
Figure 2: COACH system with customization
+
+
+
+
+
+
+
Figure 3: The architecture of the Prompter
+
+5 Conclusion
+===
+
+We would like to thank our collaborators: CrossWing Inc.; Professor Alex Mihailidis and team at the Toronto Rehabilitation Institute; Professor Goldie Nejat and team in Mechanical and Industrial Engineering at the University of Toronto; and Professor François Michaud and team at the University of Sherbrooke. We also wish to thank Dr.Elizabeth Rochon from the Toronto Rehabilitation Institute for her expert advice on suitable strategies for communicating with persons with dementia.
+Computations were performed on the SOSCIP Consortium's Cloud Data Analytics computing platform. SOSCIP is funded by the Federal Economic Development Agency of Southern Ontario, the Province of Ontario, IBM Canada Ltd., Ontario Centres of Excellence, Mitacs and 15 Ontario academic member institutions.
+
diff --git a/_posts/2017/2017-04-01-S-Kousha.md b/_posts/2017/2017-04-01-S-Kousha.md
new file mode 100644
index 0000000..b9b32cd
--- /dev/null
+++ b/_posts/2017/2017-04-01-S-Kousha.md
@@ -0,0 +1,78 @@
+---
+layout: post
+title: "History Slicing as a Service"
+author: "Shayan Kousha"
+supervisors: "Yi Li and Professor Marsha Chechik"
+category: "Software Engineering"
+permalink: /history-slicing-as-a-service
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+Version control is a system of recording changes to a codebase over time in the form of commits so that specific versions and commits can be recalled later. A commit represents the difference between two versions of the source code. Version control systems are currently used broadly in software development. However, understanding the functional changes brought about by a given commit can be challenging. For instance, it is often necessary to determine the set of requisite commits for implementation of a feature or bug-fix. This forces developers to comb through commits and interpret the respective commit messages manually. This problem arises when a developer submits a feature for code review. It is naturally desirable to submit only the commits that are related to the feature while leaving out the irrelevant ones.
+We previously developed two $history slicing tools$, namely DEFINER [1] and CSLICER [2] to solve this problem. These tools help developers save time by automating the process. The programs however do not possess powerful graphical user interfaces (UI) and can only be operated through the command line, rendering them difficult to use.
+In order to unify the tools and make them more accessible, a web application was created. Through this application, users can easily access the tools without having to learn proper commands to run them in a command line environment.
+
+
+
+
+
+
Figure 1: Architecture Diagram
+
+2 Approach
+===
+
+Several libraries, tools, and technologies were utilized to build this web app. Figure 1 shows how they are connected to each other. It also presents the relationship between back-end and front-end components. The app’s core, however, consisted solely of DEFINER and CSLICER. The inputs to our tools are a Git repository, a history range (a continuous sequence of commits), and a set of test cases.
+A typical usage of the tool involves the following steps:
+
+1. The Git repository’s name and access permission are obtained by asking the users to log into their GitHub accounts. Users are redirected to the login page of GitHub using the OAuth framework [3], an authorization protocol. An authorization form is then displayed, indicating the type of permissions being granted. Next, users are asked to select the intended repositories from a list of all available options (See Figure 2).
+
+
+
+
+
+
Figure 2: Repositories’ names
+
+
+2. A node.js library called “git-flow-vis-host” [4] is used to facilitate the process of selecting a history range. This library helps us visualize the history of the selected repository and allows the users to select a history range. The visualized history is a diagram containing relevant information such as commit IDs and log messages (see Figure 3). Users indicate the start and the end of a range by clicking on two commits. The resulting history range comprises the start and end commits, as well as every commit in between.
+
+
+
+
+
+
Figure 3: Tests and history of a repository.
+
+3. The last step is to select test cases. A JavaScript library, “JsTree” [5], is used to display the test classes as well as the associated tests in a tree structure (see Figure 3). We analyze compiled byte code of the repository and extract all available test cases. Users then select the intended tests by clicking on a class and its $respective$ test cases. The test cases are used to determine whether a commit is related to a feature or high-level functionality. For example, to find the commits related to a $feature$, developers can select its associated feature test.
+
+The selected history range is then divided into several subsets. In the initial state of the execution, the division happens randomly. Subsequently, each test case is executed on all the resulting subsets. In the case of a test failing, it can be concluded that the subset is missing at least one related commit. Based on the test failures, commits are given a score and subsequent subsets are generated using the given scores. If all the tests pass, the subset is guaranteed to contain all the necessary commits. This subset can then be used as a new history range. This process is repeated until deriving a minimal set of commits that pass the tests, i.e., removing any of the commits in the subset results in a test failure. Finally, the web app highlights the commits in the selected subset that are required for tests to pass (See Figure 4).
+
+
+
+
+
+
Figure 4: The final result is highlighted.
+
+
+3 Analysis
+===
+
+We evaluated our tool on an open source software project Apache Commons-csv [6] , which is a Java library for manipulating CSV files. The evaluation task was to identify the commits that preserve a feature called “IgnoreCaseHeaderMapping”. The targeted history range was from the start commit, b230a6f5, to the end commit, ffb3c493, which contains 78 commits. The test case used is called “testIgnoreCaseHeaderMapping”, which is a method in the “CSVParserTest” class. It took our app a few minutes to display the result.
+The result consists of ten commits. Closer examination made it clear that applying those commits preserves the target feature. Since we were not familiar with the code and change histories of the project, it would have taken us a few hours to identify these ten commits. In addition, the current slicing engine executes tests sequentially and it can be slow when the input history is long.
+
+4 Conclusion
+===
+
+In this paper we shared our experience developing a web app to reach our goal of facilitating the use of our original tools, DEFINER [1] and CSLICER [2]. We explained how the web app works and what techniques and libraries we used to improve the quality of user experience.
+In the future, the goal is to optimize DEFINER [1], by multi-threading it to run the test in parallel instead of sequentially, and the web app, by implementing a cache of previous results. We believe parallelization will improve the performance of DEFINER. We hope to store the results for each run in cache and reuse them in subsequent runs.
+
+### Reference
+
+1. Yi Li, Chenguang Zhu, Julia Rubin and Marsha Chechik. Precise Semantic History Slicing through Dynamic Delta Refinement. In Proc. of 31st IEEE/ACM Int. Conf. on Automated Software Engineering (ASE’16).
+2. Yi Li, Julia Rubin and Marsha Chechik. Semantic Slicing of Software Version Histories. In Proceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering, ASE 2015.
+3. OAuth - https://oauth.net
+4. Teun/git-flow-vis-host - https://github.com/Teun/git-flow-vis-host
+5. JsTree - https://www.jstree.com/
+6. Commons-csv - https://github.com/apache/commons-csv
diff --git a/_posts/2017/2017-04-06-J-Yao.md b/_posts/2017/2017-04-06-J-Yao.md
new file mode 100644
index 0000000..b1a1b77
--- /dev/null
+++ b/_posts/2017/2017-04-06-J-Yao.md
@@ -0,0 +1,359 @@
+---
+layout: post
+title: "Numerical PDE Methods for Discontinuous Coefficient Problem"
+author: "Jienan Yao"
+supervisors: "Professor Christina Christara"
+category: "Scientific Computing/Numerical Analysis"
+permalink: /numerical-pde-methods-for-discontinuous-coefficient-problem
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+This project explores Partial Differential Equation (PDE)
+
+discretization methods
+for discontinuous coefficient PDEs,
+with application to a mathematical model simulating
+the invasion of brain cancer (glioma). This model involves
+a PDE with discontinuous diffusion coefficient
+due to the heterogeneous nature of the brain,
+consisting of white and grey matters.
+
+PDEs are ubiquitous in modeling many physical phenomena.
+Phenomena that involve diffusion (scattering) and reaction
+(e.g. proliferation)
+are often modelled by the so-called $reaction-diffusion$ PDEs.
+Such PDEs are pertinent to cancer growth,
+as the latter involves scattering and proliferation of cancerous cells.
+
+Physical problems that involve unknown quantities that
+are evolving in time (and vary along spacial dimensions)
+are modelled by time-dependent PDEs.
+These PDEs, together with equations describing
+the initial state (referred to as $initial$ $conditions$),
+and equations describing the boundary behaviour of the unknown
+(referred to as $boundary$ $conditions$),
+form an $Initial$ $Value$ $Problem$ (IVP).
+On the other hand, if the unknown quantities
+vary only along spacial dimensions,
+the PDEs together with boundary conditions
+form a $Boundary$ $Value$ $Problem$ (BVP).
+
+Often, PDEs cannot be solved by analytic methods.
+In such cases, numerical methods are employed for the PDE solution.
+The numerical solution involves two main steps:
+the conversion of the continuous problem
+into a set of discrete algebraic equations, referred to
+as $discretization$,
+and the solution of the arising set of equations
+(often a linear system of equations),
+which results in discrete approximate values of
+the unknown quantities or other related discrete values.
+The size of the system of equations depends
+on the number of discrete points/data ($discretization points$)
+taken in the domain of the problem.
+The discretization method is critical for the accuracy
+of the solution, as well as for the correctness of the solution,
+in the sense of satisfying any special conditions or constraints
+arising from the problem.
+A discretization method should $converge$,
+in the sense of the approximate solution values converging
+to the exact ones, as the number of discretization points
+increases. Faster convergence (i.e. a higher $order$ $of$ $convergence$) is desirable.
+
+The partial derivatives occurring in a PDE
+often appear with coefficient functions.
+Standard numerical PDE methods normally assume
+continuous coefficient functions. However, when
+these discretization methods are applied to
+a discontinuous coefficient PDE,
+convergence of the approximate solution,
+as the number of discretization points increases,
+is not guaranteed.
+Studying numerical methods for PDEs with discontinuous coefficients
+is pertinent to brain cancer growth,
+as it is known that the brain consists mainly
+of grey and white matter, and the diffusion rate
+(represented by a coefficient function) is
+higher in the white than in the grey matter.
+
+In previous studies, some researchers formulated Hermite spline collocation methods
+for discontinuous diffusion PDEs [1][2],
+using a clever adjustment
+of the basis functions to satisfy certain constraints
+resulting from the discontinuity of the coefficient.
+In [3], quadratic spline collocation methods are used, and
+in [4], adaptive Hermite spline collocation is formulated
+for the same problem, with a clever approximation
+of the discontinuous diffusion coefficient.
+In all these works, the expected (fourth) order of convergence
+is obtained.
+
+Finite Difference (FD) methods (approximating derivatives
+by linear combinations of discrete function values)
+are popular and flexible discretization methods for PDEs.
+We propose two approaches to adjust the standard
+FD methods,
+so that the numerical solution satisfies the
+constraints resulting from the discontinuity of the coefficient,
+and converges with the expected order of convergence.
+
+In Section 2, we present the problems considered.
+In Section 3, we describe the numerical methods developed,
+in particular regarding discontinuous diffusion,
+and in Section 4, we demonstrate results from numerical experiments
+that show the effectiveness of our methods.
+We conclude in Section 5.
+
+2 Discontinuous Diffusion PDE
+===
+
+The PDE under consideration is the Reaction-Diffusion PDE
+in one spatial dimension
+\begin{equation}
+\label{eq:IVP}
+u_t = (d(x)u_x)_x + \rho u + f(x, t) \equiv \mathcal{L}u + f(x, t), ~
+\mbox{in} ~ [a, b] \times (0, t_f), (1)
+\end{equation}
+where $u(x,t)$ is unknown quantity
+dependent on $x$ (spatial coordinate) and $t$ (time),
+which diffuses (spreads around) with diffusion coefficient $d(x)$
+and grows (proliferates or reacts) with coefficient $\rho$.
+Given the initial (at time $t = 0$) state of $u$, and
+some conditions at the boundary of the spatial domain,
+we want to predict the state at some given final time $t = t_f$.
+PDE (1), together with these initial and boundary conditions,
+forms an IVP.
+
+(In most realistic problems,
+the forcing term $f(x, t)$ is equal to zero,
+but we may set it to non-zero for the purpose
+of certain numerical experiments.)
+
+In the mathematical model for the density
+of tumoral cells in the brain of a patient,
+considered in [5],
+the non-homogeneity
+of brain (grey and white matter, reflected in the discontinuity
+of the diffusion coefficient) is modelled as
+
+
+
+
+
+For simplicity, the two values of the diffusion coefficient
+in the white and grey matter are set as follows:
+Let $D_w=1$ and $D_g = \gamma$ where $\gamma = \frac{D_g}{D_w} < 1$
+is a parameter chosen by the user.
+Assume, for simplicity, two interfaces: from left to right,
+$w_1$ (grey to white) and $w_2$ (white to grey).
+See Figure 1.
+
+
+
+
+
+
Figure 1: diffusion coefficient $d(x)$ as it varies with $x$.
+
+The presence of the discontinuity in the diffusion coefficient
+results in a certain type of (dis-)continuity conditions
+across interfaces modelled as
+
+
+
+
+
+Since the discontinuities occur along the space dimension,
+we also consider a BVP,
+described by the PDE
+
+
+
+
+
+where the solution $u(x)$ satisfies (dis-)continuity conditions
+similar to (1)-(2),
+and boundary conditions similar to those
+the solution of (1) satisfies.
+
+The space discretization techniques are easier to describe for the BVP than for the IVP. For this reason, we focus on the description of the space discretization techniques for the BVP in detail, and these techniques can be applied to the IVP.
+
+3 Numerical Methods
+===
+
+consider the space discretization of PDE (5).
+We discretize the spatial domain as shown in Figure 2.
+
+
+
+
+
Figure 2: Domain discretization
+
+For simplicity, we use uniform discretization.
+Let $x_0=a$, $x_i = a+ih_x~(i=1,\dots, N)$, $N=N_1+N_2+N_3$ and
+$h_x=\frac{b-a}{N}$. Also for simplicity,
+assume that $w_1 = x_{N_1} = x_k, w_2=x_{N_1+N_2}$ and $u(x_i)$ = $u_i$.
+Note that $N$ is the total number of subintervals
+and $N+1$ the total number of discretization points
+including boundary.
+
+Two approaches were developed in the project to deal
+with discontinuous diffusion.
+
+$Approach$ $1$
+
+We treat the PDE as multi-domain problem
+with individual respective approximations for each subdomain,
+and use the interface conditions as "boundary" conditions
+for the subdomain problems.
+Specifically, the equations used at the interface points are:
+
+
+
+
+
+
+Discretizing each term of equation (6) by one-sided FDs and taking into account (2) results in
+
+
+
+
+
+Note that, for non-interface points, we use the standard equations
+
+
+
+
+
+discretized by standard second-order FDs.
+
+$Approach$ $2$
+
+For all non-interface points,
+we use the same space discretization
+as in the first approach.
+For the interface points, we establish equations to relate
+%the limits of the functional and forcing terms from both sides
+the limits of the PDE terms from both sides
+of the interface point. The equations used at the interface points are:
+
+
+
+
+
+To discretize equation (9),
+we form one-sided stencils that involve $u_{xx}$ and $u_x$,
+take a linear combination of them so that the $u_x$ terms
+are cancelled using the discontinuity condition (3),
+while condition (2) is also taken into account,
+then add appropriate terms to form $\mathcal{L}u(w_1^-)$
+and $\mathcal{L}u(w_1^+)$. Then we get
+
+
+
+
+
+In the above relation, the term
+$f(w_1^-) + f(w_1^+)$ is approximated by
+$f(w_1-\epsilon) + f(w_1+\epsilon)$,
+for a suitably small $\epsilon > 0$.
+Relation (10) is discretized similarly.
+
+Following a similar derivation, the proposed space discretization methods
+can be extended to fourth-order accuracy
+(error in spatial discretization is $O(h_x^4)$),
+for both the interface and non-interface points.
+
+Coming back to (1),
+for the time discretization, we adopt the standard Crank-Nicolson
+timestepping scheme, with $\Delta t \propto h_x$,
+and, for the space discretization, the techniques
+we described for the PDE (5).
+
+4 Numerical Results
+===
+
+We first test the proposed space discretization schemes
+on a BVP, then extend them to IVPs.
+In all problems, we used $\gamma = 0.20$, $\rho = 1$,
+$a = -5$ and $b = -a$.
+In Problems 1 and 2, $w_1 = -0.5$, $w_2 = -w_1$, and
+in Problem 3, $w_1 = 0$ and $w_2 = 2$.
+
+In Problem 1, we pick a function $u$ that satisfies the interface conditions
+and take its gradients as defined in $\mathcal{L}u$
+to form the non-zero forcing term $f(x)$.
+Then, Problem 1 is a BVP with a known solution,
+guaranteed to satisfy the interface conditions.
+When we apply each of our approaches to Problem 1,
+we obtain respective approximate solutions
+that can be compared to the (known) exact one.
+Such a problem can be used as a benchmark
+to evaluate the accuracy of our computed approximate solutions.
+
+
+
+
+
Figure 3: Plot of error versus the total number of subintervals $N$ for Problem 1.
+For Approach 2, $\epsilon = 10^{-10}$.
+
+In Figure 3,the error of the computed solution decreases in the expected order:
+when the number of discretization points is doubled, the error
+becomes approximately 4 times smaller for the second-order method
+and 16 times smaller for the fourth-order method.
+The slope of the error plots indicates the (negative) order of convergence.
+
+Problem 2 is an IVP with exact solution known,
+and a non-zero forcing term $f(x,t)$
+formed according to PDE (1).
+The solution satisfies the interface conditions at all points in time and
+the state of $u$ at $t=0$ is given as the initial condition.
+Again, as in Problem 1, we compute approximate solutions
+by our approaches and compare them to the (known) exact one.
+
+
+
+
+
+
Figure 4: Plot of maximum error among all points in time versus $N$ for Problem 2.
+For Approach 2, $\epsilon = 10^{-10}$.
+
+In Figure 4, the error decreasing trend is similar to the BVP case.
+The convergence results match the expected ones.
+
+Problem 3 is an IVP with exact solution unknown,
+and a zero forcing term $f(x,t)$.
+The initial condition satisfies the interface conditions.
+
+While, as mentioned in the Introduction,
+other researchers managed to obtain
+fourth-order methods for the same problem,
+we did this by employing the simpler, more flexible
+and more widely used Finite Difference methods.
+
+Note that both the proposed methods can be generalized to more interfaces,
+and to non-uniform grid discretizations.
+We also plan to consider adaptive FD methods and
+extension to multiple space dimensions.
+
+### Acknowledgement
+I would like to express my sincere gratitude to
+my supervisor Christina Christara for her valuable guidance and
+kindly encouragement, and
+to the University of Toronto Excellence Award (UTEA) program
+for funding the project.
+
+### References
+
+1. M. G. Papadomanolaki and Y. G. Saridakis, “Collocation with discontinuous Hermite elements for a tumour invasion model with heterogeneous diffusion in 1+1 dimensions, ”in Numerical Analysis conference, NumAn2010, pp. 214–223, September 2010.
+
+2. I. E. Athanasakis, M. G. Papadomanolaki, E. P. Pa-padopoulou, and Y. G. Saridakis, “Discontinuous Hermitecollocation and diagonally implicit RK3 for a brain tumour invasion model,” in World Congress on Engineering WCE, Vol 1, pp. 1–6, July 2013.
+
+3. C. Christara, “Numerical methods for discontinuous diffusion parabolic PDEs with application to brain tumor growth, oral presentation,” in Canadian Applied and Industrial Mathematics Society conference, June 2014. oralpresenation.
+
+4. C. Christara, “Adaptive and non-adaptive spline collocation methods for pdes with discontinuous coefficients: application to brain cancer growth,” in Canadian Applied and Industrial Mathematics Society conference, July 2016. oralpresenation.
+
+5. K. R. Swanson, E. Alvord, and J. Murray, “A quantitativemodel for differential motility of gliomas in grey and white matter,”Cell proliferation, vol. 33, no. 5,pp. 317–329,2000.
\ No newline at end of file
diff --git a/_posts/2017/2017-04-08-A-Mishkin.md b/_posts/2017/2017-04-08-A-Mishkin.md
new file mode 100644
index 0000000..0ae78be
--- /dev/null
+++ b/_posts/2017/2017-04-08-A-Mishkin.md
@@ -0,0 +1,87 @@
+---
+layout: post
+title: "Web ValueCharts: Analyzing Individual and Group Preferences with Interactive, Web-based Visualizations"
+author: "Aaron Mishkin"
+supervisors: "Professor Poole and Professor Giuseppe Carenini"
+category: "HCI"
+permalink: /web-valuecharts-analyzing-individual-and-group-preferences-with-interactive-web-based-visualizations
+year: "2017"
+
+---
+
+1 Introduction
+===
+
+any critical decisions in business development, policy planning, and daily life can be framed as preferential choices: decisions made by picking out the most preferred option from a finite set of alternatives. Multi-criteria preferential choices occur when the alternative must be chosen according to a set of competing criteria. Selecting an alternative that performs well across all criteria is often impossible and instead tradeoffs must be carefully considered. There is significant evidence that people are poorly suited to such tasks [1]. Furthermore, preferential choices can involve one to many - multi-stakeholder decisions require understanding and balancing stakeholder preferences that may conflict. Multi-criteria preferential choices therefore pose challenging, complex problems for individuals and organizations alike.
+
+In this work we present Web ValueCharts (WVC), a web-based software system to support multi-criteria preferential choices in both the single and multi-stakeholder settings. WVC enables individual and collective analysis of linear preferences models through interactive visualizations. Our goal in creating WVC is to make preferential choices more comprehensible, participatory, and engaging, thereby increasing stakeholder satisfaction in decision outcomes.
+
+
+2 Background
+===
+
+
+Multi-Criteria Decision Analysis (MCDA) is the prescriptive branch of Decision Theory concerned with quantifying tradeoffs in multi-criteria preferential choices. Linear models are a formalism from MCDA that represent stakeholder preferences by assigning a $utility$, or measure of value to the stakeholder, to each alternative. A linear model is defined as follows:
+
+Let $C$ be the set of criteria, and $A$ the set of alternatives. Then, a score function $s_{t}(c, a)$ is used to express the performance of alternative $a \in A$ under criterion $c \in C$ to a stakeholder $t$. These scores are normalized so that $s_{t}(c, a) = 1$ for the best alternative under $c$ and $s_{t}(c, a) = 0$ for the worst. A weight is also defined for each criterion, denoted $w_{t}(c)$, and encodes the importance of $c$ to $t$ relative to the other criteria. The sum of these weights is normalized to 1. Given a complete mapping of score functions and weights to criteria, the linear model computes the utility $u_{t}(a)$ as:
+
+$[u_t(a)$ = $\sum_{c \, \in \, C}$ $w_t(c)*s_t(c,a)]$
+
+There are several existing visualization systems that support stakeholders in exploring linear models. Our previous work on the ValueCharts [3] and Group ValueCharts [4] visualizations focused on the single and multi-stakeholder settings separately: ValueCharts supports inspection of just one linear preference model, while Group ValueCharts is designed for analysis of multiple models at the same time. Other software systems with visual encodings similar to ValueCharts and Group ValueCharts, such as LineUp [2], suffer from similar restrictions. WVC builds on ValueCharts and Group ValueCharts to create a software system that can support decision tasks across both settings.
+
+
+
+3.1 The ValueCharts Visualization
+===
+
+The ValueCharts visualization displays criteria as rows and alternatives as columns. The height of each row is directly proportional to the weight assigned to the corresponding criteria in the stakeholder's linear model $w_t(c)$. The cells where a row and column intersect represent the score of the column's alternative under the row's criterion ($s_t(c, a)$); a full cell reflects a score of one, while an empty cell reflects a score of zero. The stacked bar chart at the top of a ValueChart shows the total utility $u_t(a)$ for each alternative.
+
+To refine their linear models, a stakeholder may adjust their weights by clicking and dragging on the dividers between row labels. Score functions can be changed by directly interacting with the scatter plot (continuous criteria) or bar chart (discrete criteria) in each row. Modifications to preferences are immediately reflected in the dynamic visualization. Sensitivity analysis (modifying models to understand how the most preferred alternative changes) is thus easily performed using ValueCharts.
+
+
+
+
+
+
+
Figure 1: An annotated ValueChart for a single stakeholder trying to choose a hotel in Vancouver. The utility for the best alternative given the stakeholder’s linear model is clearly highlighted. Color is used to encode criteria.
+
+3.2 The Group ValueCharts Visualization
+===
+
+Once satisfied, stakeholders participating in a group decision may submit their linear models to be included in a Group ValueCharts visualization (Figure 2). They are then allowed to view the $Group$ $ValueChart$ as well as the ValueChart corresponding to their own preferences through a simple toggle.
+
+Group ValueCharts is designed to support comparisons between stakeholders' preferences. It enables stakeholders to comprehend multiple, often conflicting, preference models simultaneously, and its visual encodings facilitate quick identification of disagreements. Group ValueCharts preserves the fundamental language of ValueCharts - criteria are displayed as rows and alternatives as columns. However, each row cell contains an additional bar chart of red outlines showing the distribution of weights assigned by stakeholders to the criteria. Note that row heights no longer encode criteria weights. Instead, they represent the maximum weight assigned to the criteria by a stakeholder. Additionally, each column contains one bar per stakeholder to indicate their scores $s_t(c,a)$ and utilities $u_t(a)$.
+
+
+
+
+
+
+
Figure 2: An annotated Group ValueChart for a three stakeholders collectively trying to choose a hotel in Vancouver. Notice that color is used to encode users instead of criteria as in a ValueChart.
+
+
+4 Discussion
+===
+
+WVC implements a cycle of decision analysis at the single and multi stakeholder levels by combining the ValueCharts and Group ValueCharts visualizations and allowing users to easily transition between them. There is strong evidence that decision making is similarly iterative [1]. Past research has shown the effectiveness of ValueCharts and Group ValueCharts $independent$ of one another [5] [4]. We are confident that WVC' combined and expanded functionality provides greater support for preferential choices. We are beginning a comprehensive task-based analysis of the application in order to demonstrate this.
+
+WVC's web implementation is lightweight, accessible, and built with cutting edge web technologies including Angular, d3, and ExpressJS. Figure 3 contains a detailed comparison of WVC with ValueCharts and Group ValueCharts and reveals the decided benefits of a modern internet application. We are constantly improving the software, which is open source. We are also actively exploring new avenues of research, including a novel method for active learning in preferential choices based on Bayesian optimization and additive Gaussian processes.
+
+
+
+
+
+### Acknowledgements
+I would like to express my very great appreciation to David Poole, Giuseppe Carenini, and Emily Hindalong for their excellent guidance. I would also like thank NSERC for funding this project.
+
+### References
+
+1. Ralph L Keeney and Howard Raiffa. Decisions with multiple objectives:preferences and value trade-offs". Cambridge university press, 1993.
+
+2. Giuseppe Carenini and John Loyd. Valuecharts: analyzing linear models expressing preferences and evaluations.In Proceedings of the workingconference on Advanced visual interfaces, pages 150–157. ACM, 2004.
+
+3. S. Bajracharya, G. Carenini, B.C. Chamberlain, K. Chen, D. Poole, H. Taheri,and G. Oberg. Interactive visualization for group decision-analysis. Unpublished manuscript, Department of Computer Science, University of British Columbia,Vancouver, Canada, 2017.
+
+4. Samuel Gratzl, Alexander Lex, Nils Gehlenborg, Hanspeter Pfister, and Marc Streit. Lineup: Visual analysis of multi-attribute rankings.IEEE transactions on visualization and computer graphics, 19(12):2277–2286, 2013.
+
+5. Jeanette Bautista and Giuseppe Carenini. An empirical evaluation of interactive visualizations for preferential choice. In Proceedings of the working conference on Advanced visual interfaces, pages 207–214. ACM, 2008.
diff --git a/_sass/style.css b/_sass/style.css
index c79c39c..b6c2f98 100644
--- a/_sass/style.css
+++ b/_sass/style.css
@@ -8397,7 +8397,7 @@ figcaption {
border-left: 4px solid #67373f !important; }
.header-background {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-position: center; }
.review-subtitle {
@@ -8409,7 +8409,7 @@ figcaption {
padding: 0 !important; }
.page-footer {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
margin: 0px !important;
min-height: 100px;
padding: 30px 0 30px 0 !important; }
@@ -8430,7 +8430,7 @@ figcaption {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100vw; }
@@ -8449,7 +8449,7 @@ figcaption {
@media only screen and (min-width: 651px) and (max-width: 992px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100%; }
@@ -8508,7 +8508,7 @@ figcaption {
@media only screen and (max-width: 650px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover; }
.collapsible-toc {
diff --git a/_sass/style.scss b/_sass/style.scss
index bbaa799..2d32790 100644
--- a/_sass/style.scss
+++ b/_sass/style.scss
@@ -44,7 +44,7 @@
$web-title: "Code Pro Demo";
$post-title-font: "Calibri";
$post-font: "CMU Serif";
-$background: url("../resources/backgroundweb2016.svg");
+$background: url("../resources/backgroundweb2017.svg");
$toc-height: 570px;
$toc-width: 896px;
diff --git a/assets/2017/A.Choi/ac_example.pdf b/assets/2017/A.Choi/ac_example.pdf
new file mode 100644
index 0000000..1c88499
Binary files /dev/null and b/assets/2017/A.Choi/ac_example.pdf differ
diff --git a/assets/2017/A.Choi/ac_example.png b/assets/2017/A.Choi/ac_example.png
new file mode 100644
index 0000000..68678fb
Binary files /dev/null and b/assets/2017/A.Choi/ac_example.png differ
diff --git a/assets/2017/A.Choi/alg1.png b/assets/2017/A.Choi/alg1.png
new file mode 100644
index 0000000..a8afd44
Binary files /dev/null and b/assets/2017/A.Choi/alg1.png differ
diff --git a/assets/2017/A.Choi/alg2.png b/assets/2017/A.Choi/alg2.png
new file mode 100644
index 0000000..95d638e
Binary files /dev/null and b/assets/2017/A.Choi/alg2.png differ
diff --git a/assets/2017/A.Choi/feedforward_circuits_andrewchoi.tex b/assets/2017/A.Choi/feedforward_circuits_andrewchoi.tex
new file mode 100644
index 0000000..a3a037f
--- /dev/null
+++ b/assets/2017/A.Choi/feedforward_circuits_andrewchoi.tex
@@ -0,0 +1,167 @@
+\documentclass[11pt,a4paper, final, twoside]{article}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{amsmath}
+\usepackage{fancyhdr}
+\usepackage{amsthm}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{amscd}
+\usepackage{latexsym}
+\usepackage{graphicx}
+%\usepackage{graphics}
+\usepackage{natbib}
+\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black, citecolor=black]{hyperref}
+\usepackage{color}
+\usepackage{natbib}
+\usepackage{sectsty}
+\setcounter{MaxMatrixCols}{10}
+
+
+\sectionfont{\fontsize{12}{15}\selectfont}
+
+\renewcommand{\thefootnote}{}
+\setlength{\oddsidemargin}{1pt} \setlength{\evensidemargin}{1pt}
+\setlength{\hoffset}{-1in} \addtolength{\hoffset}{25mm}
+\setlength{\textwidth}{140mm}
+\setlength{\marginparsep}{0pt} \setlength{\marginparwidth}{0pt}
+\setlength{\topmargin}{0pt}
+\setlength{\voffset}{-2in} \addtolength{\voffset}{20mm}
+\setlength{\textheight}{300mm}
+\setlength{\headsep}{20mm}
+\setlength{\footskip}{15mm}
+\pagestyle{fancy}
+\fancyhead{} \fancyfoot{}
+
+
+
+% Theorem environments
+\newtheorem{thm}{Theorem}[section]
+\newtheorem{algorithm}[thm]{Algorithm}
+\newtheorem{axiom}[thm]{Axiom}
+\newtheorem{lem}[thm]{Lemma}
+\newtheorem{example}[thm]{Example}
+\newtheorem{exercise}[thm]{Exercise}
+\newtheorem{notation}[thm]{Notation}
+\newtheorem{problem}[thm]{Problem}
+\theoremstyle{proposition}
+\newtheorem{prop}{Proposition}[section]
+\newtheorem{case}[thm]{Case}
+\newtheorem{claim}[thm]{Claim}
+\newtheorem{conclusion}[thm]{Conclusion}
+\newtheorem{condition}[thm]{Condition}
+\newtheorem{conjecture}[thm]{Conjecture}
+\newtheorem{cor}[thm]{Corollary}
+\newtheorem{criterion}[thm]{Criterion}
+\theoremstyle{definition}
+\newtheorem{defn}{Definition}[section]
+\theoremstyle{remark}
+\newtheorem{rem}{Remark}[section]
+\newtheorem{solution}[thm]{Solution}
+\newtheorem{summary}[thm]{Summary}
+\numberwithin{equation}{section}
+\pagenumbering{arabic} % 1, 2, 3, 4, ...
+
+\begin{document}
+\hyphenpenalty=100000
+
+\begin{center}
+{\Large \textbf{\\A Feed-Forward Algorithm for Arithmetic Circuits}}\\[5mm]
+{\large \textbf{Andrew Jemin Choi}\\[1mm]}
+{\normalsize \emph{Under the supervision of Professor Guy Van den Broeck}\\[1mm]}
+\end{center}
+
+% Introduction
+\section{Introduction}\label{I1}
+Probabilistic queries are a foundation to many machine learning problems. We often query probabilistic models, such as Bayesian networks, to gain information about the variables in a system and make inferences about them. However, even the simplest queries in these networks, such as finding marginal probabilities of the input, come at an exponential cost. In fact, the problem of exact inference and making such queries in these probabilistic models is NP-hard. [1, 2]
+
+An effective approach for making exact inferences in networks is to construct an Arithmetic Circuit (AC) from the network. [3] The state-of-the-art method uses a software algorithm to backpropagate the marginal probabilities of the AC. [4] We propose a new algorithm for calculating marginal probabilities by using feed-forward ACs, which can potentially reduce inference time and power comsumption.
+
+% Background
+\section{Background}\label{I2}
+A network polynomial is a linear function that outputs the probability of an event given the input parameters of the network. An example of one such polynomial is: \newline \centerline{$f=0.4\times(\theta_{f}) + 0.6\times(\theta_{\overline{f}})$} \newline
+Evaluating the network polynomial is important in making inferences in our network. However, the number of terms in the polynomial is exponential with respect to the number of inputs. One compact way of representing these exponential terms is to express the polynomial using an arithmetic circuit. [2]
+
+An arithmetic circuit is a directed acyclic graph (DAG) whose leaves are variables or constants and whose interior nodes are addition or multiplication operations. The size of an arithmetic circuit is defined as the number of edges within the circuit. The size of the circuit also grows linearly with respect to the number of terms in the polynomial.
+
+% Diagram here
+\begin{figure}[h]
+ \caption{A binary arithmetic circuit that expresses the linear polynomial: $f=0.4\times(\theta_{f}) + 0.6\times(\theta_{\overline{f}})$}
+ \centering
+ \includegraphics[width=9cm]{ac_example.pdf}
+\end{figure}
+\newpage
+% End Diagram
+
+By traversing the AC from the leaves, we can calculate the output of the polynomial at the root. Furthermore, if we start from the root, we can calculate the marginal probabilities by evaluating the partial derivatives for interior nodes, similar to how backpropation is used to update weights in a neural network. Both of these processes are linear in time with respect to the circuit size [2]. Similarly, the state-of-the-art uses a software implementation of bit-encoding backpropagation, where the original AC is traversed twice in order to find the marginal probabilities. One limitation to using bit-encoding is that it only works for alternating circuits, where every level of interior nodes alternate between addition and multiplication nodes.
+
+% Approach
+\section{Approach}\label{I3}
+We propose a feed-forward approach to finding marginal probabilities. This approach would produce two arithmetic circuits, where the first circuit outputs the result of the polynomial and the second circuit outputs the marginal probability of a variable. By creating an additional circuit, we can perform additional optimizations and construct it in hardware to perform more efficient inferences.
+
+% Diagram here
+\begin{figure}[h]
+ \caption{A high-level model of the proposed feed-forward AC}
+ \centering
+ \includegraphics[width=10cm]{feedforward_example.pdf}
+\end{figure}
+\newpage
+% End Diagram
+
+Since partial derivatives of addition nodes are generally equal to the partial derivatives of the child nodes, we can calculate the partial derivatives by calculating the products of all sibling nodes of a child node, as follows: \newline\centerline{dr(c) = dr(p)$\times$ $\prod\limits_{c \neq c'}^{} vr(c')$ [4]}\newline where dr(c) is the derivative of the child node, dr(p) is the derivative of the parent node, and vr(c') is the value of a sibling node. This naive method requires many more edges than our original AC. As a result, the new AC will be quadratic in size with respect to our original AC using a naive approach.
+
+Like the naive approach, our approach to finding marginal probabilities involves using only the product nodes; however, we do so i in a more efficient manner. We can do this by caching previously computed products and accessing them in future calculations, which is also a memoization technique. By caching the products into a register to calculate partial derivatives, the calculation can be done in linear size with respect to our original AC.
+
+This cache-based algorithm has two significant advantages compared to the bit-encoding algorithm:
+\begin{enumerate}
+\item The partial derivatives can be calculated in linear size, irrespective of the circuit structure. The feed-forward algorithm works correctly for non-alternating circuits, which is a feature absent from bit-encoded backpropagation.
+\item The algorithm can be used to create an external circuit that we can construct in hardware, which will allow us to perform additional optimizations to reduce inference time.
+\end{enumerate}
+
+% Analysis
+\section{Analysis}\label{I4}
+
+We compared the performance of three algorithms, written in C, on three different data sets. For the feed-forward algorithm, we generated a feed-forward arithmetic circuit from the original circuit, and then compiled the circuit back into C code. Then, we measured the CPU time needed to find the marginal probability of one variable from the initialized circuit structures.
+
+
+ \begin{table}[h!]
+ \centering
+ \begin{tabular}{||c c c c ||}
+ \hline
+ \textbf{Test Set} (nodes) & Bit-Encoded (s) & \textbf{Feed-Forward} (s) & Naive (s)\\ %[0.5ex]
+ \hline\hline
+ \textbf{Verysimple.ac} (20) & 0.01994 & \textbf{0.00504} & 0.01921\\
+ \hline
+ \textbf{Voting.ac} (12468) [5] & 2.29930 & \textbf{0.34500} & 6.85860\\
+ \hline
+ \textbf{Movie.ac} (21714) [5] & 0.84004 & \textbf{0.18353} & 1.31189\\ %[1ex]
+ \hline
+\end{tabular}
+\caption{CPU times (in seconds) of 10000 iterations of bit-encoded, feed-forward, and naive algorithms. The values were averaged from 3 trials. }
+\end{table}
+
+The CPU times show that the feed-forward approach is 4 to 5 times faster on simple circuit structures (verysimple.ac and movie.ac) and about 8 times faster for more complex structures (voting.ac) compared to bit-encoded backpropagation. We can attribute the improvement in performance to the simpler output circuit structure of the compiled code, and better performance in the forward passes compared to the backward pass. The feed-forward algorithm was found to give correct results even for non-alternating circuits, which makes this algorithm suitable for a wider range of applications. In addition, it can be represented by a hardware circuit, leading to more energy efficient and faster inferences. We hope to compare the differences between a software and hardware implementation in future work.
+\newpage
+
+% Conclusion
+\section{Conclusion}
+We proposed a new algorithm to find the marginal probabilities in an arithmetic circuit in linear size using a cache-based feed-forward algorithm. We found that calculating the marginal probabilities by compiling the feed-forward circuit significantly reduces inference time. The algorithm can also be used for a wider range of circuits, and it can be implemented in a hardware circuit, potentially using fewer resources.
+
+\mbox{}\\
+
+% Acknowledgements
+\noindent \Large\textbf{Acknowledgements}\\[1mm]
+\normalsize \noindent I would like to thank Prof. Guy Van den Broeck for his brilliant insight and mentorship during this project. I am also grateful to his students in the StarAI Lab for their enlightening discussions during my stay at UCLA. \\[3mm]
+
+\newpage
+
+% References and Citations
+\noindent \Large\textbf{References}\\[1mm]
+\normalsize \noindent
+[1] Cooper, G. F., 1990. The computational complexity of probabilistic inference using Bayesian belief networks. Artif. Intell. 42, pp. 393-405. \newline \newline
+[2] Darwiche, A., 2003. A Differential Approach to Inference in Bayesian Networks. J. ACM 50, pp. 280-305. \newline \newline
+[3] Chavira, M. and Darwiche, A., 2005. Compiling Bayesian networks with local structure. In Proceedings of the 19th International Joint Conference on Artificial Intelligence (IJCAI), pp. 1306–1312. \newline \newline
+[4] Darwiche, A., 2009. Modeling and Reasoning with Bayesian Networks. Cambridge University Press, Chapter 12.\newline \newline
+[5] Bekker, J., Davis, J., Choi, A., Darwiche, A., and Van den Broeck, G., 2015. Tractable Learning for Complex Probability Queries. Advances in Neural Information Processing Systems 28 (NIPS). \newline
+
+\end{document}
+
diff --git a/assets/2017/A.Choi/feedforward_example.pdf b/assets/2017/A.Choi/feedforward_example.pdf
new file mode 100644
index 0000000..0adc727
Binary files /dev/null and b/assets/2017/A.Choi/feedforward_example.pdf differ
diff --git a/assets/2017/A.Choi/feedforward_example.png b/assets/2017/A.Choi/feedforward_example.png
new file mode 100644
index 0000000..865ba01
Binary files /dev/null and b/assets/2017/A.Choi/feedforward_example.png differ
diff --git a/assets/2017/A.Mishkin/group_valuechart.png b/assets/2017/A.Mishkin/group_valuechart.png
new file mode 100644
index 0000000..ce481b9
Binary files /dev/null and b/assets/2017/A.Mishkin/group_valuechart.png differ
diff --git a/assets/2017/A.Mishkin/table.png b/assets/2017/A.Mishkin/table.png
new file mode 100644
index 0000000..2c47486
Binary files /dev/null and b/assets/2017/A.Mishkin/table.png differ
diff --git a/assets/2017/A.Mishkin/valuechart.png b/assets/2017/A.Mishkin/valuechart.png
new file mode 100644
index 0000000..3ec98ef
Binary files /dev/null and b/assets/2017/A.Mishkin/valuechart.png differ
diff --git a/assets/2017/A.Yasodhara/image1.png b/assets/2017/A.Yasodhara/image1.png
new file mode 100644
index 0000000..7412874
Binary files /dev/null and b/assets/2017/A.Yasodhara/image1.png differ
diff --git a/assets/2017/A.Yasodhara/image2.png b/assets/2017/A.Yasodhara/image2.png
new file mode 100644
index 0000000..4221a9e
Binary files /dev/null and b/assets/2017/A.Yasodhara/image2.png differ
diff --git a/assets/2017/A.Yasodhara/image3.png b/assets/2017/A.Yasodhara/image3.png
new file mode 100644
index 0000000..612508c
Binary files /dev/null and b/assets/2017/A.Yasodhara/image3.png differ
diff --git a/assets/2017/A.Yasodhara/image4.png b/assets/2017/A.Yasodhara/image4.png
new file mode 100644
index 0000000..0b17feb
Binary files /dev/null and b/assets/2017/A.Yasodhara/image4.png differ
diff --git a/assets/2017/A.Yasodhara/image5.png b/assets/2017/A.Yasodhara/image5.png
new file mode 100644
index 0000000..5239d14
Binary files /dev/null and b/assets/2017/A.Yasodhara/image5.png differ
diff --git a/assets/2017/C.Herng Yi/2017-03-24-C-Herng-Yi.md b/assets/2017/C.Herng Yi/2017-03-24-C-Herng-Yi.md
new file mode 100644
index 0000000..a32538a
--- /dev/null
+++ b/assets/2017/C.Herng Yi/2017-03-24-C-Herng-Yi.md
@@ -0,0 +1,15 @@
+---
+layout: post
+title: "Solving PDEs on Deconstructed Domains for Geometry Processing"
+author: "Herng Yi Cheng, Mitchell Dembowski, {Silvia Gonz\'alez Sell\'an} and Christine Ma"
+supervisors: "Professor Alec Jacobson"
+category: "Scientific Computer/Numerical Analysis"
+permalink: /solving-pdes-on-deconstructed-domains-for-geometry-processing
+year: "2017"
+
+---
+
+Introduction
+===
+
+The Laplace equation and Possion equation are partial differential equations (PDEs) which arise naturally from analyzing heat flow, Maxwell's equations of electromagnetism, and shape recognition in computer graphics \cite{ShapeRepresentation}. We studied a new way to solve these equations on overlapping triangular mesh domains, in order to smoothen the computer animation of objects that are represented using those meshes. We designed several variants of a divide-and-conquer solution method, and tested them against each other for accuracy.
diff --git a/assets/2017/C.Herng Yi/Bibliography.bib b/assets/2017/C.Herng Yi/Bibliography.bib
new file mode 100644
index 0000000..4b6e6dd
--- /dev/null
+++ b/assets/2017/C.Herng Yi/Bibliography.bib
@@ -0,0 +1,165 @@
+@Inbook{Cai2003,
+author="Cai, X.",
+editor="Langtangen, Hans Petter
+and Tveito, Aslak",
+title="Overlapping Domain Decomposition Methods",
+bookTitle="Advanced Topics in Computational Partial Differential Equations: Numerical Methods and Diffpack Programming",
+year="2003",
+publisher="Springer Berlin Heidelberg",
+address="Berlin, Heidelberg",
+pages="57--95",
+abstract="Overlapping domain decomposition methods are efficient and flexible. It is also important that such methods are inherently suitable for parallel computing. In this chapter, we will first explain the mathematical formulation and algorithmic composition of the overlapping domain decomposition methods. Afterwards, we will focus on a generic implementation framework and its applications within Diffpack.",
+isbn="978-3-642-18237-2",
+doi="10.1007/978-3-642-18237-2_2",
+url="http://dx.doi.org/10.1007/978-3-642-18237-2_2"
+}
+
+@book{nocedal2006numerical,
+ title={Numerical Optimization},
+ author={Nocedal, J. and Wright, S.},
+ isbn={9780387303031},
+ lccn={99013263},
+ series={Springer Series in Operations Research and Financial Engineering},
+ url={https://books.google.es/books?id=eNlPAAAAMAAJ},
+ year={2006},
+ publisher={Springer New York}
+}
+
+
+@article{MinRough,
+title = "Minimal roughness property of the Delaunay triangulation",
+journal = "Computer Aided Geometric Design",
+volume = "7",
+number = "6",
+pages = "489 - 497",
+year = "1990",
+note = "",
+issn = "0167-8396",
+doi = "http://dx.doi.org/10.1016/0167-8396(90)90011-F",
+url = "http://www.sciencedirect.com/science/article/pii/016783969090011F",
+author = "Samuel Rippa",
+keywords = "Triangulations",
+keywords = "Delaunay triangulation."
+}
+
+
+
+@article{RelaxLapHeat,
+ author={Robert J Low},
+ title={Relaxation: from Laplace's equation to the heat equation and discretely back again},
+ journal={European Journal of Physics},
+ volume={36},
+ number={3},
+ pages={035010},
+ url={http://stacks.iop.org/0143-0807/36/i=3/a=035010},
+ year={2015},
+ abstract={We see how the relaxation method for Laplace's equation is related to a numerical solution of the heat equation, which is in turn motivated by thinking of the Hamiltonian as the the time evolution operator in quantum mechanics. This gives some physical insight into what the relaxation method is doing. We also use this to suggest investigative work for a student learning about computational methods in physics.}
+}
+
+@book {RandomWalkHeat,
+ AUTHOR = {Lawler, Gregory F.},
+ TITLE = {Random walk and the heat equation},
+ SERIES = {Student Mathematical Library},
+ VOLUME = {55},
+ PUBLISHER = {American Mathematical Society, Providence, RI},
+ YEAR = {2010},
+ PAGES = {x+156},
+ ISBN = {978-0-8218-4829-6},
+ MRCLASS = {60-01 (28A80 35R60 60G42 60G50 60J65)},
+ MRNUMBER = {2732325},
+MRREVIEWER = {Peter M\"orters},
+ DOI = {10.1090/stml/055},
+ URL = {http://dx.doi.org/10.1090/stml/055},
+}
+
+@book {MarkovStewart,
+ AUTHOR = {Stewart, William J.},
+ TITLE = {Probability, {M}arkov chains, queues, and simulation},
+ NOTE = {The mathematical basis of performance modeling},
+ PUBLISHER = {Princeton University Press, Princeton, NJ},
+ YEAR = {2009},
+ PAGES = {xviii+758},
+ ISBN = {978-0-691-14062-9},
+ MRCLASS = {60-01 (60J10 60K25 65C05 65C10 65C40)},
+ MRNUMBER = {2518195},
+}
+
+
+@book{DomainDecomp,
+title = "Domain decomposition : parallel multilevel methods for elliptic partial differential equations",
+author = "Smith, {Barry F.} and Bjørstad, {Petter E.} and Gropp, {William D.}",
+year = "1996",
+publisher = "Cambridge University Press",
+}
+
+@inproceedings{NoFreeLunch,
+ author = {Wardetzky, Max and Mathur, Saurabh and K\"{a}lberer, Felix and Grinspun, Eitan},
+ title = {Discrete Laplace Operators: No Free Lunch},
+ booktitle = {Proceedings of the Fifth Eurographics Symposium on Geometry Processing},
+ series = {SGP '07},
+ year = {2007},
+ isbn = {978-3-905673-46-3},
+ location = {Barcelona, Spain},
+ pages = {33--37},
+ numpages = {5},
+ url = {http://dl.acm.org/citation.cfm?id=1281991.1281995},
+ acmid = {1281995},
+ publisher = {Eurographics Association},
+ address = {Aire-la-Ville, Switzerland, Switzerland},
+}
+
+@phdthesis{AlecThesis,
+ title = {Algorithms and Interfaces for Real-Time Deformation of 2{D} and 3{D} Shapes},
+ school = {ETH Zurich},
+ author = {Jacobson, Alec},
+ year = {2013},
+}
+
+@book{evans1998partial,
+ title={Partial Differential Equations},
+ author={Evans, L.C.},
+ isbn={9780821807729},
+ lccn={97041033},
+ series={Graduate studies in mathematics},
+ url={https://books.google.ca/books?id=5Pv4LVB\_m8AC},
+ year={1998},
+ publisher={American Mathematical Society}
+}
+
+@book{courant2005dirichlet,
+ title={Dirichlet's Principle, Conformal Mapping, and Minimal Surfaces},
+ author={Courant, R.},
+ isbn={9780486445526},
+ lccn={2005049736},
+ series={Dover books on mathematics},
+ url={https://books.google.ca/books?id=FLr5JDljqY4C},
+ year={2005},
+ publisher={Dover Publications}
+}
+
+@article{IntroFEM,
+ title={A gentle introduction to the Finite Element Method},
+ author={Sayas, Francisco-Javier},
+ journal={University of Delaware},
+ year={2008}
+}
+
+@article{ShapeRepresentation,
+ author = {Gorelick, Lena and Galun, Meirav and Sharon, Eitan and Basri, Ronen and Brandt, Achi},
+ title = {Shape Representation and Classification Using the Poisson Equation},
+ journal = {IEEE Trans. Pattern Anal. Mach. Intell.},
+ issue_date = {December 2006},
+ volume = {28},
+ number = {12},
+ month = dec,
+ year = {2006},
+ issn = {0162-8828},
+ pages = {1991--2005},
+ numpages = {15},
+ url = {http://dx.doi.org/10.1109/TPAMI.2006.253},
+ doi = {10.1109/TPAMI.2006.253},
+ acmid = {1176239},
+ publisher = {IEEE Computer Society},
+ address = {Washington, DC, USA},
+ keywords = {Computer vision, Computer vision, shape, Poisson equation, silhouette classification., Poisson equation, shape, silhouette classification.},
+}
diff --git a/assets/2017/C.Herng Yi/Dirichlet_Sampling_Constraint.jpg b/assets/2017/C.Herng Yi/Dirichlet_Sampling_Constraint.jpg
new file mode 100644
index 0000000..41e869e
Binary files /dev/null and b/assets/2017/C.Herng Yi/Dirichlet_Sampling_Constraint.jpg differ
diff --git a/assets/2017/C.Herng Yi/IEEEtranS.bst b/assets/2017/C.Herng Yi/IEEEtranS.bst
new file mode 100644
index 0000000..b9c2c64
--- /dev/null
+++ b/assets/2017/C.Herng Yi/IEEEtranS.bst
@@ -0,0 +1,2607 @@
+%%
+%% IEEEtranS.bst
+%% BibTeX Bibliography Style file
+%% Sorting version of IEEEtran.bst
+%% *** Not for normal IEEE work ***
+%% Version 1.14 (2015/08/26)
+%%
+%% Copyright (c) 2003-2015 Michael Shell
+%%
+%% Original starting code base and algorithms obtained from the output of
+%% Patrick W. Daly's makebst package as well as from prior versions of
+%% IEEE BibTeX styles:
+%%
+%% 1. Howard Trickey and Oren Patashnik's ieeetr.bst (1985/1988)
+%% 2. Silvano Balemi and Richard H. Roy's IEEEbib.bst (1993)
+%%
+%% Added sorting code is from plain.bst.
+%%
+%% Support sites:
+%% http://www.michaelshell.org/tex/ieeetran/
+%% http://www.ctan.org/pkg/ieeetran
+%% and/or
+%% http://www.ieee.org/
+%%
+%% For use with BibTeX version 0.99a or later
+%%
+%% This is a numerical citation style.
+%%
+%%*************************************************************************
+%% Legal Notice:
+%% This code is offered as-is without any warranty either expressed or
+%% implied; without even the implied warranty of MERCHANTABILITY or
+%% FITNESS FOR A PARTICULAR PURPOSE!
+%% User assumes all risk.
+%% In no event shall the IEEE or any contributor to this code be liable for
+%% any damages or losses, including, but not limited to, incidental,
+%% consequential, or any other damages, resulting from the use or misuse
+%% of any information contained here.
+%%
+%% All comments are the opinions of their respective authors and are not
+%% necessarily endorsed by the IEEE.
+%%
+%% This work is distributed under the LaTeX Project Public License (LPPL)
+%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
+%% distributed and modified. A copy of the LPPL, version 1.3, is included
+%% in the base LaTeX documentation of all distributions of LaTeX released
+%% 2003/12/01 or later.
+%% Retain all contribution notices and credits.
+%% ** Modified files should be clearly indicated as such, including **
+%% ** renaming them and changing author support contact information. **
+%%*************************************************************************
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% DEFAULTS FOR THE CONTROLS OF THE BST STYLE %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% These are the defaults for the user adjustable controls. The values used
+% here can be overridden by the user via IEEEtranBSTCTL entry type.
+
+% NOTE: The recommended LaTeX command to invoke a control entry type is:
+%
+%\makeatletter
+%\def\bstctlcite{\@ifnextchar[{\@bstctlcite}{\@bstctlcite[@auxout]}}
+%\def\@bstctlcite[#1]#2{\@bsphack
+% \@for\@citeb:=#2\do{%
+% \edef\@citeb{\expandafter\@firstofone\@citeb}%
+% \if@filesw\immediate\write\csname #1\endcsname{\string\citation{\@citeb}}\fi}%
+% \@esphack}
+%\makeatother
+%
+% It is called at the start of the document, before the first \cite, like:
+% \bstctlcite{IEEEexample:BSTcontrol}
+%
+% IEEEtran.cls V1.6 and later does provide this command.
+
+
+
+% #0 turns off the display of the number for articles.
+% #1 enables
+FUNCTION {default.is.use.number.for.article} { #1 }
+
+
+% #0 turns off the display of the paper and type fields in @inproceedings.
+% #1 enables
+FUNCTION {default.is.use.paper} { #1 }
+
+
+% #0 turns off the display of urls
+% #1 enables
+FUNCTION {default.is.use.url} { #1 }
+
+
+% #0 turns off the forced use of "et al."
+% #1 enables
+FUNCTION {default.is.forced.et.al} { #0 }
+
+
+% The maximum number of names that can be present beyond which an "et al."
+% usage is forced. Be sure that num.names.shown.with.forced.et.al (below)
+% is not greater than this value!
+% Note: There are many instances of references in IEEE journals which have
+% a very large number of authors as well as instances in which "et al." is
+% used profusely.
+FUNCTION {default.max.num.names.before.forced.et.al} { #10 }
+
+
+% The number of names that will be shown with a forced "et al.".
+% Must be less than or equal to max.num.names.before.forced.et.al
+FUNCTION {default.num.names.shown.with.forced.et.al} { #1 }
+
+
+% #0 turns off the alternate interword spacing for entries with URLs.
+% #1 enables
+FUNCTION {default.is.use.alt.interword.spacing} { #1 }
+
+
+% If alternate interword spacing for entries with URLs is enabled, this is
+% the interword spacing stretch factor that will be used. For example, the
+% default "4" here means that the interword spacing in entries with URLs can
+% stretch to four times normal. Does not have to be an integer. Note that
+% the value specified here can be overridden by the user in their LaTeX
+% code via a command such as:
+% "\providecommand\BIBentryALTinterwordstretchfactor{1.5}" in addition to
+% that via the IEEEtranBSTCTL entry type.
+FUNCTION {default.ALTinterwordstretchfactor} { "4" }
+
+
+% #0 turns off the "dashification" of repeated (i.e., identical to those
+% of the previous entry) names. The IEEE normally does this.
+% #1 enables
+FUNCTION {default.is.dash.repeated.names} { #1 }
+
+
+% The default name format control string.
+FUNCTION {default.name.format.string}{ "{f.~}{vv~}{ll}{, jj}" }
+
+
+% The default LaTeX font command for the names.
+FUNCTION {default.name.latex.cmd}{ "" }
+
+
+% The default URL prefix.
+FUNCTION {default.name.url.prefix}{ "[Online]. Available:" }
+
+
+% Other controls that cannot be accessed via IEEEtranBSTCTL entry type.
+
+% #0 turns off the terminal startup banner/completed message so as to
+% operate more quietly.
+% #1 enables
+FUNCTION {is.print.banners.to.terminal} { #1 }
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% FILE VERSION AND BANNER %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+FUNCTION{bst.file.version} { "1.14" }
+FUNCTION{bst.file.date} { "2015/08/26" }
+FUNCTION{bst.file.website} { "http://www.michaelshell.org/tex/ieeetran/bibtex/" }
+
+FUNCTION {banner.message}
+{ is.print.banners.to.terminal
+ { "-- IEEEtranS.bst version" " " * bst.file.version *
+ " (" * bst.file.date * ") " * "by Michael Shell." *
+ top$
+ "-- " bst.file.website *
+ top$
+ "-- See the " quote$ * "IEEEtran_bst_HOWTO.pdf" * quote$ * " manual for usage information." *
+ top$
+ "** Sorting version - not for normal IEEE work."
+ top$
+ }
+ { skip$ }
+ if$
+}
+
+FUNCTION {completed.message}
+{ is.print.banners.to.terminal
+ { ""
+ top$
+ "Done."
+ top$
+ }
+ { skip$ }
+ if$
+}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%
+%% STRING CONSTANTS %%
+%%%%%%%%%%%%%%%%%%%%%%
+FUNCTION {bbl.a}{ "A" }
+FUNCTION {bbl.an}{ "An" }
+FUNCTION {bbl.and}{ "and" }
+FUNCTION {bbl.etal}{ "et~al." }
+FUNCTION {bbl.editors}{ "eds." }
+FUNCTION {bbl.editor}{ "ed." }
+FUNCTION {bbl.edition}{ "ed." }
+FUNCTION {bbl.volume}{ "vol." }
+FUNCTION {bbl.of}{ "of" }
+FUNCTION {bbl.number}{ "no." }
+FUNCTION {bbl.in}{ "in" }
+FUNCTION {bbl.pages}{ "pp." }
+FUNCTION {bbl.page}{ "p." }
+FUNCTION {bbl.chapter}{ "ch." }
+FUNCTION {bbl.paper}{ "paper" }
+FUNCTION {bbl.part}{ "pt." }
+FUNCTION {bbl.patent}{ "Patent" }
+FUNCTION {bbl.patentUS}{ "U.S." }
+FUNCTION {bbl.revision}{ "Rev." }
+FUNCTION {bbl.series}{ "ser." }
+FUNCTION {bbl.standard}{ "Std." }
+FUNCTION {bbl.techrep}{ "Tech. Rep." }
+FUNCTION {bbl.the}{ "The" }
+FUNCTION {bbl.mthesis}{ "Master's thesis" }
+FUNCTION {bbl.phdthesis}{ "Ph.D. dissertation" }
+FUNCTION {bbl.st}{ "st" }
+FUNCTION {bbl.nd}{ "nd" }
+FUNCTION {bbl.rd}{ "rd" }
+FUNCTION {bbl.th}{ "th" }
+
+
+% This is the LaTeX spacer that is used when a larger than normal space
+% is called for (such as just before the address:publisher).
+FUNCTION {large.space} { "\hskip 1em plus 0.5em minus 0.4em\relax " }
+
+% The LaTeX code for dashes that are used to represent repeated names.
+% Note: Some older IEEE journals used something like
+% "\rule{0.275in}{0.5pt}\," which is fairly thick and runs right along
+% the baseline. However, the IEEE now uses a thinner, above baseline,
+% six dash long sequence.
+FUNCTION {repeated.name.dashes} { "------" }
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% PREDEFINED STRING MACROS %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+MACRO {jan} {"Jan."}
+MACRO {feb} {"Feb."}
+MACRO {mar} {"Mar."}
+MACRO {apr} {"Apr."}
+MACRO {may} {"May"}
+MACRO {jun} {"Jun."}
+MACRO {jul} {"Jul."}
+MACRO {aug} {"Aug."}
+MACRO {sep} {"Sep."}
+MACRO {oct} {"Oct."}
+MACRO {nov} {"Nov."}
+MACRO {dec} {"Dec."}
+
+
+
+%%%%%%%%%%%%%%%%%%
+%% ENTRY FIELDS %%
+%%%%%%%%%%%%%%%%%%
+
+ENTRY
+ { address
+ assignee
+ author
+ booktitle
+ chapter
+ day
+ dayfiled
+ edition
+ editor
+ howpublished
+ institution
+ intype
+ journal
+ key
+ language
+ month
+ monthfiled
+ nationality
+ note
+ number
+ organization
+ pages
+ paper
+ publisher
+ school
+ series
+ revision
+ title
+ type
+ url
+ volume
+ year
+ yearfiled
+ CTLuse_article_number
+ CTLuse_paper
+ CTLuse_url
+ CTLuse_forced_etal
+ CTLmax_names_forced_etal
+ CTLnames_show_etal
+ CTLuse_alt_spacing
+ CTLalt_stretch_factor
+ CTLdash_repeated_names
+ CTLname_format_string
+ CTLname_latex_cmd
+ CTLname_url_prefix
+ }
+ {}
+ { label }
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%
+%% INTEGER VARIABLES %%
+%%%%%%%%%%%%%%%%%%%%%%%
+
+INTEGERS { prev.status.punct this.status.punct punct.std
+ punct.no punct.comma punct.period
+ prev.status.space this.status.space space.std
+ space.no space.normal space.large
+ prev.status.quote this.status.quote quote.std
+ quote.no quote.close
+ prev.status.nline this.status.nline nline.std
+ nline.no nline.newblock
+ status.cap cap.std
+ cap.no cap.yes}
+
+INTEGERS { longest.label.width multiresult nameptr namesleft number.label numnames }
+
+INTEGERS { is.use.number.for.article
+ is.use.paper
+ is.use.url
+ is.forced.et.al
+ max.num.names.before.forced.et.al
+ num.names.shown.with.forced.et.al
+ is.use.alt.interword.spacing
+ is.dash.repeated.names}
+
+
+%%%%%%%%%%%%%%%%%%%%%%
+%% STRING VARIABLES %%
+%%%%%%%%%%%%%%%%%%%%%%
+
+STRINGS { bibinfo
+ longest.label
+ oldname
+ s
+ t
+ ALTinterwordstretchfactor
+ name.format.string
+ name.latex.cmd
+ name.url.prefix}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%
+%% LOW LEVEL FUNCTIONS %%
+%%%%%%%%%%%%%%%%%%%%%%%%%
+
+FUNCTION {initialize.controls}
+{ default.is.use.number.for.article 'is.use.number.for.article :=
+ default.is.use.paper 'is.use.paper :=
+ default.is.use.url 'is.use.url :=
+ default.is.forced.et.al 'is.forced.et.al :=
+ default.max.num.names.before.forced.et.al 'max.num.names.before.forced.et.al :=
+ default.num.names.shown.with.forced.et.al 'num.names.shown.with.forced.et.al :=
+ default.is.use.alt.interword.spacing 'is.use.alt.interword.spacing :=
+ default.is.dash.repeated.names 'is.dash.repeated.names :=
+ default.ALTinterwordstretchfactor 'ALTinterwordstretchfactor :=
+ default.name.format.string 'name.format.string :=
+ default.name.latex.cmd 'name.latex.cmd :=
+ default.name.url.prefix 'name.url.prefix :=
+}
+
+
+% This IEEEtran.bst features a very powerful and flexible mechanism for
+% controlling the capitalization, punctuation, spacing, quotation, and
+% newlines of the formatted entry fields. (Note: IEEEtran.bst does not need
+% or use the newline/newblock feature, but it has been implemented for
+% possible future use.) The output states of IEEEtran.bst consist of
+% multiple independent attributes and, as such, can be thought of as being
+% vectors, rather than the simple scalar values ("before.all",
+% "mid.sentence", etc.) used in most other .bst files.
+%
+% The more flexible and complex design used here was motivated in part by
+% the IEEE's rather unusual bibliography style. For example, the IEEE ends the
+% previous field item with a period and large space prior to the publisher
+% address; the @electronic entry types use periods as inter-item punctuation
+% rather than the commas used by the other entry types; and URLs are never
+% followed by periods even though they are the last item in the entry.
+% Although it is possible to accommodate these features with the conventional
+% output state system, the seemingly endless exceptions make for convoluted,
+% unreliable and difficult to maintain code.
+%
+% IEEEtran.bst's output state system can be easily understood via a simple
+% illustration of two most recently formatted entry fields (on the stack):
+%
+% CURRENT_ITEM
+% "PREVIOUS_ITEM
+%
+% which, in this example, is to eventually appear in the bibliography as:
+%
+% "PREVIOUS_ITEM," CURRENT_ITEM
+%
+% It is the job of the output routine to take the previous item off of the
+% stack (while leaving the current item at the top of the stack), apply its
+% trailing punctuation (including closing quote marks) and spacing, and then
+% to write the result to BibTeX's output buffer:
+%
+% "PREVIOUS_ITEM,"
+%
+% Punctuation (and spacing) between items is often determined by both of the
+% items rather than just the first one. The presence of quotation marks
+% further complicates the situation because, in standard English, trailing
+% punctuation marks are supposed to be contained within the quotes.
+%
+% IEEEtran.bst maintains two output state (aka "status") vectors which
+% correspond to the previous and current (aka "this") items. Each vector
+% consists of several independent attributes which track punctuation,
+% spacing, quotation, and newlines. Capitalization status is handled by a
+% separate scalar because the format routines, not the output routine,
+% handle capitalization and, therefore, there is no need to maintain the
+% capitalization attribute for both the "previous" and "this" items.
+%
+% When a format routine adds a new item, it copies the current output status
+% vector to the previous output status vector and (usually) resets the
+% current (this) output status vector to a "standard status" vector. Using a
+% "standard status" vector in this way allows us to redefine what we mean by
+% "standard status" at the start of each entry handler and reuse the same
+% format routines under the various inter-item separation schemes. For
+% example, the standard status vector for the @book entry type may use
+% commas for item separators, while the @electronic type may use periods,
+% yet both entry handlers exploit many of the exact same format routines.
+%
+% Because format routines have write access to the output status vector of
+% the previous item, they can override the punctuation choices of the
+% previous format routine! Therefore, it becomes trivial to implement rules
+% such as "Always use a period and a large space before the publisher." By
+% pushing the generation of the closing quote mark to the output routine, we
+% avoid all the problems caused by having to close a quote before having all
+% the information required to determine what the punctuation should be.
+%
+% The IEEEtran.bst output state system can easily be expanded if needed.
+% For instance, it is easy to add a "space.tie" attribute value if the
+% bibliography rules mandate that two items have to be joined with an
+% unbreakable space.
+
+FUNCTION {initialize.status.constants}
+{ #0 'punct.no :=
+ #1 'punct.comma :=
+ #2 'punct.period :=
+ #0 'space.no :=
+ #1 'space.normal :=
+ #2 'space.large :=
+ #0 'quote.no :=
+ #1 'quote.close :=
+ #0 'cap.no :=
+ #1 'cap.yes :=
+ #0 'nline.no :=
+ #1 'nline.newblock :=
+}
+
+FUNCTION {std.status.using.comma}
+{ punct.comma 'punct.std :=
+ space.normal 'space.std :=
+ quote.no 'quote.std :=
+ nline.no 'nline.std :=
+ cap.no 'cap.std :=
+}
+
+FUNCTION {std.status.using.period}
+{ punct.period 'punct.std :=
+ space.normal 'space.std :=
+ quote.no 'quote.std :=
+ nline.no 'nline.std :=
+ cap.yes 'cap.std :=
+}
+
+FUNCTION {initialize.prev.this.status}
+{ punct.no 'prev.status.punct :=
+ space.no 'prev.status.space :=
+ quote.no 'prev.status.quote :=
+ nline.no 'prev.status.nline :=
+ punct.no 'this.status.punct :=
+ space.no 'this.status.space :=
+ quote.no 'this.status.quote :=
+ nline.no 'this.status.nline :=
+ cap.yes 'status.cap :=
+}
+
+FUNCTION {this.status.std}
+{ punct.std 'this.status.punct :=
+ space.std 'this.status.space :=
+ quote.std 'this.status.quote :=
+ nline.std 'this.status.nline :=
+}
+
+FUNCTION {cap.status.std}{ cap.std 'status.cap := }
+
+FUNCTION {this.to.prev.status}
+{ this.status.punct 'prev.status.punct :=
+ this.status.space 'prev.status.space :=
+ this.status.quote 'prev.status.quote :=
+ this.status.nline 'prev.status.nline :=
+}
+
+
+FUNCTION {not}
+{ { #0 }
+ { #1 }
+ if$
+}
+
+FUNCTION {and}
+{ { skip$ }
+ { pop$ #0 }
+ if$
+}
+
+FUNCTION {or}
+{ { pop$ #1 }
+ { skip$ }
+ if$
+}
+
+
+% convert the strings "yes" or "no" to #1 or #0 respectively
+FUNCTION {yes.no.to.int}
+{ "l" change.case$ duplicate$
+ "yes" =
+ { pop$ #1 }
+ { duplicate$ "no" =
+ { pop$ #0 }
+ { "unknown boolean " quote$ * swap$ * quote$ *
+ " in " * cite$ * warning$
+ #0
+ }
+ if$
+ }
+ if$
+}
+
+
+% pushes true if the single char string on the stack is in the
+% range of "0" to "9"
+FUNCTION {is.num}
+{ chr.to.int$
+ duplicate$ "0" chr.to.int$ < not
+ swap$ "9" chr.to.int$ > not and
+}
+
+% multiplies the integer on the stack by a factor of 10
+FUNCTION {bump.int.mag}
+{ #0 'multiresult :=
+ { duplicate$ #0 > }
+ { #1 -
+ multiresult #10 +
+ 'multiresult :=
+ }
+ while$
+pop$
+multiresult
+}
+
+% converts a single character string on the stack to an integer
+FUNCTION {char.to.integer}
+{ duplicate$
+ is.num
+ { chr.to.int$ "0" chr.to.int$ - }
+ {"noninteger character " quote$ * swap$ * quote$ *
+ " in integer field of " * cite$ * warning$
+ #0
+ }
+ if$
+}
+
+% converts a string on the stack to an integer
+FUNCTION {string.to.integer}
+{ duplicate$ text.length$ 'namesleft :=
+ #1 'nameptr :=
+ #0 'numnames :=
+ { nameptr namesleft > not }
+ { duplicate$ nameptr #1 substring$
+ char.to.integer numnames bump.int.mag +
+ 'numnames :=
+ nameptr #1 +
+ 'nameptr :=
+ }
+ while$
+pop$
+numnames
+}
+
+
+
+
+% The output routines write out the *next* to the top (previous) item on the
+% stack, adding punctuation and such as needed. Since IEEEtran.bst maintains
+% the output status for the top two items on the stack, these output
+% routines have to consider the previous output status (which corresponds to
+% the item that is being output). Full independent control of punctuation,
+% closing quote marks, spacing, and newblock is provided.
+%
+% "output.nonnull" does not check for the presence of a previous empty
+% item.
+%
+% "output" does check for the presence of a previous empty item and will
+% remove an empty item rather than outputing it.
+%
+% "output.warn" is like "output", but will issue a warning if it detects
+% an empty item.
+
+FUNCTION {output.nonnull}
+{ swap$
+ prev.status.punct punct.comma =
+ { "," * }
+ { skip$ }
+ if$
+ prev.status.punct punct.period =
+ { add.period$ }
+ { skip$ }
+ if$
+ prev.status.quote quote.close =
+ { "''" * }
+ { skip$ }
+ if$
+ prev.status.space space.normal =
+ { " " * }
+ { skip$ }
+ if$
+ prev.status.space space.large =
+ { large.space * }
+ { skip$ }
+ if$
+ write$
+ prev.status.nline nline.newblock =
+ { newline$ "\newblock " write$ }
+ { skip$ }
+ if$
+}
+
+FUNCTION {output}
+{ duplicate$ empty$
+ 'pop$
+ 'output.nonnull
+ if$
+}
+
+FUNCTION {output.warn}
+{ 't :=
+ duplicate$ empty$
+ { pop$ "empty " t * " in " * cite$ * warning$ }
+ 'output.nonnull
+ if$
+}
+
+% "fin.entry" is the output routine that handles the last item of the entry
+% (which will be on the top of the stack when "fin.entry" is called).
+
+FUNCTION {fin.entry}
+{ this.status.punct punct.no =
+ { skip$ }
+ { add.period$ }
+ if$
+ this.status.quote quote.close =
+ { "''" * }
+ { skip$ }
+ if$
+write$
+newline$
+}
+
+
+FUNCTION {is.last.char.not.punct}
+{ duplicate$
+ "}" * add.period$
+ #-1 #1 substring$ "." =
+}
+
+FUNCTION {is.multiple.pages}
+{ 't :=
+ #0 'multiresult :=
+ { multiresult not
+ t empty$ not
+ and
+ }
+ { t #1 #1 substring$
+ duplicate$ "-" =
+ swap$ duplicate$ "," =
+ swap$ "+" =
+ or or
+ { #1 'multiresult := }
+ { t #2 global.max$ substring$ 't := }
+ if$
+ }
+ while$
+ multiresult
+}
+
+FUNCTION {capitalize}{ "u" change.case$ "t" change.case$ }
+
+FUNCTION {emphasize}
+{ duplicate$ empty$
+ { pop$ "" }
+ { "\emph{" swap$ * "}" * }
+ if$
+}
+
+FUNCTION {do.name.latex.cmd}
+{ name.latex.cmd
+ empty$
+ { skip$ }
+ { name.latex.cmd "{" * swap$ * "}" * }
+ if$
+}
+
+% IEEEtran.bst uses its own \BIBforeignlanguage command which directly
+% invokes the TeX hyphenation patterns without the need of the Babel
+% package. Babel does a lot more than switch hyphenation patterns and
+% its loading can cause unintended effects in many class files (such as
+% IEEEtran.cls).
+FUNCTION {select.language}
+{ duplicate$ empty$ 'pop$
+ { language empty$ 'skip$
+ { "\BIBforeignlanguage{" language * "}{" * swap$ * "}" * }
+ if$
+ }
+ if$
+}
+
+FUNCTION {tie.or.space.prefix}
+{ duplicate$ text.length$ #3 <
+ { "~" }
+ { " " }
+ if$
+ swap$
+}
+
+FUNCTION {get.bbl.editor}
+{ editor num.names$ #1 > 'bbl.editors 'bbl.editor if$ }
+
+FUNCTION {space.word}{ " " swap$ * " " * }
+
+
+% Field Conditioners, Converters, Checkers and External Interfaces
+
+FUNCTION {empty.field.to.null.string}
+{ duplicate$ empty$
+ { pop$ "" }
+ { skip$ }
+ if$
+}
+
+FUNCTION {either.or.check}
+{ empty$
+ { pop$ }
+ { "can't use both " swap$ * " fields in " * cite$ * warning$ }
+ if$
+}
+
+FUNCTION {empty.entry.warn}
+{ author empty$ title empty$ howpublished empty$
+ month empty$ year empty$ note empty$ url empty$
+ and and and and and and
+ { "all relevant fields are empty in " cite$ * warning$ }
+ 'skip$
+ if$
+}
+
+
+% The bibinfo system provides a way for the electronic parsing/acquisition
+% of a bibliography's contents as is done by ReVTeX. For example, a field
+% could be entered into the bibliography as:
+% \bibinfo{volume}{2}
+% Only the "2" would show up in the document, but the LaTeX \bibinfo command
+% could do additional things with the information. IEEEtran.bst does provide
+% a \bibinfo command via "\providecommand{\bibinfo}[2]{#2}". However, it is
+% currently not used as the bogus bibinfo functions defined here output the
+% entry values directly without the \bibinfo wrapper. The bibinfo functions
+% themselves (and the calls to them) are retained for possible future use.
+%
+% bibinfo.check avoids acting on missing fields while bibinfo.warn will
+% issue a warning message if a missing field is detected. Prior to calling
+% the bibinfo functions, the user should push the field value and then its
+% name string, in that order.
+
+FUNCTION {bibinfo.check}
+{ swap$ duplicate$ missing$
+ { pop$ pop$ "" }
+ { duplicate$ empty$
+ { swap$ pop$ }
+ { swap$ pop$ }
+ if$
+ }
+ if$
+}
+
+FUNCTION {bibinfo.warn}
+{ swap$ duplicate$ missing$
+ { swap$ "missing " swap$ * " in " * cite$ * warning$ pop$ "" }
+ { duplicate$ empty$
+ { swap$ "empty " swap$ * " in " * cite$ * warning$ }
+ { swap$ pop$ }
+ if$
+ }
+ if$
+}
+
+
+% The IEEE separates large numbers with more than 4 digits into groups of
+% three. The IEEE uses a small space to separate these number groups.
+% Typical applications include patent and page numbers.
+
+% number of consecutive digits required to trigger the group separation.
+FUNCTION {large.number.trigger}{ #5 }
+
+% For numbers longer than the trigger, this is the blocksize of the groups.
+% The blocksize must be less than the trigger threshold, and 2 * blocksize
+% must be greater than the trigger threshold (can't do more than one
+% separation on the initial trigger).
+FUNCTION {large.number.blocksize}{ #3 }
+
+% What is actually inserted between the number groups.
+FUNCTION {large.number.separator}{ "\," }
+
+% So as to save on integer variables by reusing existing ones, numnames
+% holds the current number of consecutive digits read and nameptr holds
+% the number that will trigger an inserted space.
+FUNCTION {large.number.separate}
+{ 't :=
+ ""
+ #0 'numnames :=
+ large.number.trigger 'nameptr :=
+ { t empty$ not }
+ { t #-1 #1 substring$ is.num
+ { numnames #1 + 'numnames := }
+ { #0 'numnames :=
+ large.number.trigger 'nameptr :=
+ }
+ if$
+ t #-1 #1 substring$ swap$ *
+ t #-2 global.max$ substring$ 't :=
+ numnames nameptr =
+ { duplicate$ #1 nameptr large.number.blocksize - substring$ swap$
+ nameptr large.number.blocksize - #1 + global.max$ substring$
+ large.number.separator swap$ * *
+ nameptr large.number.blocksize - 'numnames :=
+ large.number.blocksize #1 + 'nameptr :=
+ }
+ { skip$ }
+ if$
+ }
+ while$
+}
+
+% Converts all single dashes "-" to double dashes "--".
+FUNCTION {n.dashify}
+{ large.number.separate
+ 't :=
+ ""
+ { t empty$ not }
+ { t #1 #1 substring$ "-" =
+ { t #1 #2 substring$ "--" = not
+ { "--" *
+ t #2 global.max$ substring$ 't :=
+ }
+ { { t #1 #1 substring$ "-" = }
+ { "-" *
+ t #2 global.max$ substring$ 't :=
+ }
+ while$
+ }
+ if$
+ }
+ { t #1 #1 substring$ *
+ t #2 global.max$ substring$ 't :=
+ }
+ if$
+ }
+ while$
+}
+
+
+% This function detects entries with names that are identical to that of
+% the previous entry and replaces the repeated names with dashes (if the
+% "is.dash.repeated.names" user control is nonzero).
+FUNCTION {name.or.dash}
+{ 's :=
+ oldname empty$
+ { s 'oldname := s }
+ { s oldname =
+ { is.dash.repeated.names
+ { repeated.name.dashes }
+ { s 'oldname := s }
+ if$
+ }
+ { s 'oldname := s }
+ if$
+ }
+ if$
+}
+
+% Converts the number string on the top of the stack to
+% "numerical ordinal form" (e.g., "7" to "7th"). There is
+% no artificial limit to the upper bound of the numbers as the
+% two least significant digits determine the ordinal form.
+FUNCTION {num.to.ordinal}
+{ duplicate$ #-2 #1 substring$ "1" =
+ { bbl.th * }
+ { duplicate$ #-1 #1 substring$ "1" =
+ { bbl.st * }
+ { duplicate$ #-1 #1 substring$ "2" =
+ { bbl.nd * }
+ { duplicate$ #-1 #1 substring$ "3" =
+ { bbl.rd * }
+ { bbl.th * }
+ if$
+ }
+ if$
+ }
+ if$
+ }
+ if$
+}
+
+% If the string on the top of the stack begins with a number,
+% (e.g., 11th) then replace the string with the leading number
+% it contains. Otherwise retain the string as-is. s holds the
+% extracted number, t holds the part of the string that remains
+% to be scanned.
+FUNCTION {extract.num}
+{ duplicate$ 't :=
+ "" 's :=
+ { t empty$ not }
+ { t #1 #1 substring$
+ t #2 global.max$ substring$ 't :=
+ duplicate$ is.num
+ { s swap$ * 's := }
+ { pop$ "" 't := }
+ if$
+ }
+ while$
+ s empty$
+ 'skip$
+ { pop$ s }
+ if$
+}
+
+% Converts the word number string on the top of the stack to
+% Arabic string form. Will be successful up to "tenth".
+FUNCTION {word.to.num}
+{ duplicate$ "l" change.case$ 's :=
+ s "first" =
+ { pop$ "1" }
+ { skip$ }
+ if$
+ s "second" =
+ { pop$ "2" }
+ { skip$ }
+ if$
+ s "third" =
+ { pop$ "3" }
+ { skip$ }
+ if$
+ s "fourth" =
+ { pop$ "4" }
+ { skip$ }
+ if$
+ s "fifth" =
+ { pop$ "5" }
+ { skip$ }
+ if$
+ s "sixth" =
+ { pop$ "6" }
+ { skip$ }
+ if$
+ s "seventh" =
+ { pop$ "7" }
+ { skip$ }
+ if$
+ s "eighth" =
+ { pop$ "8" }
+ { skip$ }
+ if$
+ s "ninth" =
+ { pop$ "9" }
+ { skip$ }
+ if$
+ s "tenth" =
+ { pop$ "10" }
+ { skip$ }
+ if$
+}
+
+
+% Converts the string on the top of the stack to numerical
+% ordinal (e.g., "11th") form.
+FUNCTION {convert.edition}
+{ duplicate$ empty$ 'skip$
+ { duplicate$ #1 #1 substring$ is.num
+ { extract.num
+ num.to.ordinal
+ }
+ { word.to.num
+ duplicate$ #1 #1 substring$ is.num
+ { num.to.ordinal }
+ { "edition ordinal word " quote$ * edition * quote$ *
+ " may be too high (or improper) for conversion" * " in " * cite$ * warning$
+ }
+ if$
+ }
+ if$
+ }
+ if$
+}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%% LATEX BIBLIOGRAPHY CODE %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+FUNCTION {start.entry}
+{ newline$
+ "\bibitem{" write$
+ cite$ write$
+ "}" write$
+ newline$
+ ""
+ initialize.prev.this.status
+}
+
+% Here we write out all the LaTeX code that we will need. The most involved
+% code sequences are those that control the alternate interword spacing and
+% foreign language hyphenation patterns. The heavy use of \providecommand
+% gives users a way to override the defaults. Special thanks to Javier Bezos,
+% Johannes Braams, Robin Fairbairns, Heiko Oberdiek, Donald Arseneau and all
+% the other gurus on comp.text.tex for their help and advice on the topic of
+% \selectlanguage, Babel and BibTeX.
+FUNCTION {begin.bib}
+{ "% Generated by IEEEtranS.bst, version: " bst.file.version * " (" * bst.file.date * ")" *
+ write$ newline$
+ preamble$ empty$ 'skip$
+ { preamble$ write$ newline$ }
+ if$
+ "\begin{thebibliography}{" longest.label * "}" *
+ write$ newline$
+ "\providecommand{\url}[1]{#1}"
+ write$ newline$
+ "\csname url@samestyle\endcsname"
+ write$ newline$
+ "\providecommand{\newblock}{\relax}"
+ write$ newline$
+ "\providecommand{\bibinfo}[2]{#2}"
+ write$ newline$
+ "\providecommand{\BIBentrySTDinterwordspacing}{\spaceskip=0pt\relax}"
+ write$ newline$
+ "\providecommand{\BIBentryALTinterwordstretchfactor}{"
+ ALTinterwordstretchfactor * "}" *
+ write$ newline$
+ "\providecommand{\BIBentryALTinterwordspacing}{\spaceskip=\fontdimen2\font plus "
+ write$ newline$
+ "\BIBentryALTinterwordstretchfactor\fontdimen3\font minus \fontdimen4\font\relax}"
+ write$ newline$
+ "\providecommand{\BIBforeignlanguage}[2]{{%"
+ write$ newline$
+ "\expandafter\ifx\csname l@#1\endcsname\relax"
+ write$ newline$
+ "\typeout{** WARNING: IEEEtranS.bst: No hyphenation pattern has been}%"
+ write$ newline$
+ "\typeout{** loaded for the language `#1'. Using the pattern for}%"
+ write$ newline$
+ "\typeout{** the default language instead.}%"
+ write$ newline$
+ "\else"
+ write$ newline$
+ "\language=\csname l@#1\endcsname"
+ write$ newline$
+ "\fi"
+ write$ newline$
+ "#2}}"
+ write$ newline$
+ "\providecommand{\BIBdecl}{\relax}"
+ write$ newline$
+ "\BIBdecl"
+ write$ newline$
+}
+
+FUNCTION {end.bib}
+{ newline$ "\end{thebibliography}" write$ newline$ }
+
+FUNCTION {if.url.alt.interword.spacing}
+{ is.use.alt.interword.spacing
+ { is.use.url
+ { url empty$ 'skip$ {"\BIBentryALTinterwordspacing" write$ newline$} if$ }
+ { skip$ }
+ if$
+ }
+ { skip$ }
+ if$
+}
+
+FUNCTION {if.url.std.interword.spacing}
+{ is.use.alt.interword.spacing
+ { is.use.url
+ { url empty$ 'skip$ {"\BIBentrySTDinterwordspacing" write$ newline$} if$ }
+ { skip$ }
+ if$
+ }
+ { skip$ }
+ if$
+}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%
+%% LONGEST LABEL PASS %%
+%%%%%%%%%%%%%%%%%%%%%%%%
+
+FUNCTION {initialize.longest.label}
+{ "" 'longest.label :=
+ #1 'number.label :=
+ #0 'longest.label.width :=
+}
+
+FUNCTION {longest.label.pass}
+{ type$ "ieeetranbstctl" =
+ { skip$ }
+ { number.label int.to.str$ 'label :=
+ number.label #1 + 'number.label :=
+ label width$ longest.label.width >
+ { label 'longest.label :=
+ label width$ 'longest.label.width :=
+ }
+ { skip$ }
+ if$
+ }
+ if$
+}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%%
+%% FORMAT HANDLERS %%
+%%%%%%%%%%%%%%%%%%%%%
+
+%% Lower Level Formats (used by higher level formats)
+
+FUNCTION {format.address.org.or.pub.date}
+{ 't :=
+ ""
+ year empty$
+ { "empty year in " cite$ * warning$ }
+ { skip$ }
+ if$
+ address empty$ t empty$ and
+ year empty$ and month empty$ and
+ { skip$ }
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ address "address" bibinfo.check *
+ t empty$
+ { skip$ }
+ { punct.period 'prev.status.punct :=
+ space.large 'prev.status.space :=
+ address empty$
+ { skip$ }
+ { ": " * }
+ if$
+ t *
+ }
+ if$
+ year empty$ month empty$ and
+ { skip$ }
+ { t empty$ address empty$ and
+ { skip$ }
+ { ", " * }
+ if$
+ month empty$
+ { year empty$
+ { skip$ }
+ { year "year" bibinfo.check * }
+ if$
+ }
+ { month "month" bibinfo.check *
+ year empty$
+ { skip$ }
+ { " " * year "year" bibinfo.check * }
+ if$
+ }
+ if$
+ }
+ if$
+ }
+ if$
+}
+
+
+FUNCTION {format.names}
+{ 'bibinfo :=
+ duplicate$ empty$ 'skip$ {
+ this.to.prev.status
+ this.status.std
+ 's :=
+ "" 't :=
+ #1 'nameptr :=
+ s num.names$ 'numnames :=
+ numnames 'namesleft :=
+ { namesleft #0 > }
+ { s nameptr
+ name.format.string
+ format.name$
+ bibinfo bibinfo.check
+ 't :=
+ nameptr #1 >
+ { nameptr num.names.shown.with.forced.et.al #1 + =
+ numnames max.num.names.before.forced.et.al >
+ is.forced.et.al and and
+ { "others" 't :=
+ #1 'namesleft :=
+ }
+ { skip$ }
+ if$
+ namesleft #1 >
+ { ", " * t do.name.latex.cmd * }
+ { s nameptr "{ll}" format.name$ duplicate$ "others" =
+ { 't := }
+ { pop$ }
+ if$
+ t "others" =
+ { " " * bbl.etal emphasize * }
+ { numnames #2 >
+ { "," * }
+ { skip$ }
+ if$
+ bbl.and
+ space.word * t do.name.latex.cmd *
+ }
+ if$
+ }
+ if$
+ }
+ { t do.name.latex.cmd }
+ if$
+ nameptr #1 + 'nameptr :=
+ namesleft #1 - 'namesleft :=
+ }
+ while$
+ cap.status.std
+ } if$
+}
+
+
+
+
+%% Higher Level Formats
+
+%% addresses/locations
+
+FUNCTION {format.address}
+{ address duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ }
+ if$
+}
+
+
+
+%% author/editor names
+
+FUNCTION {format.authors}{ author "author" format.names }
+
+FUNCTION {format.editors}
+{ editor "editor" format.names duplicate$ empty$ 'skip$
+ { ", " *
+ get.bbl.editor
+ capitalize
+ *
+ }
+ if$
+}
+
+
+
+%% date
+
+FUNCTION {format.date}
+{
+ month "month" bibinfo.check duplicate$ empty$
+ year "year" bibinfo.check duplicate$ empty$
+ { swap$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ "there's a month but no year in " cite$ * warning$ }
+ if$
+ *
+ }
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ swap$ 'skip$
+ {
+ swap$
+ " " * swap$
+ }
+ if$
+ *
+ }
+ if$
+}
+
+FUNCTION {format.date.electronic}
+{ month "month" bibinfo.check duplicate$ empty$
+ year "year" bibinfo.check duplicate$ empty$
+ { swap$
+ { pop$ }
+ { "there's a month but no year in " cite$ * warning$
+ pop$ ")" * "(" swap$ *
+ this.to.prev.status
+ punct.no 'this.status.punct :=
+ space.normal 'this.status.space :=
+ quote.no 'this.status.quote :=
+ cap.yes 'status.cap :=
+ }
+ if$
+ }
+ { swap$
+ { swap$ pop$ ")" * "(" swap$ * }
+ { "(" swap$ * ", " * swap$ * ")" * }
+ if$
+ this.to.prev.status
+ punct.no 'this.status.punct :=
+ space.normal 'this.status.space :=
+ quote.no 'this.status.quote :=
+ cap.yes 'status.cap :=
+ }
+ if$
+}
+
+
+
+%% edition/title
+
+% Note: The IEEE considers the edition to be closely associated with
+% the title of a book. So, in IEEEtran.bst the edition is normally handled
+% within the formatting of the title. The format.edition function is
+% retained here for possible future use.
+FUNCTION {format.edition}
+{ edition duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ convert.edition
+ status.cap
+ { "t" }
+ { "l" }
+ if$ change.case$
+ "edition" bibinfo.check
+ "~" * bbl.edition *
+ cap.status.std
+ }
+ if$
+}
+
+% This is used to format the booktitle of a conference proceedings.
+% Here we use the "intype" field to provide the user a way to
+% override the word "in" (e.g., with things like "presented at")
+% Use of intype stops the emphasis of the booktitle to indicate that
+% we no longer mean the written conference proceedings, but the
+% conference itself.
+FUNCTION {format.in.booktitle}
+{ booktitle "booktitle" bibinfo.check duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ select.language
+ intype missing$
+ { emphasize
+ bbl.in " " *
+ }
+ { intype " " * }
+ if$
+ swap$ *
+ cap.status.std
+ }
+ if$
+}
+
+% This is used to format the booktitle of collection.
+% Here the "intype" field is not supported, but "edition" is.
+FUNCTION {format.in.booktitle.edition}
+{ booktitle "booktitle" bibinfo.check duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ select.language
+ emphasize
+ edition empty$ 'skip$
+ { ", " *
+ edition
+ convert.edition
+ "l" change.case$
+ * "~" * bbl.edition *
+ }
+ if$
+ bbl.in " " * swap$ *
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.article.title}
+{ title duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ "t" change.case$
+ }
+ if$
+ "title" bibinfo.check
+ duplicate$ empty$ 'skip$
+ { quote.close 'this.status.quote :=
+ is.last.char.not.punct
+ { punct.std 'this.status.punct := }
+ { punct.no 'this.status.punct := }
+ if$
+ select.language
+ "``" swap$ *
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.article.title.electronic}
+{ title duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ "t" change.case$
+ }
+ if$
+ "title" bibinfo.check
+ duplicate$ empty$
+ { skip$ }
+ { select.language }
+ if$
+}
+
+FUNCTION {format.book.title.edition}
+{ title "title" bibinfo.check
+ duplicate$ empty$
+ { "empty title in " cite$ * warning$ }
+ { this.to.prev.status
+ this.status.std
+ select.language
+ emphasize
+ edition empty$ 'skip$
+ { ", " *
+ edition
+ convert.edition
+ status.cap
+ { "t" }
+ { "l" }
+ if$
+ change.case$
+ * "~" * bbl.edition *
+ }
+ if$
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.book.title}
+{ title "title" bibinfo.check
+ duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ select.language
+ emphasize
+ }
+ if$
+}
+
+
+
+%% journal
+
+FUNCTION {format.journal}
+{ journal duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ select.language
+ emphasize
+ }
+ if$
+}
+
+
+
+%% how published
+
+FUNCTION {format.howpublished}
+{ howpublished duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ }
+ if$
+}
+
+
+
+%% institutions/organization/publishers/school
+
+FUNCTION {format.institution}
+{ institution duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.organization}
+{ organization duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.address.publisher.date}
+{ publisher "publisher" bibinfo.warn format.address.org.or.pub.date }
+
+FUNCTION {format.address.publisher.date.nowarn}
+{ publisher "publisher" bibinfo.check format.address.org.or.pub.date }
+
+FUNCTION {format.address.organization.date}
+{ organization "organization" bibinfo.check format.address.org.or.pub.date }
+
+FUNCTION {format.school}
+{ school duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ cap.status.std
+ }
+ if$
+}
+
+
+
+%% volume/number/series/chapter/pages
+
+FUNCTION {format.volume}
+{ volume empty.field.to.null.string
+ duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ bbl.volume
+ status.cap
+ { capitalize }
+ { skip$ }
+ if$
+ swap$ tie.or.space.prefix
+ "volume" bibinfo.check
+ * *
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.number}
+{ number empty.field.to.null.string
+ duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ status.cap
+ { bbl.number capitalize }
+ { bbl.number }
+ if$
+ swap$ tie.or.space.prefix
+ "number" bibinfo.check
+ * *
+ cap.status.std
+ }
+ if$
+}
+
+FUNCTION {format.number.if.use.for.article}
+{ is.use.number.for.article
+ { format.number }
+ { "" }
+ if$
+}
+
+% The IEEE does not seem to tie the series so closely with the volume
+% and number as is done in other bibliography styles. Instead the
+% series is treated somewhat like an extension of the title.
+FUNCTION {format.series}
+{ series empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ bbl.series " " *
+ series "series" bibinfo.check *
+ cap.status.std
+ }
+ if$
+}
+
+
+FUNCTION {format.chapter}
+{ chapter empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ type empty$
+ { bbl.chapter }
+ { type "l" change.case$
+ "type" bibinfo.check
+ }
+ if$
+ chapter tie.or.space.prefix
+ "chapter" bibinfo.check
+ * *
+ cap.status.std
+ }
+ if$
+}
+
+
+% The intended use of format.paper is for paper numbers of inproceedings.
+% The paper type can be overridden via the type field.
+% We allow the type to be displayed even if the paper number is absent
+% for things like "postdeadline paper"
+FUNCTION {format.paper}
+{ is.use.paper
+ { paper empty$
+ { type empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ type "type" bibinfo.check
+ cap.status.std
+ }
+ if$
+ }
+ { this.to.prev.status
+ this.status.std
+ type empty$
+ { bbl.paper }
+ { type "type" bibinfo.check }
+ if$
+ " " * paper
+ "paper" bibinfo.check
+ *
+ cap.status.std
+ }
+ if$
+ }
+ { "" }
+ if$
+}
+
+
+FUNCTION {format.pages}
+{ pages duplicate$ empty$ 'skip$
+ { this.to.prev.status
+ this.status.std
+ duplicate$ is.multiple.pages
+ {
+ bbl.pages swap$
+ n.dashify
+ }
+ {
+ bbl.page swap$
+ }
+ if$
+ tie.or.space.prefix
+ "pages" bibinfo.check
+ * *
+ cap.status.std
+ }
+ if$
+}
+
+
+
+%% technical report number
+
+FUNCTION {format.tech.report.number}
+{ number "number" bibinfo.check
+ this.to.prev.status
+ this.status.std
+ cap.status.std
+ type duplicate$ empty$
+ { pop$
+ bbl.techrep
+ }
+ { skip$ }
+ if$
+ "type" bibinfo.check
+ swap$ duplicate$ empty$
+ { pop$ }
+ { tie.or.space.prefix * * }
+ if$
+}
+
+
+
+%% note
+
+FUNCTION {format.note}
+{ note empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ punct.period 'this.status.punct :=
+ note #1 #1 substring$
+ duplicate$ "{" =
+ { skip$ }
+ { status.cap
+ { "u" }
+ { "l" }
+ if$
+ change.case$
+ }
+ if$
+ note #2 global.max$ substring$ * "note" bibinfo.check
+ cap.yes 'status.cap :=
+ }
+ if$
+}
+
+
+
+%% patent
+
+FUNCTION {format.patent.date}
+{ this.to.prev.status
+ this.status.std
+ year empty$
+ { monthfiled duplicate$ empty$
+ { "monthfiled" bibinfo.check pop$ "" }
+ { "monthfiled" bibinfo.check }
+ if$
+ dayfiled duplicate$ empty$
+ { "dayfiled" bibinfo.check pop$ "" * }
+ { "dayfiled" bibinfo.check
+ monthfiled empty$
+ { "dayfiled without a monthfiled in " cite$ * warning$
+ *
+ }
+ { " " swap$ * * }
+ if$
+ }
+ if$
+ yearfiled empty$
+ { "no year or yearfiled in " cite$ * warning$ }
+ { yearfiled "yearfiled" bibinfo.check
+ swap$
+ duplicate$ empty$
+ { pop$ }
+ { ", " * swap$ * }
+ if$
+ }
+ if$
+ }
+ { month duplicate$ empty$
+ { "month" bibinfo.check pop$ "" }
+ { "month" bibinfo.check }
+ if$
+ day duplicate$ empty$
+ { "day" bibinfo.check pop$ "" * }
+ { "day" bibinfo.check
+ month empty$
+ { "day without a month in " cite$ * warning$
+ *
+ }
+ { " " swap$ * * }
+ if$
+ }
+ if$
+ year "year" bibinfo.check
+ swap$
+ duplicate$ empty$
+ { pop$ }
+ { ", " * swap$ * }
+ if$
+ }
+ if$
+ cap.status.std
+}
+
+FUNCTION {format.patent.nationality.type.number}
+{ this.to.prev.status
+ this.status.std
+ nationality duplicate$ empty$
+ { "nationality" bibinfo.warn pop$ "" }
+ { "nationality" bibinfo.check
+ duplicate$ "l" change.case$ "united states" =
+ { pop$ bbl.patentUS }
+ { skip$ }
+ if$
+ " " *
+ }
+ if$
+ type empty$
+ { bbl.patent "type" bibinfo.check }
+ { type "type" bibinfo.check }
+ if$
+ *
+ number duplicate$ empty$
+ { "number" bibinfo.warn pop$ }
+ { "number" bibinfo.check
+ large.number.separate
+ swap$ " " * swap$ *
+ }
+ if$
+ cap.status.std
+}
+
+
+
+%% standard
+
+FUNCTION {format.organization.institution.standard.type.number}
+{ this.to.prev.status
+ this.status.std
+ organization duplicate$ empty$
+ { pop$
+ institution duplicate$ empty$
+ { "institution" bibinfo.warn }
+ { "institution" bibinfo.warn " " * }
+ if$
+ }
+ { "organization" bibinfo.warn " " * }
+ if$
+ type empty$
+ { bbl.standard "type" bibinfo.check }
+ { type "type" bibinfo.check }
+ if$
+ *
+ number duplicate$ empty$
+ { "number" bibinfo.check pop$ }
+ { "number" bibinfo.check
+ large.number.separate
+ swap$ " " * swap$ *
+ }
+ if$
+ cap.status.std
+}
+
+FUNCTION {format.revision}
+{ revision empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ bbl.revision
+ revision tie.or.space.prefix
+ "revision" bibinfo.check
+ * *
+ cap.status.std
+ }
+ if$
+}
+
+
+%% thesis
+
+FUNCTION {format.master.thesis.type}
+{ this.to.prev.status
+ this.status.std
+ type empty$
+ {
+ bbl.mthesis
+ }
+ {
+ type "type" bibinfo.check
+ }
+ if$
+cap.status.std
+}
+
+FUNCTION {format.phd.thesis.type}
+{ this.to.prev.status
+ this.status.std
+ type empty$
+ {
+ bbl.phdthesis
+ }
+ {
+ type "type" bibinfo.check
+ }
+ if$
+cap.status.std
+}
+
+
+
+%% URL
+%%
+FUNCTION {format.url}
+{ is.use.url
+ { url empty$
+ { "" }
+ { this.to.prev.status
+ this.status.std
+ cap.yes 'status.cap :=
+ name.url.prefix " " *
+ "\url{" * url * "}" *
+ punct.no 'this.status.punct :=
+ punct.period 'prev.status.punct :=
+ space.normal 'this.status.space :=
+ space.normal 'prev.status.space :=
+ quote.no 'this.status.quote :=
+ }
+ if$
+ }
+ { "" }
+ if$
+}
+
+
+
+
+%%%%%%%%%%%%%%%%%%%%
+%% ENTRY HANDLERS %%
+%%%%%%%%%%%%%%%%%%%%
+
+
+% Note: In many journals, the IEEE (or the authors) tend not to show the number
+% for articles, so the display of the number is controlled here by the
+% switch "is.use.number.for.article"
+FUNCTION {article}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.journal "journal" bibinfo.check "journal" output.warn
+ format.volume output
+ format.number.if.use.for.article output
+ format.pages output
+ format.date "year" output.warn
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {book}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ author empty$
+ { format.editors "author and editor" output.warn }
+ { format.authors output.nonnull }
+ if$
+ name.or.dash
+ format.book.title.edition output
+ format.series output
+ author empty$
+ { skip$ }
+ { format.editors output }
+ if$
+ format.address.publisher.date output
+ format.volume output
+ format.number output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {booklet}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.article.title "title" output.warn
+ format.howpublished "howpublished" bibinfo.check output
+ format.organization "organization" bibinfo.check output
+ format.address "address" bibinfo.check output
+ format.date output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {electronic}
+{ std.status.using.period
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.date.electronic output
+ format.article.title.electronic output
+ format.howpublished "howpublished" bibinfo.check output
+ format.organization "organization" bibinfo.check output
+ format.address "address" bibinfo.check output
+ format.note output
+ format.url output
+ fin.entry
+ empty.entry.warn
+ if.url.std.interword.spacing
+}
+
+FUNCTION {inbook}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ author empty$
+ { format.editors "author and editor" output.warn }
+ { format.authors output.nonnull }
+ if$
+ name.or.dash
+ format.book.title.edition output
+ format.series output
+ format.address.publisher.date output
+ format.volume output
+ format.number output
+ format.chapter output
+ format.pages output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {incollection}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.in.booktitle.edition "booktitle" output.warn
+ format.series output
+ format.editors output
+ format.address.publisher.date.nowarn output
+ format.volume output
+ format.number output
+ format.chapter output
+ format.pages output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {inproceedings}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.in.booktitle "booktitle" output.warn
+ format.series output
+ format.editors output
+ format.volume output
+ format.number output
+ publisher empty$
+ { format.address.organization.date output }
+ { format.organization "organization" bibinfo.check output
+ format.address.publisher.date output
+ }
+ if$
+ format.paper output
+ format.pages output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {manual}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.book.title.edition "title" output.warn
+ format.howpublished "howpublished" bibinfo.check output
+ format.organization "organization" bibinfo.check output
+ format.address "address" bibinfo.check output
+ format.date output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {mastersthesis}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.master.thesis.type output.nonnull
+ format.school "school" bibinfo.warn output
+ format.address "address" bibinfo.check output
+ format.date "year" output.warn
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {misc}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.article.title output
+ format.howpublished "howpublished" bibinfo.check output
+ format.organization "organization" bibinfo.check output
+ format.address "address" bibinfo.check output
+ format.pages output
+ format.date output
+ format.note output
+ format.url output
+ fin.entry
+ empty.entry.warn
+ if.url.std.interword.spacing
+}
+
+FUNCTION {patent}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.article.title output
+ format.patent.nationality.type.number output
+ format.patent.date output
+ format.note output
+ format.url output
+ fin.entry
+ empty.entry.warn
+ if.url.std.interword.spacing
+}
+
+FUNCTION {periodical}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.editors output
+ name.or.dash
+ format.book.title "title" output.warn
+ format.series output
+ format.volume output
+ format.number output
+ format.organization "organization" bibinfo.check output
+ format.date "year" output.warn
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {phdthesis}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.phd.thesis.type output.nonnull
+ format.school "school" bibinfo.warn output
+ format.address "address" bibinfo.check output
+ format.date "year" output.warn
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {proceedings}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.editors output
+ name.or.dash
+ format.book.title "title" output.warn
+ format.series output
+ format.volume output
+ format.number output
+ publisher empty$
+ { format.address.organization.date output }
+ { format.organization "organization" bibinfo.check output
+ format.address.publisher.date output
+ }
+ if$
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {standard}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors output
+ name.or.dash
+ format.book.title "title" output.warn
+ format.howpublished "howpublished" bibinfo.check output
+ format.organization.institution.standard.type.number output
+ format.revision output
+ format.date output
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {techreport}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.howpublished "howpublished" bibinfo.check output
+ format.institution "institution" bibinfo.warn output
+ format.address "address" bibinfo.check output
+ format.tech.report.number output.nonnull
+ format.date "year" output.warn
+ format.note output
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+FUNCTION {unpublished}
+{ std.status.using.comma
+ start.entry
+ if.url.alt.interword.spacing
+ format.authors "author" output.warn
+ name.or.dash
+ format.article.title "title" output.warn
+ format.date output
+ format.note "note" output.warn
+ format.url output
+ fin.entry
+ if.url.std.interword.spacing
+}
+
+
+% The special entry type which provides the user interface to the
+% BST controls
+FUNCTION {IEEEtranBSTCTL}
+{ is.print.banners.to.terminal
+ { "** IEEEtran BST control entry " quote$ * cite$ * quote$ * " detected." *
+ top$
+ }
+ { skip$ }
+ if$
+ CTLuse_article_number
+ empty$
+ { skip$ }
+ { CTLuse_article_number
+ yes.no.to.int
+ 'is.use.number.for.article :=
+ }
+ if$
+ CTLuse_paper
+ empty$
+ { skip$ }
+ { CTLuse_paper
+ yes.no.to.int
+ 'is.use.paper :=
+ }
+ if$
+ CTLuse_url
+ empty$
+ { skip$ }
+ { CTLuse_url
+ yes.no.to.int
+ 'is.use.url :=
+ }
+ if$
+ CTLuse_forced_etal
+ empty$
+ { skip$ }
+ { CTLuse_forced_etal
+ yes.no.to.int
+ 'is.forced.et.al :=
+ }
+ if$
+ CTLmax_names_forced_etal
+ empty$
+ { skip$ }
+ { CTLmax_names_forced_etal
+ string.to.integer
+ 'max.num.names.before.forced.et.al :=
+ }
+ if$
+ CTLnames_show_etal
+ empty$
+ { skip$ }
+ { CTLnames_show_etal
+ string.to.integer
+ 'num.names.shown.with.forced.et.al :=
+ }
+ if$
+ CTLuse_alt_spacing
+ empty$
+ { skip$ }
+ { CTLuse_alt_spacing
+ yes.no.to.int
+ 'is.use.alt.interword.spacing :=
+ }
+ if$
+ CTLalt_stretch_factor
+ empty$
+ { skip$ }
+ { CTLalt_stretch_factor
+ 'ALTinterwordstretchfactor :=
+ "\renewcommand{\BIBentryALTinterwordstretchfactor}{"
+ ALTinterwordstretchfactor * "}" *
+ write$ newline$
+ }
+ if$
+ CTLdash_repeated_names
+ empty$
+ { skip$ }
+ { CTLdash_repeated_names
+ yes.no.to.int
+ 'is.dash.repeated.names :=
+ }
+ if$
+ CTLname_format_string
+ empty$
+ { skip$ }
+ { CTLname_format_string
+ 'name.format.string :=
+ }
+ if$
+ CTLname_latex_cmd
+ empty$
+ { skip$ }
+ { CTLname_latex_cmd
+ 'name.latex.cmd :=
+ }
+ if$
+ CTLname_url_prefix
+ missing$
+ { skip$ }
+ { CTLname_url_prefix
+ 'name.url.prefix :=
+ }
+ if$
+
+
+ num.names.shown.with.forced.et.al max.num.names.before.forced.et.al >
+ { "CTLnames_show_etal cannot be greater than CTLmax_names_forced_etal in " cite$ * warning$
+ max.num.names.before.forced.et.al 'num.names.shown.with.forced.et.al :=
+ }
+ { skip$ }
+ if$
+}
+
+
+%%%%%%%%%%%%%%%%%%%
+%% ENTRY ALIASES %%
+%%%%%%%%%%%%%%%%%%%
+FUNCTION {conference}{inproceedings}
+FUNCTION {online}{electronic}
+FUNCTION {internet}{electronic}
+FUNCTION {webpage}{electronic}
+FUNCTION {www}{electronic}
+FUNCTION {default.type}{misc}
+
+
+
+%%%%%%%%%%%%%%%%%%
+%% MAIN PROGRAM %%
+%%%%%%%%%%%%%%%%%%
+
+READ
+
+EXECUTE {initialize.controls}
+EXECUTE {initialize.status.constants}
+EXECUTE {banner.message}
+
+
+
+% BEGIN sort code based on that of plain.bst
+
+FUNCTION {sortify}
+{ purify$
+ "l" change.case$
+}
+
+INTEGERS { len }
+
+FUNCTION {chop.word}
+{ 's :=
+ 'len :=
+ s #1 len substring$ =
+ { s len #1 + global.max$ substring$ }
+ { s }
+ if$
+}
+
+FUNCTION {sort.format.names}
+{ 's :=
+ #1 'nameptr :=
+ ""
+ s num.names$ 'numnames :=
+ numnames 'namesleft :=
+ { namesleft #0 > }
+ { nameptr #1 >
+ { " " * }
+ { skip$ }
+ if$
+ s nameptr "{vv{ } }{ll{ }}{ ff{ }}{ jj{ }}" format.name$ 't :=
+ nameptr numnames = t "others" = and
+ { "et al" * }
+ { t sortify * }
+ if$
+ nameptr #1 + 'nameptr :=
+ namesleft #1 - 'namesleft :=
+ }
+ while$
+}
+
+FUNCTION {sort.format.title}
+{ 't :=
+ bbl.a " " * #2
+ bbl.an " " * #3
+ bbl.the " " * #4 t chop.word
+ chop.word
+ chop.word
+ sortify
+ #1 global.max$ substring$
+}
+
+FUNCTION {author.sort}
+{ author empty$
+ { key empty$
+ { "to sort, need author or key in " cite$ * warning$ "" }
+ { key sortify }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+
+FUNCTION {author.editor.sort}
+{ author empty$
+ { editor empty$
+ { key empty$
+ { "to sort, need author, editor, or key in " cite$ * warning$ "" }
+ { key sortify }
+ if$
+ }
+ { editor sort.format.names }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+
+FUNCTION {author.organization.sort}
+{ author empty$
+ { organization empty$
+ { key empty$
+ { "to sort, need author, organization, or key in " cite$ * warning$ "" }
+ { key sortify }
+ if$
+ }
+ { bbl.the " " * #4 organization chop.word sortify }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+
+FUNCTION {editor.organization.sort}
+{ editor empty$
+ { organization empty$
+ { key empty$
+ { "to sort, need editor, organization, or key in " cite$ * warning$ "" }
+ { key sortify }
+ if$
+ }
+ { bbl.the " " * #4 organization chop.word sortify }
+ if$
+ }
+ { editor sort.format.names }
+ if$
+}
+
+FUNCTION {author.organization.institution.sort}
+{ author empty$
+ { organization empty$
+ { institution empty$
+ { key empty$
+ { "to sort, need author, organization, institution or key in " cite$ * warning$ "" }
+ { key sortify }
+ if$
+ }
+ { bbl.the " " * #4 institution chop.word sortify }
+ if$
+ }
+ { bbl.the " " * #4 organization chop.word sortify }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+
+
+FUNCTION {presort}
+{ type$ "ieeetranbstctl" =
+ { key empty$
+ { "_" }
+ { key sortify }
+ if$
+ }
+ { type$ "book" =
+ type$ "inbook" =
+ or
+ { author.editor.sort }
+ { type$ "proceedings" =
+ type$ "periodical" =
+ or
+ { editor.organization.sort }
+ { type$ "manual" =
+ type$ "electronic" =
+ type$ "misc" =
+ or or
+ { author.organization.sort }
+ { type$ "standard" =
+ { author.organization.institution.sort }
+ { author.sort }
+ if$
+ }
+ if$
+ }
+ if$
+ }
+ if$
+ " "
+ *
+ type$ "patent" =
+ { year empty$
+ { yearfiled }
+ { year }
+ if$
+ }
+ { year }
+ if$
+ empty.field.to.null.string sortify
+ *
+ " "
+ *
+ title empty.field.to.null.string
+ sort.format.title
+ *
+ }
+ if$
+ #1 entry.max$ substring$
+ 'sort.key$ :=
+}
+
+ITERATE {presort}
+
+SORT
+
+% END sort code based on that of plain.bst
+
+
+
+EXECUTE {initialize.longest.label}
+ITERATE {longest.label.pass}
+
+EXECUTE {begin.bib}
+ITERATE {call.type$}
+EXECUTE {end.bib}
+
+EXECUTE{completed.message}
+
+
+%% That's all folks, mds.
diff --git a/assets/2017/C.Herng Yi/Overlap_sampling_constraint.jpg b/assets/2017/C.Herng Yi/Overlap_sampling_constraint.jpg
new file mode 100644
index 0000000..2fd0572
Binary files /dev/null and b/assets/2017/C.Herng Yi/Overlap_sampling_constraint.jpg differ
diff --git a/assets/2017/C.Herng Yi/allfigs2.jpg b/assets/2017/C.Herng Yi/allfigs2.jpg
new file mode 100644
index 0000000..de89953
Binary files /dev/null and b/assets/2017/C.Herng Yi/allfigs2.jpg differ
diff --git a/assets/2017/C.Herng Yi/annulus_laplace.png b/assets/2017/C.Herng Yi/annulus_laplace.png
new file mode 100644
index 0000000..a8f652b
Binary files /dev/null and b/assets/2017/C.Herng Yi/annulus_laplace.png differ
diff --git a/assets/2017/C.Herng Yi/annulus_poisson.png b/assets/2017/C.Herng Yi/annulus_poisson.png
new file mode 100644
index 0000000..06fc8b9
Binary files /dev/null and b/assets/2017/C.Herng Yi/annulus_poisson.png differ
diff --git a/assets/2017/C.Herng Yi/annulusshape.png b/assets/2017/C.Herng Yi/annulusshape.png
new file mode 100644
index 0000000..ae7a475
Binary files /dev/null and b/assets/2017/C.Herng Yi/annulusshape.png differ
diff --git a/assets/2017/C.Herng Yi/laplace_irregular.png b/assets/2017/C.Herng Yi/laplace_irregular.png
new file mode 100644
index 0000000..be7cd1b
Binary files /dev/null and b/assets/2017/C.Herng Yi/laplace_irregular.png differ
diff --git a/assets/2017/C.Herng Yi/main.tex b/assets/2017/C.Herng Yi/main.tex
new file mode 100644
index 0000000..0cbb6f9
--- /dev/null
+++ b/assets/2017/C.Herng Yi/main.tex
@@ -0,0 +1,207 @@
+\documentclass[11pt,a4paper, final, twoside]{article}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{amsmath}
+\usepackage{fancyhdr}
+\usepackage{amsthm}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{amscd}
+\usepackage{latexsym}
+\usepackage{graphicx}
+\usepackage{graphics}
+\usepackage{natbib}
+\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black, citecolor=black]{hyperref}
+\usepackage{color}
+\usepackage{natbib}
+\usepackage{sectsty}
+\setcounter{MaxMatrixCols}{10}
+
+
+\sectionfont{\fontsize{12}{15}\selectfont}
+
+\renewcommand{\thefootnote}{}
+\setlength{\oddsidemargin}{1pt} \setlength{\evensidemargin}{1pt}
+\setlength{\hoffset}{-1in} \addtolength{\hoffset}{25mm}
+\setlength{\textwidth}{140mm}
+\setlength{\marginparsep}{0pt} \setlength{\marginparwidth}{0pt}
+\setlength{\topmargin}{0pt}
+\setlength{\voffset}{-2in} \addtolength{\voffset}{20mm}
+\setlength{\textheight}{300mm}
+\setlength{\headsep}{20mm}
+\setlength{\footskip}{15mm}
+\pagestyle{fancy}
+\fancyhead{} \fancyfoot{}
+
+
+
+% Theorem environments
+\newtheorem{thm}{Theorem}[section]
+\newtheorem{algorithm}[thm]{Algorithm}
+\newtheorem{axiom}[thm]{Axiom}
+\newtheorem{lem}[thm]{Lemma}
+\newtheorem{example}[thm]{Example}
+\newtheorem{exercise}[thm]{Exercise}
+\newtheorem{notation}[thm]{Notation}
+\newtheorem{problem}[thm]{Problem}
+\theoremstyle{proposition}
+\newtheorem{prop}{Proposition}[section]
+\newtheorem{case}[thm]{Case}
+\newtheorem{claim}[thm]{Claim}
+\newtheorem{conclusion}[thm]{Conclusion}
+\newtheorem{condition}[thm]{Condition}
+\newtheorem{conjecture}[thm]{Conjecture}
+\newtheorem{cor}[thm]{Corollary}
+\newtheorem{criterion}[thm]{Criterion}
+\theoremstyle{definition}
+\newtheorem{defn}{Definition}[section]
+\theoremstyle{remark}
+\newtheorem{rem}{Remark}[section]
+\newtheorem{solution}[thm]{Solution}
+\newtheorem{summary}[thm]{Summary}
+\numberwithin{equation}{section}
+\renewcommand{\rmdefault}{phv} % Arial
+\renewcommand{\sfdefault}{phv} % Arial
+\pagenumbering{arabic} % 1, 2, 3, 4, ...
+
+\begin{document}
+\hyphenpenalty=100000
+
+
+%%%%%%%%%%%%%%%
+%% MY MACROS %%
+%%%%%%%%%%%%%%%
+
+\newcommand{\R}{\mathbb{R}}
+\newcommand{\m}{\mathsf}
+\newcommand{\lap}{\Delta}
+\newcommand{\tp}{^\intercal}
+\newcommand{\mesh}{\mathcal{M}}
+
+\begin{center}
+
+{\Large \textbf{\\Solving PDEs on Deconstructed Domains\\for Geometry Processing}}\\[5mm]
+{\large \textbf{Herng Yi Cheng, Mitchell Dembowski, \\Silvia Gonz\'alez Sell\'an and Christine Ma }\\[1mm]}
+{\normalsize \emph{Under the supervision of Professor Alec Jacobson}\\[1mm]}
+\end{center}
+
+\section{Introduction}
+
+The Laplace equation and Possion equation are partial differential equations (PDEs) which arise naturally from analyzing heat flow, Maxwell's equations of electromagnetism, and shape recognition in computer graphics \cite{ShapeRepresentation}. We studied a new way to solve these equations on overlapping triangular mesh domains, in order to smoothen the computer animation of objects that are represented using those meshes. We designed several variants of a divide-and-conquer solution method, and tested them against each other for accuracy.
+
+\section{Background}\label{I1}
+
+%We studied a new way to solve some partial differential equations (PDEs) using a divide-and-conquer method. In particular, we studied
+The Laplace equation models the steady-state distribution of heat on a domain $A \subset \R^2$ with each point $(p_1,p_2)$ on its boundary $\partial A$ held at a fixed temperature $g(p_1,p_2)$. The steady-state temperature distribution $u(x,y) : A \to \R$ must satisfy
+\begin{align}
+\lap u (x,y) &= 0 &\text{ for all } &(x,y) \in A\setminus\partial A,\label{Eq:LaplaceEquation}\\
+u(p_1,p_2) &= g(p_1,p_2) &\text{ for all } &(p_1,p_2) \in \partial A\label{Eq:BoundaryCondition},
+\end{align}
+where \eqref{Eq:LaplaceEquation} is the Laplace equation, $\lap = \frac{\partial^2}{\partial x^2} + \frac{\partial^2}{\partial y^2}$ is the Laplace operator and \eqref{Eq:BoundaryCondition} is the boundary condition. \eqref{Eq:LaplaceEquation} can be generalized to the Poisson equation
+\begin{equation}
+\lap u = h \text{ for constant } h \in \R.
+\end{equation}
+
+The usual method for solving these PDEs numerically, known as finite element discretization, consists in approximating $A$ using a triangle mesh with vertices $v_1,\dotsc,v_n$ and substituting every function $f$ defined on $A$ by the vector of its finite evaluations $f_i=f(v_i)$. From this discrete perspective, solving either of the equations above becomes an optimization problem over a finite number of variables. The solutions to these optimization problems approximate the smooth solutions of the original PDE.
+
+%To solve these PDEs numerically, these equations that involve ``smooth'' differentiation over a continuous space are often ``discretized'' by approximating $A$ using a triangle mesh with vertices $v_1,\dotsc,v_n$, and formulating a ``dual optimization problem'' to the PDE over a finite number of variables. The solutions of these optimization problems approximate smooth solutions of the original PDEs.
+
+In the case of the Laplace and Poisson equations, this optimization problem amounts to minimizing the discrete Dirichlet energy function, which has the form
+%The optimization problem consists in minimizing the Dirichlet energy function, which has the form
+\begin{equation}\label{Eq:DirichletEnergy}
+E(u) = \frac12\m{u}_A\tp\m{Q}\m{u}_A + \m{c}\tp\m{u}_A \text{, where } \m{u}_A = \begin{bmatrix}
+u(v_1) \\ \vdots \\ u(v_n)
+\end{bmatrix},
+\end{equation}
+for some constant vector $\m{c} \in \R^n$. The $n \times n$ cotangent matrix $\m{Q}$ is ubiquitous in geometry processing and serves as the discrete equivalent of the continuous Laplace operator seen above; its derivation can be found in \cite{AlecThesis}. This energy is to be minimized over all $\m{u}_A \in \R^n$, subject to the boundary condition that fixes the entries of $\m{u}_A$ that correspond to vertices on $\partial A$. Expanding the matrix products in \eqref{Eq:DirichletEnergy} shows that the right-hand-side is quadratic in the entries of $\m{u}_A$, therefore standard techniques of quadratic programming that minimize quadratic functions subject to constraints yield the energy minimizer, or the vector $\m{u}_A$ that minimizes \eqref{Eq:DirichletEnergy}. However, the precise method by which these optimization problems are solved will not be a concern throughout the paper.
+
+
+%\section{Introduction}
+
+
+\newpage
+\section{Domain Decomposition}
+
+How well the energy minimizers approximate solutions to the smooth PDEs depends on the quality of the mesh. Two important parameters of a mesh that determine its quality are its coarseness, as measured by the average lengths of edges (segments connecting vertices), and its regularity, as measured by the aspect ratios of its triangles. Very regular meshes have triangles that are roughly equilateral, while long and thin triangles make an irregular mesh. As mesh quality improves, the energy minimizers should converge to solutions to the PDEs.
+
+Generating quality meshes that represent complex shapes is an active field of research. In 3D, it is often much easier to decompose complex 3D shapes into the union of simpler domains, and then generate quality meshes for those domains. Thus, we study a divide-and-conquer approach to minimize the Dirichlet energy over the union of many domains by minimizing parts of that energy over each individual domain, while demanding that the minimizers agree wherever the domains overlap, to ensure a compatible combined minimizer. We will refer to this as the consistency requirement (formalized below). We implemented this approach to handle general pairs of overlapping 2D domains $A$ and $B$, with corresponding meshes.
+
+However, functions over $A$ and $B$ cannot be compared because they are represented, respectively, by vectors $\m{u}_A$ and $\m{u}_B$, whose entries are values on different sets of vertices. In order to formulate that consistency requirement, we linearly interpolate from $\m{u}_A$ over the triangles of $A$'s mesh to reconstruct a function $u_A : A \to \R$; this is to say, we take $u_A$ to be the only function which is linear on every triangle of $A$'s mesh while taking the values of $\m{u}_A$ at its vertices.
+Similarly, we reconstruct $u_B : B \to \R$. This reconstruction can be plotted out, as in Figure~\ref{Fig:VisualizingConstraints}. Our contribution is to analyze the following two formulations of the consistency requirement as the linear constraints of quadratic programs, in the hopes that they can be generalized to 3D.
+\begin{description}
+ \item[Overlap sampling constraint (OSC)] $u_A$ and $u_B$ must agree at the combined vertices of both meshes.
+ \item[Dirichlet sampling constraint (DSC)] $u_A$ and $u_B$ must agree at the vertices of both meshes that lie on $\partial(A \cap B)$ (a small subset of the overlap sampling constraint).
+\end{description}
+
+\begin{figure}[h]\centering
+\begin{tabular}{ccc}\\
+\includegraphics[height=5cm]{Overlap_sampling_constraint} & \quad &
+\includegraphics[height=5cm]{Dirichlet_Sampling_Constraint}
+\end{tabular}
+\caption{Energy minimizers for the OSC (left) and the DSC (right), subject to the same boundary condition $g(x,y) = (x+0.3)^2y^2$. Note how the two generate virtually identical solutions, even though the second one is only enforcing equality on a much smaller number of vertices.
+}
+%The Dirichlet sampling constraint yields two barely-distinguishable layers over $A \cap B$, where equality is not enforced.}
+\label{Fig:VisualizingConstraints}
+\end{figure}
+
+\newpage
+\section{Experiments and results}\label{I2}
+
+From each constraint we derived a quadratic program to solve the Laplace or Poisson equation over $A \cup B$, subject to a boundary condition $g : \partial(A \cup B) \to \R$. Namely, we minimized a weighted combination of $E(u_A)$ and $E(u_B)$, such that $u_A$ and $u_B$ satisfy that constraint, and take values on vertices in $\partial(A \cup B)$ as dictated by $g$. We subjected each type of quadratic program to a convergence test over two annular domains with annular union (see figure \ref{Fig:AnnulusShape}), and measured the maximum of the distance of the approximations provided by each method to the known analytical solution. We repeated this test for $\lap u=0$, $\lap u=1$ and for different levels of mesh regularity. $\lap u = 1$ was chosen for a simple nonzero right-hand side; using any other nonzero constant would have simply scaled $u$.
+
+We concurrently tested the ``ideal'' method: combining the meshes of $A$ and $B$ into a combined mesh for $A \cup B$, and treating the minimizer of the Dirichlet energy over that combined mesh as a ground truth (GT) proxy to the analytic solution, when the latter is unknown. This ground truth would be unavailable in 3D where combining meshes is far more difficult, but it serves as a useful benchmark of our quadratic programs in 2D.
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width=0.6\textwidth]{annulusshape.png}
+ \caption{A pair of annular domains, in blue and red.}
+\label{Fig:AnnulusShape}
+\end{center}
+\end{figure}
+
+Our results, presented in Figure \ref{Fig:AnnulusResults}, show the Dirichlet sampling constraint to be clearly superior. While the overlap constraint appears to be accurate when solving $\lap u=0$ on regular meshes, it fails and does not even converge to the analytical solution for $\lap u = 1$, or when the meshes become increasingly irregular. As expected, the ground truth deviates the least from the analytic solution and converges to it the fastest.
+
+We performed similar tests on different domain shapes, which can be seen in Figure~\ref{Fig:ExamplesShape}. Since no analytical solution is available for these pairs of meshes, we simply measured the error between our methods and the co-refined ground truth (yellow line in figure~\ref{Fig:AnnulusResults}), safely assuming that this last one will surely converge to the smooth solution of the PDE. The results obtained from these experiments agreed completely with those observed for the pair of annular domains.
+
+\newpage
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width=.95\textwidth]{allfigs2.jpg}
+\caption{Convergence of our methods for annular domains. The top row shows the results for regular meshes, while the bottom one shows the results for irregular meshes. The left column contains results for the equation $\lap u=0$, while the right one does so for $\lap u=1$.}
+\label{Fig:AnnulusResults}
+\end{center}
+\end{figure}
+
+
+
+\begin{figure}[h]
+\begin{center}
+\includegraphics[width=0.3\textwidth]{pres1.jpg} \quad
+\includegraphics[width=0.3\textwidth]{pres2.jpg} \quad
+\includegraphics[width=0.3\textwidth]{pres3.jpg} \\
+\includegraphics[width=0.3\textwidth]{pres5.jpg} \quad
+\includegraphics[width=0.3\textwidth]{pres6.jpg} \quad
+\includegraphics[width=0.3\textwidth]{pres7.jpg}
+\caption{Examples of pairs of meshes over which we have tested convergence.}
+\label{Fig:ExamplesShape}
+\end{center}
+\end{figure}
+
+\newpage
+\section{Conclusion}
+
+The overlap sampling constraint performed inconsistently between $\lap u = 0$ and $\lap u = 1$, as well as between regular and irregular meshes, although it was surprisingly accurate when solving the Laplace equation on regular meshes.
+
+The Dirichlet sampling constraint converged in every one of our experiments for both the Laplace and Poisson equations, regardless of regularity and shape of the meshes. While converging slower than the ground truth, its rate of convergence appears to be at least linear. It is the best candidate for future research to generalize to 3D, progressing toward our goal of solving PDEs over the union of multiple domains when computing a common mesh is infeasible.
+
+\mbox{}\\
+
+\noindent {\Large\textbf{Acknowledgement}\\[1mm] }
+
+The authors would like to thank Prof. Alec Jacobson for his patient and dedicated mentorship, as well as the Fields Institute for bringing our research group together, and supporting our research with a stipend, through the Fields Undergraduate Summer Research Program. The third author would also like to express deep gratitude to the Mar\'ia Cristina Masav\'eu Peterson Foundation for its financial support of her studies.
+
+\bibliography{Bibliography}
+\bibliographystyle{plain}
+
+\end{document}
+
diff --git a/assets/2017/C.Herng Yi/poisson_irregular.png b/assets/2017/C.Herng Yi/poisson_irregular.png
new file mode 100644
index 0000000..e2f8c47
Binary files /dev/null and b/assets/2017/C.Herng Yi/poisson_irregular.png differ
diff --git a/assets/2017/C.Herng Yi/pres1.jpg b/assets/2017/C.Herng Yi/pres1.jpg
new file mode 100644
index 0000000..c426de8
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres1.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres2.jpg b/assets/2017/C.Herng Yi/pres2.jpg
new file mode 100644
index 0000000..bfe6262
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres2.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres3.jpg b/assets/2017/C.Herng Yi/pres3.jpg
new file mode 100644
index 0000000..9596d04
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres3.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres4.jpg b/assets/2017/C.Herng Yi/pres4.jpg
new file mode 100644
index 0000000..d8b4b95
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres4.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres5.jpg b/assets/2017/C.Herng Yi/pres5.jpg
new file mode 100644
index 0000000..79ee939
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres5.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres6.jpg b/assets/2017/C.Herng Yi/pres6.jpg
new file mode 100644
index 0000000..05b2737
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres6.jpg differ
diff --git a/assets/2017/C.Herng Yi/pres7.jpg b/assets/2017/C.Herng Yi/pres7.jpg
new file mode 100644
index 0000000..ece32ff
Binary files /dev/null and b/assets/2017/C.Herng Yi/pres7.jpg differ
diff --git a/assets/2017/D.Moore/badRadius.png b/assets/2017/D.Moore/badRadius.png
new file mode 100644
index 0000000..d8dd1e0
Binary files /dev/null and b/assets/2017/D.Moore/badRadius.png differ
diff --git a/assets/2017/D.Moore/blockUndef.png b/assets/2017/D.Moore/blockUndef.png
new file mode 100644
index 0000000..b736059
Binary files /dev/null and b/assets/2017/D.Moore/blockUndef.png differ
diff --git a/assets/2017/D.Moore/blockUndefBar.png b/assets/2017/D.Moore/blockUndefBar.png
new file mode 100644
index 0000000..1141a29
Binary files /dev/null and b/assets/2017/D.Moore/blockUndefBar.png differ
diff --git a/assets/2017/D.Moore/distanceGeo.png b/assets/2017/D.Moore/distanceGeo.png
new file mode 100644
index 0000000..c650861
Binary files /dev/null and b/assets/2017/D.Moore/distanceGeo.png differ
diff --git a/assets/2017/D.Moore/distancesEuch.png b/assets/2017/D.Moore/distancesEuch.png
new file mode 100644
index 0000000..94c91c6
Binary files /dev/null and b/assets/2017/D.Moore/distancesEuch.png differ
diff --git a/assets/2017/D.Moore/geodesicLine.png b/assets/2017/D.Moore/geodesicLine.png
new file mode 100644
index 0000000..1e08374
Binary files /dev/null and b/assets/2017/D.Moore/geodesicLine.png differ
diff --git a/assets/2017/D.Moore/geodesicLineGrid.png b/assets/2017/D.Moore/geodesicLineGrid.png
new file mode 100644
index 0000000..f64127d
Binary files /dev/null and b/assets/2017/D.Moore/geodesicLineGrid.png differ
diff --git a/assets/2017/D.Moore/jumpLine.png b/assets/2017/D.Moore/jumpLine.png
new file mode 100644
index 0000000..0639ef7
Binary files /dev/null and b/assets/2017/D.Moore/jumpLine.png differ
diff --git a/assets/2017/D.Moore/jumpLineGrid.png b/assets/2017/D.Moore/jumpLineGrid.png
new file mode 100644
index 0000000..2483467
Binary files /dev/null and b/assets/2017/D.Moore/jumpLineGrid.png differ
diff --git a/assets/2017/D.Moore/main.tex b/assets/2017/D.Moore/main.tex
new file mode 100644
index 0000000..e5d8325
--- /dev/null
+++ b/assets/2017/D.Moore/main.tex
@@ -0,0 +1,312 @@
+
+
+\documentclass[11pt,a4paper, final, twoside]{article}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{amsmath}
+\usepackage{fancyhdr}
+\usepackage{amsthm}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{amscd}
+\usepackage{latexsym}
+\usepackage{graphicx}
+\usepackage{graphics}
+\usepackage{natbib}
+\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black, citecolor=black]{hyperref}
+\usepackage{color}
+\usepackage{natbib}
+\usepackage{sectsty}
+\setcounter{MaxMatrixCols}{10}
+
+
+\sectionfont{\fontsize{12}{15}\selectfont}
+
+\renewcommand{\thefootnote}{}
+\setlength{\oddsidemargin}{1pt} \setlength{\evensidemargin}{1pt}
+\setlength{\hoffset}{-1in} \addtolength{\hoffset}{25mm}
+\setlength{\textwidth}{140mm}
+\setlength{\marginparsep}{0pt} \setlength{\marginparwidth}{0pt}
+\setlength{\topmargin}{0pt}
+\setlength{\voffset}{-2in} \addtolength{\voffset}{20mm}
+\setlength{\textheight}{250mm}
+\setlength{\headsep}{20mm}
+\setlength{\footskip}{15mm}
+\pagestyle{fancy}
+\fancyhead{} \fancyfoot{}
+
+
+
+% Theorem environments
+\newtheorem{thm}{Theorem}[section]
+\newtheorem{algorithm}[thm]{Algorithm}
+\newtheorem{axiom}[thm]{Axiom}
+\newtheorem{lem}[thm]{Lemma}
+\newtheorem{example}[thm]{Example}
+\newtheorem{exercise}[thm]{Exercise}
+\newtheorem{notation}[thm]{Notation}
+\newtheorem{problem}[thm]{Problem}
+\theoremstyle{proposition}
+\newtheorem{prop}{Proposition}[section]
+\newtheorem{case}[thm]{Case}
+\newtheorem{claim}[thm]{Claim}
+\newtheorem{conclusion}[thm]{Conclusion}
+\newtheorem{condition}[thm]{Condition}
+\newtheorem{conjecture}[thm]{Conjecture}
+\newtheorem{cor}[thm]{Corollary}
+\newtheorem{criterion}[thm]{Criterion}
+\theoremstyle{definition}
+\newtheorem{defn}{Definition}[section]
+\theoremstyle{remark}
+\newtheorem{rem}{Remark}[section]
+\newtheorem{solution}[thm]{Solution}
+\newtheorem{summary}[thm]{Summary}
+\numberwithin{equation}{section}
+\renewcommand{\rmdefault}{phv} % Arial
+\renewcommand{\sfdefault}{phv} % Arial
+\pagenumbering{arabic} % 1, 2, 3, 4, ...
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+% non-template additions
+
+\usepackage{caption}
+\usepackage[margin=.7cm]{subcaption}
+
+\setlength{\parindent}{0pt}
+\setlength{\parskip}{1em}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{document}
+\hyphenpenalty=100000
+
+\begin{center}
+
+{\Large \textbf{\\Geodesicness for Meshfree Simulation Methods }}\\[5mm]
+{\large \textbf{Darren Moore}\\[1mm]}
+{\normalsize \emph{Under the supervision of Professor David I.W. Levin and Professor Alec Jacobson}\\[1mm]}
+\end{center}
+
+\section{Introduction}
+Elasticity simulation can be used to animate the clothes that CGI characters wear or calculate how much weight structures will hold before they collapse \cite{Irving:2004:IFE:1028523.1028541} \cite{Clough:1990:OFF:106419.106421}. In general it lets us model how objects deform when forces are applied to them. The numerical methods used to do this require the object we're simulating to be discretized into finite pieces. The technique by which we discretize the object gives rise to two classes of numerical methods. One class, called Finite Element Methods, uses a polygon mesh discretization (Figure \ref{fig:meshA}), but mesh generation requires a lot of user tuning and can fail if the object has complicated geometry. The other class is Meshfree Methods, which uses a point cloud discretization (Figure \ref{fig:meshB}) rather than a mesh to perform the simulation.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{meshEx.png}
+ \caption{A triangle mesh for the finite element method.}
+ \label{fig:meshA}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{meshFreeEx.png}
+ \caption{A point cloud for meshfree methods.}
+ \label{fig:meshB}
+\end{subfigure}
+\caption{Two discretizations of an object that can be used for simulation.}
+\label{fig:mesh}
+\end{figure}
+
+An important distinction between point cloud and polygon mesh representations is the point cloud's lack of connectivity information. Elasticity requires a notion of connectivity to determine how applying a force to one point affects the points connected to it. Most meshfree methods simply take the set of all points in a certain radius $h$ around a given point to be connected to it (Figure \ref{fig:radius}). \cite{liu2005introduction}
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{smallRadius.png}
+ \caption{All points in a radius $h$ are connected.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{badRadius.png}
+ \caption{A case where the radial approach connects across a gap.}
+\end{subfigure}
+\caption{The radial approach in meshfree methods.}
+\label{fig:radius}
+\end{figure}
+
+This radial approach is problematic if two points are close to each other in space but have a large geodesic distance. Geodesic distance is the shortest distance between two points when taking paths that stay on the object (Figure \ref{fig:geodesic}). An incorrect interpretation of the topology will result in ``invisible connections'' that incorrectly constrain the movement of the object (Figure \ref{fig:geoBad}). The goal of our paper is to enhance the interpretation of the topology using point cloud geodesics. If you think of the point cloud as approximating a 2D shape, then a point cloud geodesic between two points is the geodesic distance between the points lying that 2D shape.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.5\linewidth]{distancesEuch.png}
+ \caption{Euclidean distance cuts through space.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.5\linewidth]{distanceGeo.png}
+ \caption{Geodesic distance stays on the object.}
+\end{subfigure}
+\caption{The Euclidean distance vs. geodesic distance between two points on a circle.}
+\label{fig:geodesic}
+\end{figure}
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{jumpLine.png}
+ \caption{}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{pantsStay.png}
+ \caption{}
+\end{subfigure}
+\caption{Due to an ``invisible connection'' in (a), the movement of the object is incorrectly constrained in (b). We expect the elastic lower bar to bend downwards.}
+\label{fig:geoBad}
+\end{figure}
+
+
+\section{Approach}
+
+We combine meshfree methods with point cloud geodesics to more accurately simulate point cloud data. The core of our approach is to use shortest-path graph searches to compute point cloud geodesic distances, then simulating the particles using those geodesic distances rather than standard Euclidean distances.
+
+To compute these point cloud geodesic distances, we represent the point cloud as a weighted graph with edge weights equal to the Euclidean distance between points (Figure \ref{fig:graph}). By exponentiating the weights we penalize large jumps. With sufficiently large exponent, the shortest-path graph distance approximates the geodesic distance.
+
+
+\begin{figure}[h]
+\centering
+\includegraphics{pointGraph.png}
+\caption{A graph defined over a point cloud. Two points are connected by an edge when their Euclidean distance is less than or equal to $h$. Edge weights are not represented in this figure.}
+\label{fig:graph}
+\end{figure}
+
+We define our graph as follows: given points $x_i$ and $x_j$, $(x_i, x_j)$ is an edge if and only if $\|x_i - x_j\| \leq h$, where $\|\cdot\|$ is the Euclidean norm. While our methods work if the graph is complete, we only connect points in a small radius to increase efficiency. Denote the edge weights by $w(x_i,x_j)$.
+
+We define a parameter, the \textit{geodesicness}, which represents the extent to which our method avoids large jumps while searching for a geodesic path between points. Let $\gamma \geq 1.0$ denote the geodesicness. Different point clouds may require different values of $\gamma$ since there will be different sized jumps in the data. This parameter is tuned by the user.
+
+Our geodesic approach uses $w(x_i, x_j) = \|x_i - x_j\|^\gamma$. As a result, large jumps in the data are expensive for the shortest-path graph search. With a sufficiently large $\gamma$, the path will walk around gaps and take a point cloud geodesic path (Figure \ref{fig:geoWalk}). It can be seen that letting $\gamma = 1.0$ is equivalent to the traditional approach. The geodesicness required to get an improved simulation result depends on the size of the gaps in the data, the number of points along the geodesic paths, and the distance between each point along the geodesic paths.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{jumpLineGrid.png}
+ \caption{Regular grid of particles.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{jumpLine.png}
+ \caption{Noisy particle arrangement.}
+\end{subfigure}
+
+\caption{The shortest path with a traditional radial based approach.}
+\label{fig:jump}
+\end{figure}
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{geodesicLineGrid.png}
+ \caption{Regular grid of particles.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{geodesicLine.png}
+ \caption{Noisy particle arrangement.}
+\end{subfigure}
+\caption{The shortest path with our geodesic approach.}
+\label{fig:geoWalk}
+\end{figure}
+
+
+\section{Results}
+
+
+We demonstrate our method's effectiveness by applying it to several point cloud data sets. Our simulations were done using a linear elastic material model, although our method works independently of the material model.
+
+Figure \ref{fig:barDrop} uses a point cloud of two bars connected only on the left. We fix the top bar in place and leave the bottom bar free to deform under gravity. With the traditional radial approach, the bottom bar does not deform, since it is incorrectly connected to the fixed top bar. With our geodesic approach, the bottom bar is free to bend downwards.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{blockUndef.png}
+ \caption{An undeformed point cloud.}
+\end{subfigure}%
+\includegraphics[scale=.25]{parula.png}
+
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{pantsStayColor.png}
+ \caption[width=2\textwidth]{Traditional radial approach: No visible deformation.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.7\linewidth]{pantsFall.png}
+ \caption{Our geodesic approach: The bar bends downwards as expected. Uses $\gamma = 15$.}
+\end{subfigure}
+\caption{The upper bar is held in place while an elastic lower bar should bend down due to gravity. Colour denotes displacement from original position.}
+\label{fig:barDrop}
+\end{figure}
+
+Figure \ref{fig:pantsKick} demonstrates our approach in the case of a user interacting with a pair of point cloud pants. We begin by fixing the top of the pants in place and allow the legs to deform freely. Next, a user attempts to pull the right leg to the right. With the traditional radial approach, the legs are incorrectly connected together and both pant legs deform. With our geodesic approach, the legs can move independently of each other as expected.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics{pantsUndefColor.png}
+ \caption{An undeformed point cloud of a pair of pants.}
+\end{subfigure}%
+\includegraphics[scale=.25]{parula.png}
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics{pantsLongStayColor.png}
+ \caption{Traditional radial approach: The legs are stuck together.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics{pantsKickColor.png}
+ \caption{Our geodesic approach: The artificial constraint is not present. Uses $\gamma = 15$.}
+\end{subfigure}
+\caption{A user deforms a pair of pants by pulling the black particle to the right. Colour denotes displacement from original position.}
+\label{fig:pantsKick}
+\end{figure}
+
+Figure \ref{fig:octopusBandit} demonstrates an application of our approach to character animation. We begin by fixing the head of the octopus in place and allow the arms to deform freely. With the traditional approach, the animator can't wiggle the arms around as they are stuck together. With our geodesic approach, the arms can move independently, allowing the octopus to wave hello.
+
+\begin{figure}[h]
+\centering
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.9\linewidth]{octoUndefRed.png}
+ \caption{The undeformed octopus bandit.}
+\end{subfigure}
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=.9\linewidth]{octoConnectRed.png}
+ \caption{Traditional radial approach: The arms are stuck together.}
+\end{subfigure}%
+\begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \includegraphics[width=1\linewidth]{octoHelloRed.png}
+ \caption{Our geodesic approach: The arms may move freely. Uses $\gamma = 15$.}
+\end{subfigure}
+\caption{An artist attempts to animate the octopus bandit waving hello.}
+\label{fig:octopusBandit}
+\end{figure}
+
+
+
+\section{Limitations}
+
+Unfortunately, the quality of a simulation produced using this method does not gracefully degrade as the geodesicness decreases. If the geodesicness falls below a certain threshold, the close points that are far geodesically will immediately connect and the simulation will behave as in the traditional radial approach.
+
+\section{Conclusion}
+Since point clouds have no connectivity information it's easy to incorrectly interpret the topology when simulating elasticity. We introduced a method which combines meshfree methods with point cloud geodesics to help interpret the topology in cases where points are close in space but far geodesically. Future work includes generalizing to three dimensions and investigating a gracefully degrading point cloud geodesic distance.
+
+\mbox{}\\
+
+\noindent \Large\textbf{Acknowledgement}\\[1mm]
+\normalsize \noindent I would like to acknowledge David Levin and Alec Jacobson, my supervisors, and Tim Jeruzalski, my mentor, for their support and ideas throughout this project.\\[3mm]
+
+\bibliography{refs.bib}
+\bibliographystyle{plain}
+
+\end{document}
diff --git a/assets/2017/D.Moore/meshEx.png b/assets/2017/D.Moore/meshEx.png
new file mode 100644
index 0000000..cf20877
Binary files /dev/null and b/assets/2017/D.Moore/meshEx.png differ
diff --git a/assets/2017/D.Moore/meshFreeEx.png b/assets/2017/D.Moore/meshFreeEx.png
new file mode 100644
index 0000000..ea37e23
Binary files /dev/null and b/assets/2017/D.Moore/meshFreeEx.png differ
diff --git a/assets/2017/D.Moore/octoConnectRed.png b/assets/2017/D.Moore/octoConnectRed.png
new file mode 100644
index 0000000..3f4afb2
Binary files /dev/null and b/assets/2017/D.Moore/octoConnectRed.png differ
diff --git a/assets/2017/D.Moore/octoHelloRed.png b/assets/2017/D.Moore/octoHelloRed.png
new file mode 100644
index 0000000..01da271
Binary files /dev/null and b/assets/2017/D.Moore/octoHelloRed.png differ
diff --git a/assets/2017/D.Moore/octoUndefRed.png b/assets/2017/D.Moore/octoUndefRed.png
new file mode 100644
index 0000000..acccdbc
Binary files /dev/null and b/assets/2017/D.Moore/octoUndefRed.png differ
diff --git a/assets/2017/D.Moore/pantsFall.png b/assets/2017/D.Moore/pantsFall.png
new file mode 100644
index 0000000..53b6d0d
Binary files /dev/null and b/assets/2017/D.Moore/pantsFall.png differ
diff --git a/assets/2017/D.Moore/pantsFallGrid.png b/assets/2017/D.Moore/pantsFallGrid.png
new file mode 100644
index 0000000..395bd6a
Binary files /dev/null and b/assets/2017/D.Moore/pantsFallGrid.png differ
diff --git a/assets/2017/D.Moore/pantsKickColor.png b/assets/2017/D.Moore/pantsKickColor.png
new file mode 100644
index 0000000..d74ee6d
Binary files /dev/null and b/assets/2017/D.Moore/pantsKickColor.png differ
diff --git a/assets/2017/D.Moore/pantsLongStayColor.png b/assets/2017/D.Moore/pantsLongStayColor.png
new file mode 100644
index 0000000..149f00b
Binary files /dev/null and b/assets/2017/D.Moore/pantsLongStayColor.png differ
diff --git a/assets/2017/D.Moore/pantsStay.png b/assets/2017/D.Moore/pantsStay.png
new file mode 100644
index 0000000..6567cc8
Binary files /dev/null and b/assets/2017/D.Moore/pantsStay.png differ
diff --git a/assets/2017/D.Moore/pantsStayColor.png b/assets/2017/D.Moore/pantsStayColor.png
new file mode 100644
index 0000000..5d7c15b
Binary files /dev/null and b/assets/2017/D.Moore/pantsStayColor.png differ
diff --git a/assets/2017/D.Moore/pantsStayGrid.png b/assets/2017/D.Moore/pantsStayGrid.png
new file mode 100644
index 0000000..a5673db
Binary files /dev/null and b/assets/2017/D.Moore/pantsStayGrid.png differ
diff --git a/assets/2017/D.Moore/pantsUndefColor.png b/assets/2017/D.Moore/pantsUndefColor.png
new file mode 100644
index 0000000..4cd75a2
Binary files /dev/null and b/assets/2017/D.Moore/pantsUndefColor.png differ
diff --git a/assets/2017/D.Moore/parula.png b/assets/2017/D.Moore/parula.png
new file mode 100644
index 0000000..47df3c7
Binary files /dev/null and b/assets/2017/D.Moore/parula.png differ
diff --git a/assets/2017/D.Moore/pointGraph.png b/assets/2017/D.Moore/pointGraph.png
new file mode 100644
index 0000000..4ecb4bd
Binary files /dev/null and b/assets/2017/D.Moore/pointGraph.png differ
diff --git a/assets/2017/D.Moore/refs.bib b/assets/2017/D.Moore/refs.bib
new file mode 100644
index 0000000..ec01e05
--- /dev/null
+++ b/assets/2017/D.Moore/refs.bib
@@ -0,0 +1,46 @@
+
+@article{Clough:1990:OFF:106419.106421,
+ author = {Clough, Ray W.},
+ title = {Original Formulation of the Finite Element Method},
+ journal = {Finite Elem. Anal. Des.},
+ issue_date = {Nov. 1990},
+ volume = {7},
+ number = {2},
+ month = nov,
+ year = {1990},
+ issn = {0168-874X},
+ pages = {89--101},
+ numpages = {13},
+ url = {http://dx.doi.org/10.1016/0168-874X(90)90001-U},
+ doi = {10.1016/0168-874X(90)90001-U},
+ acmid = {106421},
+ publisher = {Elsevier Science Publishers B. V.},
+ address = {Amsterdam, The Netherlands, The Netherlands},
+}
+
+@inproceedings{Irving:2004:IFE:1028523.1028541,
+ author = {Irving, G. and Teran, J. and Fedkiw, R.},
+ title = {Invertible Finite Elements for Robust Simulation of Large Deformation},
+ booktitle = {Proceedings of the 2004 ACM SIGGRAPH/Eurographics Symposium on Computer Animation},
+ series = {SCA '04},
+ year = {2004},
+ isbn = {3-905673-14-2},
+ location = {Grenoble, France},
+ pages = {131--140},
+ numpages = {10},
+ url = {http://dx.doi.org/10.1145/1028523.1028541},
+ doi = {10.1145/1028523.1028541},
+ acmid = {1028541},
+ publisher = {Eurographics Association},
+ address = {Aire-la-Ville, Switzerland, Switzerland},
+}
+
+@book{liu2005introduction,
+ title={An Introduction to Meshfree Methods and Their Programming},
+ author={Liu, G.R. and Gu, Y.T.},
+ isbn={9781402034688},
+ lccn={2006272255},
+ url={https://books.google.ca/books?id=0xS\_2XlQ\_Q0C},
+ year={2005},
+ publisher={Springer Netherlands}
+}
\ No newline at end of file
diff --git a/assets/2017/D.Moore/smallRadius.png b/assets/2017/D.Moore/smallRadius.png
new file mode 100644
index 0000000..bb63aa6
Binary files /dev/null and b/assets/2017/D.Moore/smallRadius.png differ
diff --git a/assets/2017/J.Yao/Uno_103_3_s2_4th-eps-converted-to-1.png b/assets/2017/J.Yao/Uno_103_3_s2_4th-eps-converted-to-1.png
new file mode 100644
index 0000000..1478f1b
Binary files /dev/null and b/assets/2017/J.Yao/Uno_103_3_s2_4th-eps-converted-to-1.png differ
diff --git a/assets/2017/J.Yao/convg_Uno104_BVP-eps-converted-to-1.png b/assets/2017/J.Yao/convg_Uno104_BVP-eps-converted-to-1.png
new file mode 100644
index 0000000..db987d4
Binary files /dev/null and b/assets/2017/J.Yao/convg_Uno104_BVP-eps-converted-to-1.png differ
diff --git a/assets/2017/J.Yao/convg_Uno104_IVP-eps-converted-to-1.png b/assets/2017/J.Yao/convg_Uno104_IVP-eps-converted-to-1.png
new file mode 100644
index 0000000..b8778ec
Binary files /dev/null and b/assets/2017/J.Yao/convg_Uno104_IVP-eps-converted-to-1.png differ
diff --git a/assets/2017/J.Yao/math1.png b/assets/2017/J.Yao/math1.png
new file mode 100644
index 0000000..dfcb145
Binary files /dev/null and b/assets/2017/J.Yao/math1.png differ
diff --git a/assets/2017/J.Yao/math10.PNG b/assets/2017/J.Yao/math10.PNG
new file mode 100644
index 0000000..46a27e6
Binary files /dev/null and b/assets/2017/J.Yao/math10.PNG differ
diff --git a/assets/2017/J.Yao/math11.PNG b/assets/2017/J.Yao/math11.PNG
new file mode 100644
index 0000000..0756e42
Binary files /dev/null and b/assets/2017/J.Yao/math11.PNG differ
diff --git a/assets/2017/J.Yao/math2.png b/assets/2017/J.Yao/math2.png
new file mode 100644
index 0000000..c6f0955
Binary files /dev/null and b/assets/2017/J.Yao/math2.png differ
diff --git a/assets/2017/J.Yao/math3.PNG b/assets/2017/J.Yao/math3.PNG
new file mode 100644
index 0000000..c5de634
Binary files /dev/null and b/assets/2017/J.Yao/math3.PNG differ
diff --git a/assets/2017/J.Yao/math4.PNG b/assets/2017/J.Yao/math4.PNG
new file mode 100644
index 0000000..d84ac59
Binary files /dev/null and b/assets/2017/J.Yao/math4.PNG differ
diff --git a/assets/2017/J.Yao/math5.PNG b/assets/2017/J.Yao/math5.PNG
new file mode 100644
index 0000000..690e5bb
Binary files /dev/null and b/assets/2017/J.Yao/math5.PNG differ
diff --git a/assets/2017/J.Yao/math6.PNG b/assets/2017/J.Yao/math6.PNG
new file mode 100644
index 0000000..24a707a
Binary files /dev/null and b/assets/2017/J.Yao/math6.PNG differ
diff --git a/assets/2017/J.Yao/math7.PNG b/assets/2017/J.Yao/math7.PNG
new file mode 100644
index 0000000..edb5f5c
Binary files /dev/null and b/assets/2017/J.Yao/math7.PNG differ
diff --git a/assets/2017/J.Yao/math8.PNG b/assets/2017/J.Yao/math8.PNG
new file mode 100644
index 0000000..4f2be18
Binary files /dev/null and b/assets/2017/J.Yao/math8.PNG differ
diff --git a/assets/2017/J.Yao/math9.PNG b/assets/2017/J.Yao/math9.PNG
new file mode 100644
index 0000000..6a98faa
Binary files /dev/null and b/assets/2017/J.Yao/math9.PNG differ
diff --git a/assets/2017/R.An/2-column.tex b/assets/2017/R.An/2-column.tex
new file mode 100644
index 0000000..5ea781e
--- /dev/null
+++ b/assets/2017/R.An/2-column.tex
@@ -0,0 +1,113 @@
+
+
+\documentclass[twocolumn]{article}
+
+\usepackage{indentfirst}
+\usepackage{float}
+\setlength{\parindent}{2em}
+
+\usepackage{graphicx}
+\graphicspath{ {images/} }
+
+\usepackage[linesnumbered,ruled,vlined]{algorithm2e}
+
+\usepackage{amsmath}
+\usepackage[margin=1cm]{geometry}
+
+\usepackage{biblatex}
+
+\bibliography{s.bib}
+
+
+
+\title{Parallel approach to single-source shortest path problem\\ on large complete graphs}
+
+\author{Ruijian An}
+
+\begin{document}
+\date{}
+\maketitle
+
+\section{Introduction}
+The single-source shortest path (SSSP) problem is a fundamental part of graph theory, with applications in transportation theory, road networks, DNA micro-arrays and many others. Given a weighted graph \emph{G = (V, E)} and a source vertex \emph{v}, the SSSP problem computes the shortest paths from \emph{v} to all other vertices.
+
+There are many efficient sequential solutions to this problem, such as Dijkstra's algorithm and the Bellman-Ford algorithm\cite{corman}. To maximize the work efficiency, Dijkstra's algorithm, which runs in \emph{O($|E| + |V|log|V|$)}, utilizes a greedy strategy, processing vertices one by one. On the other hand, the Bellman-Ford algorithm, which runs in O(\emph{$|E||V|$}), processes all vertices in every stage. Nevertheless, for large complete graphs, these sequential algorithms take a prohibitive amount of time for time-sensitive applications.
+
+Although Dijkstra's algorithm is sequential in nature, the Bellman-Ford algorithm contains a lot of parallelism which can be exploited to speed up the processing of large graphs. Our goal is to parallelize the latter algorithm, by utilizing the massively parallel architecture of Graphics Processing Units(GPUs) on large complete graphs. By efficiently implementing the algorithm on a GPU, our implementation gains a speedup of 167x over the naive parallel GPU version and 10.6x over the optimized parallel CPU version for large graphs with up to 20000 vertices.
+
+\section{Background}
+\subsection{The Bellman-Ford algorithm}
+\begin{algorithm}
+\SetAlgoLined
+\KwIn{G, w, s}
+$s.d = 0$\;
+\For{each vertex $v \in G.V$} {
+ v.d = INFINITY\;
+}
+\For{$i \gets 1$ \textbf{to} $\left|G.V\right| - 1$}{
+ \For{each edge $(u, v) \in G.E$}{
+ RELAX(u, v, w)\;
+ }
+}
+ \caption{BELLMAN\_FORD}
+\end{algorithm}
+
+\begin{algorithm}
+\SetAlgoLined
+$v.d = min(v.d, u.d + w(u, v))$\;
+\caption{RELAX}
+\end{algorithm}
+In the Bellman-Ford algorithm, each vertex in the graph has an attribute \emph{d}, which records the tentative distance from source vertex to itself. The algorithm also employs a technique called \emph{relaxation} to process edges. If an edge (\emph{u,v}) with weight \emph{w(u,v)} is relaxed, \emph{v.d} is replaced by \emph{min(v.d, u.d + w(u,v))}. The Bellman-Ford algorithm relaxes each edge for $\left|V\right|$ - 1 times, resulting in a time complexity of O($\left|V\right|$$\left|E\right|$).
+
+\subsection{GPU programming model}
+
+NVIDIA's CUDA is a user-friendly compute framework for carrying out general-purpose computations on GPUs\cite{nvi}. A CUDA program contains a kernel function, which is executed on the GPU, using a user-specified number of threads. All threads in a kernel have a unique ID, such that the kernel can assign different work based on the thread IDs. A typical CUDA program consists of three parts: copying the input data to GPU memory, launching a kernel which performs computations on the data and transferring data back to CPU memory. The data transfer time between CPU and GPU memory is typically a scalability bottleneck.
+
+
+\section{Approach}
+Our goal is to exploit the inherent data parallelism from the Bellman-Ford algorithm and accelerate it using parallelization techniques. First, we implement a straightforward naive parallelization, both on the CPU and on the GPU. Next, we optimize both implementations by improving work efficiency. Finally, we leverage GPU-specific features and mitigate the overheads of transferring data between main memory and device memory.
+
+The straightforward naive parallelization takes advantage of the inherent data parallelism. First, the shortest path estimate can be initialized in parallel. Secondly, edge relaxation, the most expensive step in the algorithm, can be parallelized. In existing parallel Bellman-Ford algorithms, each thread gets assigned a set of vertices and is responsible for relaxing either all the incoming or outgoing edges from its vertices\cite{Busato2016AnEI}\cite{Harish2007}. This approach uses adjacency lists and is well-suited for sparse graphs where $|V|$ is much larger than $|E|$. We use this as our naive multithreaded CPU implementation and naive GPU implementation.
+
+We observe that for complete graphs, partitioning work based on edges instead of vertices can exploit a higher degree of parallelism. While this approach is not straightforward to implement on the CPU, GPUs provide the ability to structure computations in a two-dimensional grid, where partitioning work by edges comes naturally. We use this observation as the baseline for our optimized GPU implementation and employ an adjacency matrix representation to better enable parallel edge relaxation on the GPU in an efficient manner.
+
+Next, we implement the optimized versions of the parallel CPU and GPU algorithms, which provide better work efficiency. We take advantage of two techniques, to discard unnecessary work. In the basic algorithm, all edges are required to be relaxed in each iteration, but not all relaxations are useful. For edge \emph{(u, v)}, the key of \emph{relaxation} is to compare \emph{v.d} with \emph{u.d + w(u,v)}, so the relaxation is useful only if the \emph{v.d} is updated in the previous iteration. Otherwise, the relaxation of \emph{(u, v)} involves redundant work. In the improved implementation, a bit \emph{mask} is used to record whether vertices are active. If a vertex's attribute \emph{d} is modified, then the corresponding bit indicates it is an active vertex. In the subsequent iterations, only edges whose starting vertex is active will be relaxed.
+
+Building on our previous observation, we can also reduce the number of iterations that the basic algorithm executes ($|V|-1$). The program can terminate once all shortest path distances converge, so instead of stopping at $|V|$-1, we can terminate early in an iteration when there are no more active vertices. We maintain a \emph{flag} to indicate if any vertices are active during the current iteration, and once the flag becomes unset, we skip the remaining iterations and terminate the execution early.
+
+
+Finally, a serialization bottleneck in our naive GPU implementation is the data transfer to device memory. In the optimized GPU algorithm, we restructure the code to leverage streams, which enable pipelining data transfers with computations.
+We create two streams \emph{(stream1, stream2)} and partition the adjacency matrix equally between them. Each part of the matrix is transferred to the device and processes in a different stream. Consequently, computations on the first part of the matrix can be carried out concurrently with transferring the second part of the matrix to the device, thus reducing the transfer time in half. We can further reduce this by similarly using more streams.
+
+
+
+\section{Analysis}
+We conduct two sets of experiments (using randomly-generated complete graphs): first, we compare a
+sequential CPU implementation, a naive multithreaded CPU version (by doing edge relaxation in parallel over 4 physical cores on a Core i7 6700HQ @ 2.6Ghz), and a naive GPU-based algorithm(on an NVIDIA Geforce GTX750 Ti, 640 cores, @ 1100MHz), all of which are unoptimized. The second graph compares the optimized multithreaded CPU implementation with the optimized GPU algorithm as described in Section 3. We include the basic (unoptimized) \textit{parallel} CPU and GPU implementations as a reference point in the second graph. Both optimized versions enforce the aforementioned work efficiency optimizations, and the latter also leverages GPU streams for overlapping data transfers with computations.\newline
+\begin{figure}[h]
+
+\centering
+\includegraphics[width=0.45\textwidth]{fig1}
+\caption{Straightforward (work inefficient) parallelization on the CPU and GPU (log scale on y axis)}
+\end{figure}
+
+
+\begin{figure}[h]
+
+\centering
+\includegraphics[width=0.5\textwidth]{fig2}
+\caption{Work ineffcient vs. optimized algorithm implementations (log scale on y axis)}
+\label{ab}
+\end{figure}
+In the first comparison, the naive GPU implementation outperforms both sequential CPU and naive multithreaded CPU versions. All implementations perform unnecessary computations, and the GPU implementation also suffers from high data transfer overheads to device memory. Consequently, we restructure parallel algorithms to reduce work inefficiencies, and use GPU streams to overlap memory transfers.
+
+Our results from Figure 2 show that the optimized GPU algorithm outperforms its optimized CPU counterpart, achieving a 10.6x speedup for a large graph with 20000 vertices. When the graph is small, the difference between the two implementations is not significant because only a subset of GPU cores are utilized and CPU cores operate at a much higher clock rate. However, the gap increases with input size, as more GPU cores actively participate in computations, while the same number of CPU cores process increasingly larger tasks. Although our testing limitations did not permit testing with larger graphs (e.g., millions of vertices), we expect this gap will increase even further.
+
+The optimizations and use of streams in the GPU implementation reduce the execution time by 167x compared to the work inefficient GPU version, while the optimized CPU implementation achieves up to 334x speedup over the work inefficient multithreaded CPU implementation, on large graphs.
+
+\section{Conclusion}
+Our work proposes an improved parallel Bellman-Ford algorithm implementation. By reworking the algorithm to leverage GPU-specific optimizations, reduce work inefficiencies, and deal with the data transfer overheads using streams, the proposed implementation is 167x faster than a naive GPU implementation, and 10.6x faster than an optimized parallel CPU implementation, on large graphs.
+
+\printbibliography
+
+\end{document}
\ No newline at end of file
diff --git a/assets/2017/R.An/RUCS-tempalte.tex b/assets/2017/R.An/RUCS-tempalte.tex
new file mode 100644
index 0000000..282e673
--- /dev/null
+++ b/assets/2017/R.An/RUCS-tempalte.tex
@@ -0,0 +1,144 @@
+\documentclass[11pt,a4paper, final, twoside]{article}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{amsmath}
+\usepackage{fancyhdr}
+\usepackage{amsthm}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{amscd}
+\usepackage{latexsym}
+\usepackage{graphicx}
+\usepackage{graphics}
+\usepackage{natbib}
+\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black, citecolor=black]{hyperref}
+\usepackage{color}
+\usepackage{natbib}
+\usepackage{sectsty}
+\setcounter{MaxMatrixCols}{10}
+
+
+\sectionfont{\fontsize{12}{15}\selectfont}
+
+\renewcommand{\thefootnote}{}
+\setlength{\oddsidemargin}{1pt} \setlength{\evensidemargin}{1pt}
+\setlength{\hoffset}{-1in} \addtolength{\hoffset}{25mm}
+\setlength{\textwidth}{140mm}
+\setlength{\marginparsep}{0pt} \setlength{\marginparwidth}{0pt}
+\setlength{\topmargin}{0pt}
+\setlength{\voffset}{-2in} \addtolength{\voffset}{20mm}
+\setlength{\textheight}{300mm}
+\setlength{\headsep}{20mm}
+\setlength{\footskip}{15mm}
+\pagestyle{fancy}
+\fancyhead{} \fancyfoot{}
+
+
+
+% Theorem environments
+\newtheorem{thm}{Theorem}[section]
+\newtheorem{algorithm}[thm]{Algorithm}
+\newtheorem{axiom}[thm]{Axiom}
+\newtheorem{lem}[thm]{Lemma}
+\newtheorem{example}[thm]{Example}
+\newtheorem{exercise}[thm]{Exercise}
+\newtheorem{notation}[thm]{Notation}
+\newtheorem{problem}[thm]{Problem}
+\theoremstyle{proposition}
+\newtheorem{prop}{Proposition}[section]
+\newtheorem{case}[thm]{Case}
+\newtheorem{claim}[thm]{Claim}
+\newtheorem{conclusion}[thm]{Conclusion}
+\newtheorem{condition}[thm]{Condition}
+\newtheorem{conjecture}[thm]{Conjecture}
+\newtheorem{cor}[thm]{Corollary}
+\newtheorem{criterion}[thm]{Criterion}
+\theoremstyle{definition}
+\newtheorem{defn}{Definition}[section]
+\theoremstyle{remark}
+\newtheorem{rem}{Remark}[section]
+\newtheorem{solution}[thm]{Solution}
+\newtheorem{summary}[thm]{Summary}
+\numberwithin{equation}{section}
+\renewcommand{\rmdefault}{phv} % Arial
+\renewcommand{\sfdefault}{phv} % Arial
+\pagenumbering{arabic} % 1, 2, 3, 4, ...
+
+\begin{document}
+\hyphenpenalty=100000
+
+
+
+\begin{center}
+
+{\Large \textbf{\\Parallel appraoch to single-source shortest path problem\\on large complete graphs }}\\[5mm]
+{\large \textbf{Ruijian An}\\[1mm]}
+{\normalsize \emph{Under the supervision of Professor Bogdan Simion}\\[1mm]}
+\end{center}
+
+
+\section{Introduction}\label{I1}
+The single-source shortest path (SSSP) problem is a fundamental part of graph theory, with applications in transportation theory, road networks, DNA micro-arrays and many others. Given a weighted graph \emph{G = (V, E)} and a source vertex \emph{v}, the SSSP problem computes the shortest paths from \emph{v} to all other vertices.
+
+There are many efficient sequential solutions to this problem, such as Dijkstra's algorithm and the Bellman-Ford algorithm\cite{corman}. To maximize the work efficiency, Dijkstra's algorithm, which runs in \emph{O($|E| + |V|log|V|$)}, utilizes a greedy strategy, processing vertices one by one. On the other hand, the Bellman-Ford algorithm, which runs in O(\emph{$|E||V|$}), processes all vertices in every stage. Nevertheless, for large complete graphs, these sequential algorithms take a prohibitive amount of time for time-sensitive applications.
+
+Although Dijkstra's algorithm is sequential in nature, the Bellman-Ford algorithm contains a lot of parallelism which can be exploited to speed up the processing of large graphs. Our goal is to parallelize the latter algorithm, by utilizing the massively parallel architecture of Graphics Processing Units(GPUs) on large complete graphs. By efficiently implementing the algorithm on a GPU, our implementation gains a speedup of 167x over the naive parallel GPU version and 10.6x over the optimized parallel CPU version for large graphs with up to 20000 vertices.
+\section{Background}\label{I2}
+\subsection{The Bellman-Ford algorithm}
+
+In the Bellman-Ford algorithm, each vertex in the graph has an attribute \emph{d}, which records the tentative distance from source vertex to itself. The algorithm also employs a technique called \emph{relaxation} to process edges. If an edge (\emph{u,v}) with weight \emph{w(u,v)} is relaxed, \emph{v.d} is replaced by \emph{min(v.d, u.d + w(u,v))}. The Bellman-Ford algorithm relaxes each edge for $\left|V\right|$ - 1 times, resulting in a time complexity of O($\left|V\right|$$\left|E\right|$).
+
+\subsection{GPU programming model}
+
+NVIDIA's CUDA is a user-friendly compute framework for carrying out general-purpose computations on GPUs\cite{nvi}. A CUDA program contains a kernel function, which is executed on the GPU, using a user-specified number of threads. All threads in a kernel have a unique ID, such that the kernel can assign different work based on the thread IDs. A typical CUDA program consists of three parts: copying the input data to GPU memory, launching a kernel which performs computations on the data and transferring data back to CPU memory. The data transfer time between CPU and GPU memory is typically a scalability bottleneck.
+\newpage
+\section{Approach}\label{I3}
+
+Our goal is to exploit the inherent data parallelism from the Bellman-Ford algorithm and accelerate it using parallelization techniques. First, we implement a straightforward naive parallelization, both on the CPU and on the GPU. Next, we optimize both implementations by improving work efficiency. Finally, we leverage GPU-specific features and mitigate the overheads of transferring data between main memory and device memory.
+
+The straightforward naive parallelization takes advantage of the inherent data parallelism. First, the shortest path estimate can be initialized in parallel. Secondly, edge relaxation, the most expensive step in the algorithm, can be parallelized. In existing parallel Bellman-Ford algorithms, each thread gets assigned a set of vertices and is responsible for relaxing either all the incoming or outgoing edges from its vertices\cite{Busato2016AnEI}\cite{Harish2007}. This approach uses adjacency lists and is well-suited for sparse graphs where $|V|$ is much larger than $|E|$. We use this as our naive multithreaded CPU implementation and naive GPU implementation.
+
+We observe that for complete graphs, partitioning work based on edges instead of vertices can exploit a higher degree of parallelism. While this approach is not straightforward to implement on the CPU, GPUs provide the ability to structure computations in a two-dimensional grid, where partitioning work by edges comes naturally. We use this observation as the baseline for our optimized GPU implementation and employ an adjacency matrix representation to better enable parallel edge relaxation on the GPU in an efficient manner.
+
+Next, we implement the optimized versions of the parallel CPU and GPU algorithms, which provide better work efficiency. We take advantage of two techniques, to discard unnecessary work. In the basic algorithm, all edges are required to be relaxed in each iteration, but not all relaxations are useful. For edge \emph{(u, v)}, the key of \emph{relaxation} is to compare \emph{v.d} with \emph{u.d + w(u,v)}, so the relaxation is useful only if the \emph{v.d} is updated in the previous iteration. Otherwise, the relaxation of \emph{(u, v)} involves redundant work. In the improved implementation, a bit \emph{mask} is used to record whether vertices are active. If a vertex's attribute \emph{d} is modified, then the corresponding bit indicates it is an active vertex. In the subsequent iterations, only edges whose starting vertex is active will be relaxed.
+
+Building on our previous observation, we can also reduce the number of iterations that the basic algorithm executes ($|V|-1$). The program can terminate once all shortest path distances converge, so instead of stopping at $|V|$-1, we can terminate early in an iteration when there are no more active vertices. We maintain a \emph{flag} to indicate if any vertices are active during the current iteration, and once the flag becomes unset, we skip the remaining iterations and terminate the execution early.
+
+
+Finally, a serialization bottleneck in our naive GPU implementation is the data transfer to device memory. In the optimized GPU algorithm, we restructure the code to leverage streams, which enable pipelining data transfers with computations.
+We create two streams \emph{(stream1, stream2)} and partition the adjacency matrix equally between them. Each part of the matrix is transferred to the device and processes in a different stream. Consequently, computations on the first part of the matrix can be carried out concurrently with transferring the second part of the matrix to the device, thus reducing the transfer time in half. We can further reduce this by similarly using more streams.
+\newpage
+\section{Analysis}\label{I4}
+We conduct two sets of experiments (using randomly-generated complete graphs): first, we compare a
+sequential CPU implementation, a naive multithreaded CPU version (by doing edge relaxation in parallel over 4 physical cores on a Core i7 6700HQ @ 2.6Ghz), and a naive GPU-based algorithm(on an NVIDIA Geforce GTX750 Ti, 640 cores, @ 1100MHz), all of which are unoptimized. The second graph compares the optimized multithreaded CPU implementation with the optimized GPU algorithm as described in Section 3. We include the basic (unoptimized) \textit{parallel} CPU and GPU implementations as a reference point in the second graph. Both optimized versions enforce the aforementioned work efficiency optimizations, and the latter also leverages GPU streams for overlapping data transfers with computations.\newline
+\begin{figure}[h]
+
+\centering
+\includegraphics[width=0.8\textwidth]{fig1}
+\caption{Straightforward (work inefficient) parallelization on the CPU and GPU (log scale on y axis)}
+\end{figure}
+
+
+\begin{figure}[h]
+
+\centering
+\includegraphics[width=0.8\textwidth]{fig2}
+\caption{Work ineffcient vs. optimized algorithm implementations (log scale on y axis)}
+\label{ab}
+\end{figure}
+
+\newpage
+In the first comparison, the naive GPU implementation outperforms both sequential CPU and naive multithreaded CPU versions. All implementations perform unnecessary computations, and the GPU implementation also suffers from high data transfer overheads to device memory. Consequently, we restructure parallel algorithms to reduce work inefficiencies, and use GPU streams to overlap memory transfers.
+
+Our results from Figure 2 show that the optimized GPU algorithm outperforms its optimized CPU counterpart, achieving a 10.6x speedup for a large graph with 20000 vertices. When the graph is small, the difference between the two implementations is not significant because only a subset of GPU cores are utilized and CPU cores operate at a much higher clock rate. However, the gap increases with input size, as more GPU cores actively participate in computations, while the same number of CPU cores process increasingly larger tasks. Although our testing limitations did not permit testing with larger graphs (e.g., millions of vertices), we expect this gap will increase even further.
+
+The optimizations and use of streams in the GPU implementation reduce the execution time by 167x compared to the work inefficient GPU version, while the optimized CPU implementation achieves up to 334x speedup over the work inefficient multithreaded CPU implementation, on large graphs.
+\section{Conclusion}
+Our work proposes an improved parallel Bellman-Ford algorithm implementation. By reworking the algorithm to leverage GPU-specific optimizations, reduce work inefficiencies, and deal with the data transfer overheads using streams, the proposed implementation is 167x faster than a naive GPU implementation, and 10.6x faster than an optimized parallel CPU implementation, on large graphs.
+
+
+
+\bibliography{s.bib}
+\bibliographystyle{unsrt}
+
+\end{document}
+
diff --git a/assets/2017/R.An/bellman-ford.png b/assets/2017/R.An/bellman-ford.png
new file mode 100644
index 0000000..f34a527
Binary files /dev/null and b/assets/2017/R.An/bellman-ford.png differ
diff --git a/assets/2017/R.An/fig1.png b/assets/2017/R.An/fig1.png
new file mode 100644
index 0000000..3e82552
Binary files /dev/null and b/assets/2017/R.An/fig1.png differ
diff --git a/assets/2017/R.An/fig2.png b/assets/2017/R.An/fig2.png
new file mode 100644
index 0000000..f9f2fd1
Binary files /dev/null and b/assets/2017/R.An/fig2.png differ
diff --git a/assets/2017/R.An/s.bib b/assets/2017/R.An/s.bib
new file mode 100644
index 0000000..6a64381
--- /dev/null
+++ b/assets/2017/R.An/s.bib
@@ -0,0 +1,36 @@
+
+
+@article{Busato2016AnEI,
+ title={An Efficient Implementation of the Bellman-Ford Algorithm for Kepler GPU Architectures},
+ author={Federico Busato and Nicola Bombieri},
+ journal={IEEE Transactions on Parallel and Distributed Systems},
+ year={2016},
+ volume={27},
+ pages={2222-2233}
+}
+
+
+
+
+@book{corman,
+ title={Introduction to algorithms},
+ author={Thomas H. Cormen},
+ year={1990},
+ publisher={MIT Press, Cambridge, MA}
+}
+
+
+@online{nvi,
+ author = "Nvidia",
+ title = "CUDA C Programming Guide",
+ url = "http://docs.nvidia.com/cuda/cuda-c-programming-guide/"
+}
+
+
+@Inbook{Harish2007,
+author="Harish, Pawan
+and Narayanan, P. J.",
+title="Accelerating Large Graph Algorithms on the GPU Using CUDA",
+bookTitle="HiPC 2007"
+}
+
diff --git a/assets/2017/S.Kousha/image1.png b/assets/2017/S.Kousha/image1.png
new file mode 100644
index 0000000..5d49874
Binary files /dev/null and b/assets/2017/S.Kousha/image1.png differ
diff --git a/assets/2017/S.Kousha/image2.png b/assets/2017/S.Kousha/image2.png
new file mode 100644
index 0000000..82bd2ce
Binary files /dev/null and b/assets/2017/S.Kousha/image2.png differ
diff --git a/assets/2017/S.Kousha/image3.png b/assets/2017/S.Kousha/image3.png
new file mode 100644
index 0000000..404e391
Binary files /dev/null and b/assets/2017/S.Kousha/image3.png differ
diff --git a/assets/2017/S.Kousha/image4.png b/assets/2017/S.Kousha/image4.png
new file mode 100644
index 0000000..ec7815b
Binary files /dev/null and b/assets/2017/S.Kousha/image4.png differ
diff --git a/assets/2017/Z.Zhou/20171023113404926.pdf b/assets/2017/Z.Zhou/20171023113404926.pdf
new file mode 100644
index 0000000..9aaa364
Binary files /dev/null and b/assets/2017/Z.Zhou/20171023113404926.pdf differ
diff --git a/assets/2017/Z.Zhou/COACH_prompt.png b/assets/2017/Z.Zhou/COACH_prompt.png
new file mode 100644
index 0000000..aacfbb4
Binary files /dev/null and b/assets/2017/Z.Zhou/COACH_prompt.png differ
diff --git a/assets/2017/Z.Zhou/COACH_with_customization_prompt.png b/assets/2017/Z.Zhou/COACH_with_customization_prompt.png
new file mode 100644
index 0000000..5b5e2b3
Binary files /dev/null and b/assets/2017/Z.Zhou/COACH_with_customization_prompt.png differ
diff --git a/assets/2017/Z.Zhou/customRobot_ruc17_submission.pdf b/assets/2017/Z.Zhou/customRobot_ruc17_submission.pdf
new file mode 100644
index 0000000..cd25ac7
Binary files /dev/null and b/assets/2017/Z.Zhou/customRobot_ruc17_submission.pdf differ
diff --git a/assets/2017/Z.Zhou/extended_abstract.bib b/assets/2017/Z.Zhou/extended_abstract.bib
new file mode 100644
index 0000000..5e3477c
--- /dev/null
+++ b/assets/2017/Z.Zhou/extended_abstract.bib
@@ -0,0 +1,56 @@
+@article{COACH,
+ author = "Jesse Hoey and Axel von Bertoldi and Pascal Poupart and Alex Mihailidis",
+ title = "Assisting persons with dementia during handwashing using a partially observable Markov decision process",
+ journal = "The 5th International Conference on Computer Vision Systems",
+ year = "2007",
+ DOI = "10.2390/biecoll-icvs2007-89"
+}
+
+@article{practice1,
+ author = "Rozanne Wilson and Elizabeth Rochon and Alex Mihailidis and Carol Leonard",
+ title = "Examining Success of Communication Strategies Used by Formal Caregivers Assisting Individuals With Alzheimer's Disease During an Activity of Daily Living",
+ journal = "Journal of Speech Language and Hearing research",
+ volume = "55",
+ number = "2",
+ pages = "328--341",
+ year = "2012",
+ doi = "10.1044/1092-4388(2011/10-0206)",
+}
+
+@article{practice2,
+ author = "Rozanne Wilson and Elizabeth Rochon and Alex Mihailidis and Carol Leonard",
+ title = "Quantitative analysis of formal caregivers’ use of communication strategies while assisting individuals with moderate and severe Alzheimer's disease during oral care",
+ journal = "Journal of Communication Disorders",
+ volume = "46",
+ number = "3",
+ pages = "249--263",
+ year = "2013",
+ doi = "10.1016/j.jcomdis.2013.01.004",
+}
+
+@misc{rochon,
+ author = "Elizabeth Rochon",
+ title = "Personal Communication",
+ year = "2017",
+}
+
+@online{web1,
+ author = "Alzheimer's Association",
+ title = "Communication and Alzheimer's",
+ url = "https://www.alz.org/care/dementia-communication-tips.asp",
+ year = "2017",
+}
+
+@online{web2,
+ author = "Alzheimer Society Canada",
+ title = "Ways to communicate",
+ url = "http://www.alzheimer.ca/en/Living-with-dementia/Ways-to-communicate",
+ year = "2017",
+}
+
+@online{web3,
+ author = "Family Caregiver Alliance",
+ title = "Caregiver's Guide to Understanding dementia Behaviours",
+ url = "https://www.caregiver.org/caregivers-guide-understanding-dementia-behaviors",
+ year = "2017",
+}
\ No newline at end of file
diff --git a/assets/2017/Z.Zhou/extended_abstract.tex b/assets/2017/Z.Zhou/extended_abstract.tex
new file mode 100644
index 0000000..727bf4e
--- /dev/null
+++ b/assets/2017/Z.Zhou/extended_abstract.tex
@@ -0,0 +1,208 @@
+\documentclass[11pt,a4paper, final, twoside]{article}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\usepackage{amsmath}
+\usepackage{fancyhdr}
+\usepackage{amsthm}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{amscd}
+\usepackage{latexsym}
+\usepackage{graphicx}
+\usepackage{graphics}
+\usepackage{natbib}
+\usepackage[colorlinks=true, urlcolor=blue, linkcolor=black, citecolor=black]{hyperref}
+\usepackage{color}
+\usepackage{natbib}
+\usepackage{sectsty}
+\usepackage{subcaption}
+\usepackage{caption}
+\usepackage{indentfirst}
+\setcounter{MaxMatrixCols}{10}
+
+
+
+\sectionfont{\fontsize{12}{15}\selectfont}
+
+\renewcommand{\thefootnote}{}
+\setlength{\oddsidemargin}{1pt} \setlength{\evensidemargin}{1pt}
+\setlength{\hoffset}{-1in} \addtolength{\hoffset}{25mm}
+\setlength{\textwidth}{140mm}
+\setlength{\marginparsep}{0pt} \setlength{\marginparwidth}{0pt}
+\setlength{\topmargin}{0pt}
+\setlength{\voffset}{-2in} \addtolength{\voffset}{20mm}
+\setlength{\textheight}{260mm}
+\setlength{\headsep}{20mm}
+\setlength{\footskip}{15mm}
+\pagestyle{fancy}
+\fancyhead{} \fancyfoot{}
+
+
+
+% Theorem environments
+\newtheorem{thm}{Theorem}[section]
+\newtheorem{algorithm}[thm]{Algorithm}
+\newtheorem{axiom}[thm]{Axiom}
+\newtheorem{lem}[thm]{Lemma}
+\newtheorem{example}[thm]{Example}
+\newtheorem{exercise}[thm]{Exercise}
+\newtheorem{notation}[thm]{Notation}
+\newtheorem{problem}[thm]{Problem}
+\theoremstyle{proposition}
+\newtheorem{prop}{Proposition}[section]
+\newtheorem{case}[thm]{Case}
+\newtheorem{claim}[thm]{Claim}
+\newtheorem{conclusion}[thm]{Conclusion}
+\newtheorem{condition}[thm]{Condition}
+\newtheorem{conjecture}[thm]{Conjecture}
+\newtheorem{cor}[thm]{Corollary}
+\newtheorem{criterion}[thm]{Criterion}
+\theoremstyle{definition}
+\newtheorem{defn}{Definition}[section]
+\theoremstyle{remark}
+\newtheorem{rem}{Remark}[section]
+\newtheorem{solution}[thm]{Solution}
+\newtheorem{summary}[thm]{Summary}
+\numberwithin{equation}{section}
+\renewcommand{\rmdefault}{phv} % Arial
+\renewcommand{\sfdefault}{phv} % Arial
+\pagenumbering{arabic} % 1, 2, 3, 4, ...
+
+\input{macros}
+
+
+\begin{document}
+\hyphenpenalty=100000
+
+
+\sloppypar
+
+\begin{center}
+
+{\Large \textbf{\\User Customization of Caregiving Robots that \\Support Older Adults with Dementia}}\\[5mm]
+{\large \textbf{Zehui (Joyce) Zhou}\\[1mm]}
+{\normalsize \emph{Under the supervision of Professor Sheila McIlraith,\\ Dr.\ Steven Shapiro, and Dr.\ Richard Valenzano}\\[1mm]}
+\end{center}
+
+
+\section{Introduction}\label{I1}
+Dementia affects more than 35 million people worldwide, and the number is still growing dramatically. Dementia affects people's ability to live independently, thus many dementia patients face the prospect of being institutionalized. As home care is often costly, we are investigating the development of an affordable socially assistive robot to support cognitively impaired older adults with daily living activities, which will potentially extend their time living at home.
+
+To communicate with patients effectively, a caregiving robot should tailor its interactions to its interlocutors, taking into account the nature and degree of cognitive impairment, other health issues, and individual preferences.
+\section{Approach}\label{I2}
+We equipped the robot with a knowledge base embodying ``best practices'' for communicating with different classes of individuals \cite{practice1,practice2, rochon, web1, web2, web3}. Upon delivery, the knowledge base can be augmented with (some) information about the people with whom the robot is expected to interact. When communicating with an individual, the robot uses the knowledge base to determine a customized strategy.
+
+People with dementia often have difficulty completing daily tasks.
+In this work, we customized the interactions of the robot with users of the COACH system, which provides assistance to complete the task of handwashing~\cite{COACH}.
+COACH tracks the user's hand positions to ensure that he or she is following a proper sequence to wash their hands.
+If COACH determines that the user is having difficulty, it will provide audio or video instructions, called \emph{prompts}. These prompts are then customized by our system.
+
+\section{Implementation}\label{I3}
+COACH uses a POMDP-based \emph{Task Manager} to estimate the user's progress and determine the next prompt.
+The prompt is then processed by the \emph{Executor} which plays a pre-recorded audio or video clip
+(see Fig.~\ref{fig:COACH}).
+
+To customize the behaviour of COACH, we deployed a \emph{Prompter} which reasons using features stored in the knowledge base to adapt the prompt for the user.
+We also modified the Executor so that it could use the output of the Prompter to dynamically generate an appropriate audio clip, rather than simply using a pre-recorded one (see Fig.~\ref{fig:COACH_with_customization}).
+\begin{figure}[h!]
+ \centering
+ \includegraphics[width=0.8\textwidth]{COACH_prompt.png}
+ \caption{The original COACH system.}
+ \label{fig:COACH}
+\end{figure}
+\begin{figure}[h!]
+ \centering
+ \includegraphics[width=0.8\textwidth]{COACH_with_customization_prompt.png}
+ \caption{COACH system with customization.}
+ \label{fig:COACH_with_customization}
+\end{figure}
+\par
+%\noindent The \textbf{Prompter} is the module deciding how should a customized prompt be carried out.\\ % duplicates earlier info
+\emph{Universal parameters} --- such as prompt detail level, volume, voice type, and speed --- are determined using the knowledge base.
+Using these parameters, the prompt from the Task Manager, and other relevant information (e.g., how the user likes to be addressed, what kind of soap is in the environment), the Prompter generates a customized prompt and mode of delivery. This allows for different types of prompts for different users and situations.
+%The \textbf{Executor} is responsible for content display and voice generation. IBM's \textbf{Watson} is then used to synthesize the audio clip.
+The Executor then uses IBM's Watson to synthesize the audio clip (see Fig.~\ref{fig:arch}).
+\begin{figure}[h!]
+ \centering
+ \includegraphics[width=0.8\textwidth]{prompter.png}
+ \caption{The architecture of the Prompter.}
+ \label{fig:arch}
+\end{figure}\\
+
+\section{Illustrative Examples}\label{I4}
+The original COACH system does not take the user and the environment into consideration.
+Consider the following example prompt, in which the Task Manager decides the user should turn on the tap.
+\begin{center}
+{\color{red} Original COACH Pre-recorded Prompt}
+\end{center}
+\begin{center}
+\textbf{\textit{``Try pulling the silver lever towards you."}}
+\end{center}
+\noindent Now, we show three examples of prompts that our system generates instead, depending on individual circumstances. Note that both the content and mode of delivery vary according to the individual.
+\begin{center}
+ {\color{red}Customized Prompts Based on Context}
+\end{center}
+
+{\bf Scenario 1:} The user is an elderly woman that has severe dementia and hearing difficulty.
+\begin{center}
+\textbf{\textit{``Ms.\ Marth, now turn on the tap.''}}
+\end{center}
+%\begin{flushright}
+The user is addressed formally (as desired) using a short sentence. This prompt is generated using a
+low-pitched voice, high volume, and slow speed.\\
+%\end{flushright}
+%She was addressed formally (as desired) using a short sentence.\\
+
+{\bf Scenario 2:} The user is an elderly Spanish-speaking woman with mild dementia and mild hearing difficulty.
+\begin{center}
+\textbf{\textit{``Se\~nora Abar, saque un poco de agua.''}}
+\end{center}
+%
+The user is addressed formally in Spanish (as desired)
+using a short sentence. This prompt is generated using normal volume and normal speed.\\
+
+{\bf Scenario 3:} The user is a 4 year-old girl.
+\begin{center}
+\textbf{\textit{``Vivian, now turn on the tap. Be careful with the hot water.''}}
+\end{center}
+%\begin{flushright}
+The user is addressed by first name using multiple sentences,
+with a high-pitched voice, normal volume, and normal speed.
+%\end{flushright}
+Being a child, she was also reminded of potential danger.
+
+%In all the cases, we believe the customized prompt is better suited for the situation at hand.
+
+\section{Evaluation}
+To evaluate the effectiveness of the customizations, we propose using the following criteria.
+
+\emph{Effectiveness}: Effectiveness measures how successful our approach is at helping users complete the handwashing task? We plan to evaluate this in trials by measuring the success rate of completing the task, and the number of prompts used per session.
+
+\emph{Satisfaction}: Satisfaction measures how satisfied users feel with the help provided by the robot. We would use a questionnaire completed by the user(s) and/or expert observers to provide feedback on individual satisfaction with the robot's behaviour.
+
+These kinds of evaluations require human trials. Due to the need for ethics approval, the evaluation is left for future work.
+
+\section{Conclusion}
+We customized the daily task of handwashing to demonstrate how human-robot interaction can be tailored using a knowledge base embodying best practices, taking into account individual circumstances and preferences. Our customizations adapt the robot's interactions to the nature and degree of cognitive impairment, other health issues, as well as personal preferences, such as language choice.
+
+%Due to the scope of hand-washing task, the customization is limited. The customization we implemented failed to show the potential of tailor its behaviour with respect to user's preference.
+
+\section{Future Work}
+% work shows the potential and limitation of customization of handwashing task using knowledge base. There are some works should be done in the future.
+We plan to explore the use of Reinforcement Learning to adapt customizations through interaction with the user. Since people's preferences and impairments can change over time, and the initial knowledge base may require some tuning, the robot should be able to learn about its users and incorporate the new knowledge into its interactions.
+
+As our goal is to create a socially assistive robot to support cognitively impaired older adults with daily living activities, the robot may need to help with different kinds of activities, such as tea or meal preparation.
+The system can also be expanded to use other languages than English or Spanish.
+Finally, our customization techniques should undergo evaluation. We have discussed some strategies for evaluation above, however we will investigate other strategies as well, and evaluate the system.\\
+
+
+\noindent \textbf{Acknowledgements}\\
+
+\noindent We would like to thank our collaborators: CrossWing Inc.; Professor Alex Mihailidis and team at the Toronto Rehabilitation Institute; Professor Goldie Nejat and team in Mechanical and Industrial Engineering at the University of Toronto; and Professor Fran\c{c}ois Michaud and team at the University of Sherbrooke. We also wish to thank Dr.~Elizabeth Rochon from the Toronto Rehabilitation Institute for her expert advice on suitable strategies for communicating with persons with dementia.
+Computations were performed on the SOSCIP Consortium's Cloud Data Analytics computing platform. SOSCIP is funded by the Federal Economic Development Agency of Southern Ontario, the Province of Ontario, IBM Canada Ltd., Ontario Centres of Excellence, Mitacs and 15 Ontario academic member institutions.
+
+
+\bibliography{extended_abstract}
+\bibliographystyle{unsrt}
+
+\end{document}
+
diff --git a/assets/2017/Z.Zhou/prompter.png b/assets/2017/Z.Zhou/prompter.png
new file mode 100644
index 0000000..50517a6
Binary files /dev/null and b/assets/2017/Z.Zhou/prompter.png differ
diff --git a/css/masthead.css b/css/masthead.css
index 517821b..0d63460 100644
--- a/css/masthead.css
+++ b/css/masthead.css
@@ -8433,7 +8433,7 @@ figcaption {
border-left: 4px solid #00525a !important; }
.header-background {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-position: center; }
.review-subtitle {
@@ -8445,7 +8445,7 @@ figcaption {
padding: 0 !important; }
.page-footer {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
margin: 0px !important;
min-height: 100px;
padding: 30px 0 30px 0 !important; }
diff --git a/css/page/masthead.css b/css/page/masthead.css
index 1227510..de6a108 100644
--- a/css/page/masthead.css
+++ b/css/page/masthead.css
@@ -8397,7 +8397,7 @@ figcaption {
border-left: 4px solid #8c333d !important; }
.header-background {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-position: center; }
.review-subtitle {
@@ -8409,7 +8409,7 @@ figcaption {
padding: 0 !important; }
.page-footer {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
margin: 0px !important;
min-height: 100px;
padding: 30px 0 30px 0 !important; }
@@ -8430,7 +8430,7 @@ figcaption {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100vw; }
@@ -8449,7 +8449,7 @@ figcaption {
@media only screen and (min-width: 651px) and (max-width: 992px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100%; }
@@ -8508,7 +8508,7 @@ figcaption {
@media only screen and (max-width: 650px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover; }
.collapsible-toc {
diff --git a/css/post.css b/css/post.css
index ae35583..09f3d12 100644
--- a/css/post.css
+++ b/css/post.css
@@ -8397,7 +8397,7 @@ figcaption {
border-left: 4px solid #8c333d !important; }
.header-background {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-position: center; }
.review-subtitle {
@@ -8409,7 +8409,7 @@ figcaption {
padding: 0 !important; }
.page-footer {
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
margin: 0px !important;
min-height: 100px;
padding: 30px 0 30px 0 !important; }
@@ -8430,7 +8430,7 @@ figcaption {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100vw; }
@@ -8449,7 +8449,7 @@ figcaption {
@media only screen and (min-width: 651px) and (max-width: 992px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover;
width: 100%; }
@@ -8508,7 +8508,7 @@ figcaption {
@media only screen and (max-width: 650px) {
.background {
height: 100vh;
- background: url("../resources/backgroundweb2016.svg");
+ background: url("../resources/backgroundweb2017.png");
background-size: cover; }
.collapsible-toc {
diff --git a/css/style.css b/css/style.css
index bc294ba..35683cf 100644
--- a/css/style.css
+++ b/css/style.css
@@ -8230,7 +8230,7 @@ button.picker__today:focus, button.picker__clear:focus, button.picker__close:foc
/* ==========================================================================
$BASE-TIME-PICKER
- ========================================================================== */
+ ==================================================2017======================== */
/**
* The list of times.
*/
@@ -8607,6 +8607,7 @@ figcaption {
color: #8c333d;
text-transform: none;
font-weight: bold;
+ word-wrap: break-word;
}
.toc-enum {
@@ -8711,4 +8712,9 @@ figcaption {
/*# sourceMappingURL=style.css.map */
#submit-button {
padding-bottom: 100px;
+}
+
+.row-center-fix {
+
+ width: 80%;
}
\ No newline at end of file
diff --git a/_includes/news.html b/_includes/news.html
index 2b7e1c7..7e55219 100644
--- a/_includes/news.html
+++ b/_includes/news.html
@@ -14,6 +14,4 @@
-
+
+
+
+
+
+
+
+
+ 
+
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+
+
+
+
+
+
+
+ 
+ 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+