One more robot learns to see

An Over-Engineered Travel Blog

Fri, 17 Mar 2023 00:00:00 +0000

Most people would just have a pin board to hang on the wall and track their travels by adding new pins for each trip; I have a custom ReactJS component which plots trips from a set of JSON files acting as a sort of database.

The locations on the map are clickable for more details like the place and date. In the top right there is a layer control I recently added to toggle on and off different datasets like Sam's and my childhood trips.

I created kevinandsam.travel back in 2018 when my partner and I quit our jobs to follow our dream of backpacking around the world. We traveled to 31 countries across 4 continents over the course of 14 months - the experience of a lifetime. I often worked on the site among other projects along with some consulting work in the downtime between destinations. I loved being a nomad but I also realized that too much work can detract from the true purpose of long-term travel and I would encourage anyone considering this lifestyle to save up more and work less.

The site is built with GatsbyJS. I’d used a couple of static site tools in the past (Middleman and Jekyll for this blog) and I wanted to try something new this time. Gatsby caught my attention because of how it combines React, server side rendering, rehydration and preloading for subsequent page navigation. This blog achieves a similar result using Turbolinks on top of Jekyll but it is cool to see this functionality as part of the framework.

The framework delivered great performance which is best illustrated through a typical user visit:

The first page loads a completely server rendered HTML page with inlined CSS and an initial JS bundle. For kevinandsam.travel the home page is 16kb of HTML and ~100kb of Javascript. Thanks to rehydration the app behaves like a React app going forwards.
Hovering over the “Map” link in the nav bar preloads 3 more Javascript files and a page data JSON file. These files total ~60kb and include the additional Javascript required for the Map. If we inspect the files we can see most of the size is coming from leaflet.
For comparison if we hover over “About Us” only two Javascript files totalling ~10kb are preloaded.
When a link is clicked the navigation to the new page is quick and smooth because the data and code has been pre-fetched.

More important than the measured performance the site feels fast thanks to smart animation of the content. Anecdotally it is fast everywhere in the world - at least everywhere I’ve tried :wink:.

Another reason I picked Gatsby is React itself. I had a few features in mind for the site which I knew would be easier to build using open source components. In my opinion, this is one of the main benefits of React, especially for solo projects or small teams, it is so much better and easier to grab off the shelf UI pieces and integrate them than in the old jquery days. One of these features is the Come Visit form which has a country dropdown and a datepicker powered by the same data that draws the map.

The conversational response that fades in after making a selection has links to send an email with a pre-filled subject and to Google flights with the destination airport pre-filled. It used to set the dates too but Google doesn't accept dates in the past so it doesn't anymore.

Having our route data in a structured JSON format was also useful for planning while we were travelling. I had a few scripts I used to quickly convert dates into durations at each location. It was often much easier to think in terms of how many days we wanted to spend somewhere than in dates. This script enabled an iterative workflow where I could print the durations while tweaking dates and see where everything landed. This was also useful to arrange meeting people in certain places and times as well as managing seasonal constraints.

Another nice feature of Gatsby is the image plugins. The site is very image heavy and the framework handles pre-processing and resizing of images at build time which makes it easier to manage assets. I can commit the full size images and then resize appropriately during the build but crucially it is easy to change the size at any time. Gatsby also automatically creates inlined placeholders for images while they load for a nice effect.

Later in the development, I added custom markdown components with rehype (and even later migrated to MDX) which after a mildly painful setup made writing posts featuring advanced layouts and photo carousels a blast. Overall, I have been pretty happy with the framework - I got the result and performance I wanted but occasionally I did have to fight with confusing build errors.

The newest addition to the blog is a re-presentation of our social media posts from our trip. While I have mixed feelings about social media, I value the content we shared about our journey and the connections it facilitated. To reduce my dependence on these platforms I decided to preserve the posts that matter to me on my own blog. This way I can maintain control over the content and have one less reason to keep my accounts.

I started by exporting my data and rebuilding my Facebook feed. I’ve used a few of these export tools and I am always impressed with the data I receive back, it wasn’t a drop in but with a minimal python script I could easily filter and transform the data into something appropriate for a Gatsby source. The initial feed was pretty straight forward to build thanks to react-photo-album and Gatsbygram for an infinite scroll example. The toughest part was drawing a nice arc on the map for the “travelling to” posts. After getting my cloned feed working I was able to take things further and add functionality to search, filter and change the order.

