Hello, I'm Neil! I'm currently a software engineer working on [Earth](https://earth.google.com/web/) and [tools for sustainability](https://sustainability.google/) at Google in NYC.

Previously, I worked in [Gοldman Sаϲhs' Electroniϲ Trading](https://www.goldmansachs.com/what-we-do/ficc-and-equities/gset-equities) division and its Structured Products spinout [SIMON](https://www.simonmarkets.com/simon/).

Before that, I studied computer science at Columbia University, where I also built robot [hardware](/blog/tshirt) and [software](https://roscon.ros.org/2019/talks/roscon2019_fetchitthemobilemanipulationchallengeresults.pdf).


# Mushroom & thyme whole wheat milk bread with provolone
## 03/06/21

![](/images/bakes/18.jpg)

---

# Carrot cake
## 02/03/21

![](/images/bakes/16.jpg)

---

# Cheesecake
## 02/03/21

![](/images/bakes/17.jpg)

---

# More-whole-wheat bread
## 01/30/21

![](/images/bakes/13.jpg)

# Walnut & cinnamon raisin bread
## 01/30/21
![](/images/bakes/14.jpg)

![](/images/bakes/15.jpg)

---

# Lemon, blueberry, and greek yogurt whole wheat almond cake
## 01/24/21

![](/images/bakes/12.jpg)

---

# Banana bread
## 01/23/21 

![](/images/bakes/11.png)

---

# Lemon meringue cupcakes
## 01/16/21

![](/images/bakes/10.jpg)

---

# Milk bread
## 01/10/21

![](/images/bakes/7.jpg)

![](/images/bakes/5.jpg)

![](/images/bakes/3.jpg)

---

# Challah bread
## 01/06/21
![](/images/bakes/2.jpg)

![](/images/bakes/9.jpg)

---

# Challah bread
## 01/03/21

![](/images/bakes/8.jpg)

![](/images/bakes/1.jpg)


---

# Sponge cake
## 12/31/20

![](/images/bakes/4.jpg)

---

# Coconut raisin brioche
## 12/29/20

![](/images/bakes/6.jpg)




I tracked my mood every day in 2024 in a spreadsheet.

![](/images/mood/sheet.png)

At the end of every day, I recorded a number from 1 to 5, where 1 was a terrible day and 5 was the best day realistically imaginable.

![](/images/mood/year.png)

I had a few `1`s:
- **January 23rd, 2024**: Intense stomach pain, no sleep, and brain fog.
- **May 14th, 2024**: I was running outside when I felt a sudden excruciating pain in my knee. A few days later I got an MRI that imaged a case of quadriceps tendonitis. No training for the next 2 months!
- **September 22nd, 2024**: At the end of another easy run, my left knee was suddenly painful to bend. Another MRI, and a case of [patellofemoral pain syndrome (runner's knee)](https://my.clevelandclinic.org/health/diseases/17914-patellofemoral-pain-syndrome-pfps).

And some `5`s:
- **July 14th, 2024**: I received the [NSF CSGrad4US fellowship](https://cra.org/csgrad4us/?gad_source=1&gclid=Cj0KCQjwnui_BhDlARIsAEo9GuuW4J13x136geZLayVvD9gB3csFUOzWM_jG1vRIhD0I_ht5IJVfg-QaAnYUEALw_wcB).
- **November 3rd, 2024**: I finished the NYC Marathon in 3 hours 30 minutes, just short of my goal but better than expected given knee issues.

but what constitutes a `5` [can change over time](https://sashachapin.substack.com/p/10x-happiness-increases-are-possible).


The brachistochrone problem asks:

> What path yields the shortest duration for a ball to roll from A to B?

The shortest path from A to B is a straight line, but it's actually not the fastest path:

![](/images/jax/optimal.gif)

We can get better results by accelerating the ball down a steeper path at first, then taking a bit of a loss as the ball rolls down the more shallow latter part of the path. The optimal solution to this problem is a cycloid. Can we arrive at the optimal path numerically instead? What if we use gradient descent?

JAX is a library that provides a `numpy`-like API, but automatically differentiable and following the functional programming paradigm. JAX lets us easily compute the gradient of a function written in `numpy`-like syntax, for example:

```py
def f(x):
	return jnp.sum(x**2)

x = jnp.array([0., 1., 2.])
grad_f = jax.grad(f)
print(grad_f(x)) # [0., 2., 4.]
```

Being able to evaluate the gradient with just a single `grad` function call means we can just as easily evaluate the gradient of a function that computes the time for a ball to roll down a curve. The inputs to our function can be the curve itself, which we'll represent as an array of `y`-values corresponding to equally-spaced `x`-values. In other words, the value of the `i`-th element in the array `ys` is the height of our experimental curve at `x=i`.

```py
# Computes the time to each segment at heights specified by `ys`
def t(xs, ys):
  vs = jnp.sqrt(2 * G * (Y_0 - ys)) # velocity
  midpt_v = (vs[1:] + vs[:-1]) / 2. # velocity at the midpoint of each arc length
  dys = ys[1:] - ys[:-1] # difference between heights for each segment
  dx = xs[1] - xs[0]
  arc_lengths = jnp.sqrt(jnp.power(dx, 2) + jnp.power(dys, 2)) # euclidean distance as arc length
  return jnp.cumsum(arc_lengths / midpt_v) # sum times as t approaches infinity
```

If we repeatedly nudge the curve in the direction of this gradient, we should converge on an optimal solution to the brachistochrone problem. We already wrote an automatically differentiable (thanks to JAX) function to evaluate the time `t` it takes for the ball to roll from the start to the end of our curve. Now let's find out how to nudge each element in `ys` in order to minimize `t`:

```py
def loss(params):
  ts = t(xs, params)
  t_final = ts[-1]
  return t_final

loss_grad = jax.grad(loss)

def optimize(params, LR=0.01, N_STEPS=1000):
  for _ in range(N_STEPS):
    grads = loss_grad(params)
    params = jnp.concatenate([
      jnp.array([Y_0]),
      params[1:-1] - (LR * grads[1:-1]),
      jnp.array([0])
    ])

N_STEPS = 3000
LR = 0.02
optimize(ys, LR=LR, N_STEPS=N_STEPS)
```

Our solution should roughly converge on the optimal path:

![JAX optimization of the brachistochrone curve](/images/jax/brachistochrone.gif)



FIX (**F**inancial **I**nformation E**x**change) is a protocol for (financial) securities-related communication. FIX specifies a presentation- and application-layer protocol: it dictates how messages can be encoded, and what their contents can be. In many use cases FIX is like the electronic version of the open outcry and post-it note passing of trading prior to electronification: it handles messaging between traders, exchanges, custodians, clearinghouses, and the other entities involved in securities markets.

Over 10TB of FIX data are generated daily, ranging from security definitions to orders to market data.

## An example

Here's an example of how people use FIX: you, a registered representative at `$INVESTMENT_FIRM`, want to place a trade in `AAPL`. You open a ticket in your trading platform; then you enter a quantity, side, a few other parameters, and hit `SUBMIT`. 

Your trading platform sends a FIX message to `$BROKERDEALER`:

```
8=FIX.4.4 | 9=148 | 35=D | 34=1080 | 49=TESTBUY1 | 52=20180920-18:14:19.508 | 56=TESTSELL1
| 11=63673064027889863415=USD21=2 | 38=7000 | 40=1 | 54=1 | 55=AAPL | 
60=20180920-18:14:19.492 | 10=092 |
```

This is a plaintext ASCII message. Your trading platform sends it over TCP/IP to a FIX server in `$BROKERDEALER`'s server farm in New Jersey. The message encodes all the relevant information about this buy order in tag-value format: a **tag** is a specific field in the FIX schema, and a **value** is whatever value your trading platform assigned to that tag. For example,

* Tag-value pair `35=D` tells `$BROKERDEALER`'s FIX server that the incoming message is a FIX `NewOrderSingle`, or a new order in a single security; application developers might refer to this tag as `MsgType(35)`. 
* Tag-value pair `55=AAPL` (`Symbol(55)`) tells `$BROKERDEALER`'s FIX server that the new order is for symbol `AAPL`.
* Tag-value pair `38=7000` means that this order is for quantity `7000` (shares) of AAPL.
* Tag-value pairs `8=FIX4.4` and `9=148` give the FIX schema version (4.4) and body length, respectively. Body length is the number of characters in the message, including deliimiters and excluding tags `8`, `9`, and `10`.
* Tag-value pair `10-092` is the FIX checksum, which validates and terminates any FIX message. The checksum is the sum of all bytes in the message, mod 256.
* Tag-value pair `34=1080` is the sequence number. Sequence numbers should always be incremented by 1 between messages; a dropped sequence number indicates that messages were missed, in which case some FIX engines will automatically send a `ResendRequest(7)` to ask for the missing message(s).

This message format is sufficient for most use cases. Sometimes, ASCII-encoded and pipe-delimited messages (or XML for that matter) are too heavy. At the presentation-layer there are other ways to encode FIX messages (e.g. [Simple Binary Encoding](https://www.fixtrading.org/standards/sbe-online/#examples)). 

Regardless of encoding, the FIX protocol assumes ordered delivery of messages -- that is, `$BROKERDEALER`'s FIX server assumes it will receive messages in the order that `$INVESTMENT_FIRM`'s trading platform sent them. Ordered delivery (or session failure) is guaranteed by a combination of sequence numbers and `Ack`/`Response` messages.

## Establishing & maintaining a connection

Some things have to happen so that you, registered representative at `$INVESTMENT_FIRM`, can hit `SUBMIT` in trading platform and expect an order to be placed. Sometime early in the morning, your trading platform probably initiated a FIX session with `$BROKERDEALER`'s FIX server by sending a `Logon(A)` message:

```
8=FIX.4.2|9=76|35=A|49=BuySide|56=SellSide|34=1|52=20190605-11:27:06.897|98=0|108=30|141=Y|10=008|
```

![](https://www.onixs.biz/hubfs/fix-dictionary/images/successful-logon.png)

Tag `HeartBtInt(108)` specifies the interval, in seconds, between heartbeat messages. 

## The full trade processing lifecycle

The FIX protocol plays a crucial role throughout the entire trade processing lifecycle, from the initial order placement to the final settlement:

1.  **Order Origination:**
    * The process begins when a trader or an automated trading system decides to place an order.
    * A **New Order - Single (MsgType = D)** message is generated. This message contains all the necessary details of the order, such as the security symbol (Tag 48), side (buy or sell - Tag 54), order quantity (Tag 38), price (Tag 44), order type (e.g., limit, market - Tag 40), and time-in-force (how long the order remains active - Tag 59).
    * This message is sent from the buy-side (e.g., an investment firm) to the sell-side (e.g., a broker) or directly to an exchange or trading venue.

2.  **Order Routing:**
    * Upon receiving the New Order - Single message, the sell-side broker's systems determine the best execution venue for the order based on various factors like price, liquidity, and regulatory requirements.
    * FIX messages are used internally within the broker's infrastructure to route the order to the appropriate exchange or Electronic Communication Network (ECN).
    * Sometimes, a **New Order - Cross (MsgType = s)** or other specialized order messages might be used for specific routing scenarios.

3.  **Order Execution:**
    * When the order reaches the execution venue and a matching counterparty is found, the trade is executed.
    * The execution venue sends an **Execution Report (MsgType = 8)** back to the sell-side broker. This crucial message provides details of the execution, including the fill quantity (Tag 38), average price (Tag 6), last fill price (Tag 31), and execution ID (Tag 17).
    * The sell-side broker, in turn, forwards the Execution Report to the originating buy-side client, keeping them informed of the trade's status. Partial fills may result in multiple Execution Reports.

4.  **Confirmation and Allocation:**
    * Following execution, further FIX messages are used for confirmation and allocation, especially for institutional trades where a single order might be allocated to multiple accounts.
    * **Confirmation (MsgType = AG)** messages are exchanged between the executing broker and the confirming party (often a central matching utility or the buy-side firm itself) to agree on the details of the trade.
    * For allocation, the buy-side firm might send an **Allocation Instruction (MsgType = J)** to the sell-side broker, specifying how the executed quantity should be distributed across different accounts. The broker then responds with an **Allocation Report (MsgType = R)** confirming the allocations.

5.  **Clearing and Settlement:**
    * While FIX is primarily focused on pre-trade and trade execution communication, the information contained within FIX messages is vital for the subsequent clearing and settlement processes.
    * Clearinghouses use the trade details communicated via FIX (often translated into other formats) to match trades and manage post-trade risk.
    * Settlement instructions, detailing how the transfer of funds and securities will occur, are often derived from the information exchanged through FIX during the earlier stages of the lifecycle.

6.  **Post-Trade Reporting:**
    * Even after settlement, FIX can be used for various post-trade reporting purposes.
    * **Trade Capture Report (MsgType = AE)** messages can be used to provide a comprehensive record of executed trades.
    * Regulatory reporting obligations often rely on the data initially communicated through FIX messages.




One of the tools I wish I'd known about sooner is [vim-repl](https://github.com/sillybun/vim-repl). It's a `vim` plugin that opens an interactive REPL, configurable based on source file type (`.py`, `.hs`, `.scala`, ...)

> A REPL, or read-eval-print-loop, lets you input, evaluate, and output expressions without having to (for example) compile an entire program.

I used to run this workflow using [SLIME](https://github.com/jpalardy/vim-slime) and `tmux`. Before that, if I wanted a development environment with a tight feedback loop between writing & evaluating code, I defaulted to a Jupyter notebook -- which, for this purpose, is probably both the wrong tool to use and often (for me) [unsustainable](https://medium.com/@_orcaman/jupyter-notebook-is-the-cancer-of-ml-engineering-70b98685ee71).

I can launch this environment quickly thanks to some keybindings: `,r` to open the REPL, and `,w` to send code over. Here's `vim-repl` in action:

{{< rawhtml >}}
<script id="asciicast-klutuZxLwIWFb8zd4Mxx4oaBs" src="https://asciinema.org/a/klutuZxLwIWFb8zd4Mxx4oaBs.js" async></script>
{{< /rawhtml >}}



I wrote 39,000+ words across 223 entries in my diary in the last 1.5 years. Could I learn more about my mood/emotions by analyzing my diary? I wrote some Python to find out. [(skip to results)](#results)

---

## The data

Diary entries are usually emotive and abstract. Below I describe an approach to quantifying my mood over the last 1.5 years. This dataset consists of diary entries written either when I was attending college or working full-time. All of my diary entries share the following properties:

1. Time of last update (for example: `January 10th, 2018, at 7:20pm`)
2. Name of entry (for example: `happy-to-see-you.txt`)
3. Text content (the actual entry)

## Sentiment analysis
I quantify the content of each diary entry by its __sentiment__: how positive or negative I felt in each entry. __Sentiment analysis__ is an approach to automatically identifying opinions/feelings in a text. My pipeline has 3 steps, all using some subset of `numpy`, `pandas`, and `matplotlib`.

1. __Data cleanup.__ I filter out _stop words_. In natural language processing, _stop words_ are tokens like `a`, `of`, `the`. These common words are syntactically important for language, but they carry little information and aren't useful for sentiment analysis.
2. __Lookup sentiment in the Emotion Lexicon.__ The [NRC Word-Emotion Association Lexicon](https://saifmohammad.com/WebPages/NRC-Emotion-Lexicon.htm) maps an index of 14,000+ words to eight basic emotions: anger, fear, anticipation, trust, surprise, sadness, joy, and disgust. I simply look up a word in the Emotion Lexicon and retrieve its associated emotion, for all 39,000 words in my diary.
3. __Classify sentiment with `word2vec`.__ Many words in my diary aren't catalogued in the Emotion Lexicon, so I trained a classifier using `word2vec` and `sklearn.linear_model.LogisticRegression` to identify the sentiment of almost all the remaining words.

---

## Results
### Overview
Like most people, I usually write about myself or other people. Since we filtered out _stop words_, common but relatively meaningless tokens like `on`, `for`, etc. are omitted. Below are the top 20 words which occur most frequently in my diary, dominantly concerning topics like `thinking` and `people`.

![overview1](/images/diary/overview_1.png)

Most of my diary entries are under 200 words. The most significant outlier, at 3,278 words, is about distractions and a short attention span. At bottom left, I bin diary entries based on word count. At bottom right, the horizontal axis is the time domain, and each point represents 1 of my 223 diary entires (with the 3,278-word outlier on Nov 2018).

![overview2](/images/diary/overview_2.png)

### Weekly trends
I write the most on the weekends. As the week progresses, I spend more time studying/working, and consequentially less time writing. On Saturdays, I apparently unload all that's accumulated during the week.

![weekly1](/images/diary/weekly_trends_1.png)

Compared to the mean, on Thursdays (my most negative day) I'm more negative by a delta of 4.7%. Sorry to everyone I hung out with on Thursdays. As expected, positive and negative sentiment are inversely related and tend to settle at a more positive mood during the weekend.

![weekly2](/images/diary/weekly_trends_2.png)

The __NRC Word-Emotion Association Lexicon__ lets us look at other emotions too. As shown below, throughout the week I consistently anticipate the arrival of the weekend. Similarly, sadness achieves a maximum in the middle of the business week, then steadily declines as we approach the weekend. That seems consistent with reality:

![weekly3](/images/diary/weekly_trends_3.png)

### Long-run trends

As approximate metrics of mood, the intensity of positive and negative sentiment are both normally distributed. Negative sentiment has a slightly left-skewed distribution, with a long-tail on the left. Sentiment is normalized to the length of each diary entry.

![longrun1](/images/diary/long_run_2.png)

Below I show the total sentiment (`positive sentiment - negative sentiment`) expressed in my diary. This provides a rough metric of positive (`sentiment>0`) or negative (`sentiment<0`) mood. Total sentiment takes a value between -1.0 and +1.0. Over 1.5 years my mood (as measured by positive/negative sentiment) has steadily tended towards more positive sentiment. I take the rolling mean of each sentiment score over a 1-week, 1-month, and 3-month window:

![longrun2](/images/diary/long_run_1.png)

Mood in the past 1.5 years as measured by total sentiment is fairly volatile, with standard deviation `0.298` for sentiment in the range `-1.0` to `1.0`. `95%` of diary entries have a total sentiment score that lies within 2 standard deviations of the mean sentiment (consistent with the normality of the distribution of positive and negative sentiment).

If my mood (as measured by sentiment) reverts to the mean, then even when sentiment drifts towards the positive or negative extreme I can expect it to settle back towards the mean. Knowing whether mood is mean-reverting might allow me to reduce the stress I experience during periods of negative mood. We can test whether mood is reverts to the mean in the long run with a quick stationarity test. Using the augmented Dickey-Fuller test (`statsmodels.tsa.adfuller`), we find that total sentiment is mean-reverting (`p<0.05`).

---

## Conclusions

Based on my diary, my mood as measured by total sentiment is mean-reverting and most positive during the weekends but otherwise fairly volatile. None of this analysis offers a concrete statement about my mood, though, since the approach is crude and my approach fails to capture some relevant information.

In summary I didn't learn much from this, and I've got a lot of statistics to review. But the graphs are pretty, right?



In my first year of college, a friend and I built a 100lb. t-shirt shooting robot to drive around & eject shirts into crowds. We were very fortunate to get a bit of money from a student group on campus, access to the Columbia University MakerSpace, and a few dumpsters with nice DC motors and aluminum extrusion sitting around.

![](/images/tshirt/shooter.jpeg)
![](/images/tshirt/1.png)

We spent a few months on-and-off between CAD, the machine shop, and our laptops. Here's a linear actuator we designed to be powered by a `12V` car window motor:

![](/images/tshirt/3.gif)

The whole assembly in CAD was built from several hundred custom & stock assets:

![](/images/tshirt/2.gif)

---

![](/images/tshirt/image14.png)
![](/images/tshirt/image15.png)
![](/images/tshirt/image16.png)
![](/images/tshirt/image17.png)
![](/images/tshirt/image18.png)
![](/images/tshirt/image19.png)
![](/images/tshirt/image20.png)
![](/images/tshirt/image21.png)
![](/images/tshirt/image22.png)
![](/images/tshirt/image23.png)

Neil Chen

Projects

Tracking my mood every day for 1 year

Finding the brachistochrone with JAX

Analyzing 1.5 years of diary entries

Building a T-shirt shooting robot

Notes

Overview of the FIX messaging protocol