I had to rig up a setTimeout and fiddle with some parameters to actually capture the loading spinner for this gif. The production parameters load more in advance and the user never sees the spinner for a very true infinite scroll experience.

Instagram was the harder of the two to build. I re-used quite a bit of the import logic and basic component setup but the modal I wanted required new state and logic. Getting the styling right and maximising the space used by the image in all possible aspect ratios was a challenge and took longer than I’d like to admit. I was able to leverage react-photo-album again along with react-responsive-carousel and an underlying library for swipe events to build a mobile and desktop friendly instagram-esque page on our site.

Afterwards, I generalized the infinite scroll pattern with a higher order component and added search to the original blog section of the site. Search could be further abstracted to remove some duplication present in each of the components but I am happy enough with the implementation for now.

I enjoyed revisiting these old posts and exploring my data in this way. It served as a fun but admittedly odd way to reminisce about our time travelling. The recent push to finish these features also motivated me to finally open source the site and share more about the process of building it. You can check out all the code on github at kevinhughes27/kevinandsam.travel; sometimes I even wrote PRs to myself :joy:.

If you made it all the way here thank you for reading, and I hope this post has inspired you to build for yourself, for fun, or simply because you can.

TensorKart: self-driving MarioKart with TensorFlow

Tue, 03 Jan 2017 00:00:00 +0000

This winter break, I decided to try and finish a project I started a few years ago: training an artificial neural network to play MarioKart 64. It had been a few years since I’d done any serious machine learning, and I wanted to try out some of the new hotness (aka TensorFlow) I’d been hearing about. The timing was right.

Project - use TensorFlow to train an agent that can play MarioKart 64.

Goal - I wanted to make the end-to-end process easy to understand and follow, since I find this is often missing from machine learning demos.

Finally, after playing way too much MarioKart and writing an emulator plugin in C, I managed to get some decent results.

Driving a new (untrained) section of the Royal Raceway:

Driving Luigi Raceway:

Getting to this point wasn’t easy and I’d like to share my process and what I learned along the way.

Training data

To create a training dataset, I wrote a program to take screenshots of my desktop synced with input from my Xbox controller. Then I ran an N64 emulator and positioned the window in the capture area. Using this program, I recorded a dataset about what my AI would see and what the appropriate action was.

This was the only part I finished back when I started this project. It was interesting to see the difference in my own coding style and tool choices from several years ago. My urge to update this code was strong, but if it ain’t broke don’t fix it. So other than a bit of clean up, I mostly left things as they were.

Model

I started by modifying the TensorFlow tutorial for a character recognizer using the MNIST dataset. I had to change the input and output layer sizes as well as the inner layers since my images were much larger than the 28x28 characters from MNIST. This was a bit tedious and I feel like TensorFlow could have been more helpful with these changes.

Later, I switched to use Nvidia’s Autopilot developed specifically for self-driving vehicles. This also simplified my data preparation code. Instead of converting to grayscale and flattening the image to a vector manually, this model took colour images directly.

Training

To train a TensorFlow model, you have to define a function for TensorFlow to optimize. In the MNIST tutorial, this function is the sum of incorrect classifications. Nvidia’s Autopilot uses the difference between the predicted and recorded steering angle. For my project, there are several important joystick outputs. The function I used was the euclidean distance between the predicted output vector and the recorded one.

One of TensorFlow’s best features is this explicit function definition. Higher level machine learning frameworks might abstract this, but TensorFlow forces the developer to think about what is happening and helps dispel the magic around machine learning.

Training was actually the easiest part of this project. TensorFlow has great documentation and there are plenty of tutorials and source code available.

Playing

With my model trained, I was ready to let it loose on MarioKart 64. But there was still a piece missing: how was I going to transfer output from my AI to the N64 emulator? The first thing I tried was to send input events using python-uinput. This almost worked and several joystick utilities believed my program was a proper joystick, but unfortunately not mupen64plus (the N64 emulator).

By this point, I was already digging into how mupen64plus-input-sdl worked (to see why it didn’t like my fake input), so it seemed like a better idea to write my own input plugin rather than trying to hack through multiple layers with fake joystick events.

Rabbit Hole - writing a mupen64plus input plugin

I hadn’t written a proper C program in quite a while, and I was excited to give it a go. I started by doing a curated copy paste of the original input driver. My goal was to get a bare bones plugin compiled and running inside the emulator. When the plugin is loaded, the emulator checks for several function definitions and errors if any are missing. This meant my plugin needed to have several empty functions defined. I thought this was interesting and pretty different from how I’m used to connecting things.

With my plugin working, I figured out how to set the controller output. I made Mario drive donuts forever.

The next step was to ask a local server what the input should be. This required making an http request in C, which turned out to be quite the task. People complain that distributed systems are hard - and they are! - but they forget that it used to be pretty hard to distribute them in the first place. It took me a while to figure out that my http request was missing an extra newline (and was thus malformed), which caused my python server to hang and never respond since it was still waiting for the request to finish. After a few more interesting mishaps, I finally finished consuming data and outputting it to the N64 emulator internally.

My completed input plugin is available on GitHub.

Playing Revisited

Now my AI could play! The first race was pretty disappointing - Mario drove straight into the wall and made no attempt to turn :sob:.

To debug, I added a manual override, allowing me to take control from the AI when needed. I observed the output while playing and stepped through the whole system again. I came up with 2 things to fix for the next iteration:

While re-inspecting my training data, I found that the screenshot was occasionally a picture of my desktop behind the emulator window. I didn’t bother looking into why this happened since I’d been down enough rabbit holes on this project already. My solution was simply to remove these bad samples from my data and move on.
I noticed that MarioKart is a very jerky game in that you typically don’t take corners smoothly. Instead, players usually make several sharp adjustments throughout a large turn. If you think about what the agent sees at each iteration, this jerkiness could explain why Mario didn’t turn. Thanks to aliasing of the data, there would be images of Mario in the middle of a turn both with and without a joystick output indicating the turn. I suspect the model learned to never turn and that this actually resulted in the smallest error over the dataset. Training is still a dumb optimization problem and it will happily settle on this if the data leads it there.

With this in mind I played more MarioKart to record new training data. I remember thinking to myself while trying to drive perfectly, “is this how parents feel when they’re driving with their children who are almost 16?”

With those 2 adjustments I got the results you saw at the beginning of this blog post. Hooray!

Final Thoughts

TensorFlow is super cool despite being a lower level abstraction than tools I used several years ago (scikit-learn and shogun). The speed it offers (thanks to cuDNN) is worth it and their gradient descent / optimizers seem really top notch. If I was doing another deep learning project, I probably wouldn’t use TensorFlow directly; I’d try keras since doing the math for layer sizes sucks (keras is built on TensorFlow though so it’s basically syntactic sugar).

In a couple of days over winter break, I was able to to train an AI to drive a virtual vehicle using the same technique Google uses for their self-driving cars. With approximately 20 minutes of training data, my AI was able to drive the majority of the simplest course, Luigi Raceway, and generalized to at least one section of an untrained racetrack. With more data, I bet we could build a complete AI for MarioKart 64.

Source code:

github.com/kevinhughes27/TensorKart

github.com/kevinhughes27/mupen64plus-input-bot

Update / Reception

This post went viral on the internet!

It started by topping hacker news:

It did pretty good on /r/programming as well. Then it got picked up by Google News, LinkedIn and all sorts of content sites. I personally got a kick out of it when Google suggested my own article to me 😂

Tensor Kart is still doing laps of the internet to this day thanks to various twitter bots.

Building my own SaaS: Ultimate Tournament

Sun, 15 May 2016 21:25:00 +0000

Update - I shutdown and open sourced Ultimate Tournament in 2020. I learned a lot from working on this project but it was time to move on. If you’d like to read more about my final thoughts or check out the code it is available on GitHub.

For the past while I’ve been working on an ambitious side project - building a complete Software as a Service (SaaS) for creating and managing Ultimate Frisbee tournaments. I started the project leading a team at a charity hackathon and have since continued working on it all on my own. This project has pushed me to learn many new things and wear a lot of different hats in order to build an entire product I am comfortable launching.

There are a lot of moving of moving pieces in a complete SaaS product: a landing page with signup, an onboarding or setup process, analytics to help improve the product, analytics for marketing, an internal admin application for managing the app and of course there is the application itself. Ultimate Tournament actually has two main user applications: the management software for tournament directors and the mobile schedule and score reporting app for players and captains. From a technical standpoint it needs good infrastructure and reliable CI both preferrably scalable on demand.

With so much to build I learned a lot more about how to configure the frontend part of a Rails application and evolved my opinion on server side rendering vs a single page applications (it always depends!). In order to achieve some of my user interface ideas I ended up learning and adopting React. I also built out an entire authentication stack which included social logins, an internal area and the ability for staff to login to tournaments to help troubleshoot.

Drag and Drop schedule editor

Tournament logistics are tricky! I under estimated the complexity of this logic on the backend - Brackets especially are a pretty non-trivial graph structure which is quite different from the data I’ve been working with lately so it was a learning experience.

Visualizing the bracket graphs

This project really helped me appreciate everything that goes into a SaaS product and helped me better understand all the things that happen around me at work. There is a lot more technical work I still want to do on this project like adding ActionCable for websockets and expanding it to other sports. I’ll probably build out an API soon as well.

Now I’m trying my hand at marketing to get the word out so people use my app. If you happen to need tournament software or know someone who does please check it out! ultimate-tournament.io

2015 a Year in Review

Fri, 01 Jan 2016 00:00:00 +0000

2015 was a pretty awesome year full of new experiences, growth and accomplishments. It marked my second year of working in software professionally and school seems like a faint memory at this point. Shopify, the company where I work, IPO’d this summer which was an exciting and [possibly] once in a lifetime experience. I think this kind of post is worth doing to reflect before simply setting our sights on the next goal. So here it is my year in review in bullet points:

Travel

Barcelona for FullStack Fest
Stockholm Sweden for Nordic.js
Paris France (for just over 24 hours but we saw a lot!)
Helsinki Finland for Junction 2015
Costa Rica for vacation
Peru for a vacation and to hike the Inca Trail!

Sports and Fitness

new PR squating at 255 lbs for 1 (although now I’m injured as I write this and my squat is low :sadface:)
ran 3k in 12:35 (mm::ss)
made a lot of improvement in mobility (I can now touch my toes!)
I discovered and became addicted to Yoga Tune Up which has really helped support my other fitness goals

Ultimate

I played my first season of competitive Ultimate with Swift
I attended 3 away tournaments with Swift in Toronto, New York and Barrie finishing our season at No Borders in Ottawa.
We didn’t win a lot of games (we were essentially the C team) but we did beat Goose when it counted!
I played in my first beach tournament ever!

Side Projects

I wrote my first text editor extension RailsRunMigration
I made a script to alert me when I spend too much time coding (the irony) coding_timer
I created some cool infographics for the OCUA Parity League
merch-my-tweet a bot who automatically creates products from your tweets
I wrote a javascript library to add a CLI to my online banking
I built my first docker image (trivial but felt cool)
I also shipped improvements to shopify-sinatra-app and completely re-wrote shopify-app as a proper rails engine

New Tech

React.js
Rails engines
npm / common js build tools
javascript testing with jasmine
capybara / browser testing
middleman
Chrome Extensions
small task automation with AppScript

Averaging That 70's Show

Tue, 22 Dec 2015 16:26:00 +0000

tl;dr I averaged every episode of That 70’s Show into a single video

A couple of weeks ago I was hanging out with my buddy and we were going to watch some TV. I was making a pitch for my new favorite show Rick & Morty which we couldn’t find using the PS3 internet browser. We did however find excellent video syncing Rick and Morty clips with Eminem’s Rap God.

One good YouTube find is never enough though so as soon as the video finished we eagerly checked the user’s other videos and thats when we stumbled upon this gem:

After watching a bit too much of ‘Every episode of Friends simultaneously’ I went looking for two things of which I found neither. Maybe I live in too much of a software bubble but I was genuinely surprised when I couldn’t find a link to the code used to make the video. I was equally surprised that this was the only video of its kind that I could find.

And thats how this project got started - I set out to create a script that would let me average all the episodes of any show into a new video. I wrote a script in python and opencv to do the work and then I picked That 70’s Show as my first test (I would have preferred Seinfeld but I don’t have it). That 70’s Show is a pretty good candidate - my main hypothesis was that shows that re-use the same locations frequently will be more interesting.

I am pretty pleased with the results! It’s pretty fun to watch and you can definitely pick out distinct patterns in how they frame shots and recognize scenes like the car from the opening credits (at ~2 minutes in). If I’d ever taken a course in film I’m sure I’d have some more intelligent things to say.

I also made this video where I ramp up to the average adding a new episode every 30 frames or around 1 second. So for the first second you’re only watching 1 episode then 2, 3 etc:

Static Blog Search with Awesomplete

Tue, 27 Oct 2015 18:49:00 +0000

This is a post about developing my blog on my blog - take a second to appreciate how meta that is.

I recently transitioned my personal site from Wordpress to a static site on Github pages built using Middleman. Overall it was an awesome change and I feel much better having my personal site and assets etc in plain text and source control. The transition was pretty smooth however there were a few things that I had with Wordpress that took a bit of finesse to achieve with Middleman. Blog search was one of those things and I eventually came up with a pretty elegant solution that I would like to share.

The reason search is interesting is because Middleman generates static sites which means any search solution needs to be entirely client side. If you google for Middleman search you’ll find some other projects and gems but I think my solution is simpler.

I built my blog search using this nice little autocomplete library called Awesomplete. To start I added the following markup to the sidebar partial which is rendered on all the blog sections of my website:

<input id="search" class="form-control" list="articleList" placeholder="Search...">
<datalist id="articleList">
  <% blog.articles.each do |article| %>
    <option><%= article.title %></option>
  <% end %>
</datalist>

This creates the base list of all my blog articles. Now we need to bring it to life with Awesomplete:

  var input = $("#search")[0];
  var awesomplete = new Awesomplete(input, {
    minChars: 1,
    maxItems: 5,
    autoFirst: true
  });

  var searchIdx = {
    <% blog.articles.each do |article| %>
      <%= article.title.to_json %>: "<%= article.url %>",
    <% end %>
  }

  window.addEventListener("awesomplete-selectcomplete", function(e) {
    var articleTitle = $(e.target).val();
    var articleUrl = searchIdx[articleTitle];
    Turbolinks.visit(articleUrl);
  });

This code does a couple of things - first it initializes the Awesomplete widget. Next it defines a searchIdx variable which just maps article title to url and stores it in javascript land so we can access it later. The last bit of code listens to the awesomplete-selectcomplete event then looks up the url for the selected article and then loads the page with Turbolinks (if you’re not familiar this is just a slicker way of doing window.location = ).

I was really happy with how this turned out, super fast, simple and the code is nicely contained in my sidebar partial. Give it a try in the search box to the right!

Some fun with D3.js

Thu, 20 Nov 2014 00:00:00 +0000

I’ve been intrigued by D3.js and the impressive visualizations I’ve seen people make for quite some time and I finally got to check it out for myself. I wanted to write this blog post sharing my experiences and revelations from the perspective of someone who at one point spent a fair amount of time with Matlab/Octave and my personal fave matplotlib.

The first major point I want to make is that D3.js is not a plotting library - it should not be compared directly to Matlab/Octave or matplotlib because they serve different purposes. D3.js is a visualization library, sure this visualization may be a graph but you shouldn’t be playing with D3.js until you already understand your data and simply want to show it off. While exploring and figuring out your data matplotlib is going to be way faster and more effective (note there are some wrappers building standard plotting functions ontop of D3.js like NVD3 if javascript is really your thing).

Once you’ve figured out your data and it’s time to show-off D3.js really shines and here is the main reason why in my opinion. It’s due to a fundamental shift in a way of thinking that makes D3.js so powerful: rather than calling plot with an array of x and y values I am binding an array of javascript objects to my plot and then telling it which attributes to use for different things. Essentially you are pulling more data into the plot and you can write code at each level - let me show you the snippet that made me realize how powerful this shift in thinking is:

var chart = d3.select(".chart");

var tip = d3.tip()
.attr('class', 'd3-tip')
.offset([-10, 0])
.html(function(d) { return "<span>" + d.text + "</span>"; });

chart.call(tip);

var bar = chart.selectAll("g")
.data(data)
.enter().append("g")
.attr("transform", function(d, i) { return "translate(" + i * barWidth + ",0)"; });

bar.append("rect")
.attr("y", function(d) { return y(d.value); })
.attr("height", function(d) { return height - y(d.value); })
.attr("width", barWidth - 1)
.on('mouseover', tip.show)
.on('mouseout', tip.hide);

The important parts to note are this: I grab the value for my y axis of the rect from d.value where d is one of the objects in my data array that I am plotting. So far this is pretty standard but look at the tip function that gets called on mouseover - it shows a span which contains d.text! I’ve attached another piece of data here called text that can be used to display more information! This was the wow moment for me because this kind of thing isn’t possible in matplotlib and showing a simple tooltip is really only the beginning of what you can do with all this added context.

Also something about plots with a :hover effect is kind of awesome!

If you haven’t played with D3 yet and have some cool data I definetly recommend it, I used it to make some pretty sweet visualizations/tools for our Parity Ultimate Frisbee League here in Ottawa, check’em out:

https://github.com/kevinhughes27/ocua-parity-league

Building my first Shopify App

Tue, 09 Sep 2014 00:00:00 +0000

A few weeks ago in my first quarterly hackathon at Shopify I joined a team that was building a Shopify App to help charities issue donation receipts for orders on their store. We got pretty far during the hackathon and afterwards I kept working on it in my free time. It was a good way to dog food our API and tooling which was my responsibility at work.

I finally finished the app and a few days ago it launched on the Shopify App Store. The app automates the process of sending customers tax receipts for their donations to a non-profit Shopify store using webhooks. It’s a pretty cool little app and a good example of how to build a simple piece of automation using webhooks.

I knew the scope of the app was going to be small so I wanted to pick an appropriately minimalist framework instead of Rails. I went with Sinatra and ended up extracting a small gem shopify-sinatra-app for others to use. The app itself is also open source, you can check out all the code and follow the ongoing development and maintenance here.

Testing javascript with python

Sat, 01 Feb 2014 00:00:00 +0000

I was recently tasked with adding Mailcheck.js to some of our production pages and I want to describe a bit of the process I went through because I did some things a bit differently and had some fun along the way.

Lets start with a PSA - do not simply drop Mailcheck onto your website as is! In my opinion / findings the default algorithm is way too greedy - aka it will mostly suggest all emails should be ____@gmail.com. It is worth taking the time to tweak mailcheck for your particular userbase, on one wants to see a correction for their proper email address!

The first thing I did was dumped a ton of emails from our database to create a dataset to work with. I could have used Node to write some scripts to test out the Mailcheck behaviour but Python is just so much more convient for doing numerical analysis. Plus it’s what our data team uses so I could leverage some of their knowledge and code. So now for the fun part - I ended up using PyV8 (a python wrapper for calling out to Google’s V8 javascript engine). With this setup I was able to slice and dice through our production emails using python and pandas calling the exact javascript mailcheck algorithm and collecting my results. After tweaking the algorithm I could take the settings and new js code and put it in production.

Check out this wacky franken script that got the job done (pandas not included):

import PyV8

def init_mailcheck():
  global ctxt
  ctxt = PyV8.JSContext()
  ctxt.enter()
  ctxt.eval(open("mailcheck.js").read())


def run_sift3Distance(s1,s2):
  script = "Mailcheck.mailcheck.sift3Distance('%s','%s')" %(s1,s2)
  return ctxt.eval(script)


def run_splitEmail(email):
  script = "Mailcheck.mailcheck.splitEmail('%s')" %(email)
  return ctxt.eval(script)


def run_mailcheck(email):
  script = """ Mailcheck.mailcheck.run({
         email: "%s",
       })
   """ % (email)
  result =  ctxt.eval(script)
  if result:
    try:
      result = result.address + '@' + result.domain
    except(AttributeError):
       pass

  return result

if __name__=="__main__":
  init_mailcheck()
  print run_mailcheck("kevinhughes27@gmil.com")
  # >>> @kevinhughes27@gmail.com

A python library for Incremental PCA (pyIPCA)

Sat, 11 Jan 2014 00:00:00 +0000

I extracted some of the useful code and nifty examples from the background of my Thesis as a python library for your enjoyment. PCA or Principal Component Analysis is a pretty common data analysis technique, incremental PCA lets you perform the same type of analysis but uses the input data one sample at a time rather than all at once.

The code fully conforms to the scikit-learn api and you should be able to easily use it anywhere you are currently using one of the sklearn.decomposition classes. In fact this library is sort of on the waiting list for sklearn.

IPCA on 2D point cloud shaped like an ellipse

Check it out if you’re interested and holla at sklearn if you want this feature! github.com/kevinhughes27/pyIPCA