Robby lives in a 10x10 board that is riddled with cans. Robby can either move in any of the cardinal directions, stay put, pick up a can, or move randomly. If Robby picks up a can, he gets 10 points. If he crashes into a wall, he loses 5 points and if he tries to mistakenly pick up a can, he loses 1 point. In class, we talked about genetic algorithms, these are algorithms derived from organic sources.

In the case of Robby, I programmed a method that mimics DNA replication-- this is a widely known algorithm. Each individual path Robby takes can be considered as a chromosome. If we initially start with random paths, Robby will obviously perform poorly. However, if we take his two best trials and splice them together (randomly), we can improve his score over the course of many iterations. The straight-forward way to implement a robot on a board is with recursion.

Using recursion, the naive method looks at the current square. If there is a can, Robby picks it up and he gets 10 points. Then Robby looks around him, moving to the first square Robby sees a can (in the order: left, right, up, down). If Robby does not see any cans, he moves randomly. I tested this method by running Robby on 1000 randomly generated 10-by-10 boards.

Using a genetic approach, Robby's path is first randomly generated as a string of 243 characters (if Robby can see 5 places-- N, W, S, E, and the current square, and there are three possible configurations in each square-- wall, can, no can, then the total combination is 3^5 or 243). Each set of strings comprises a single generation. Each generation was defined in my code as having 200 members. Each string (which can be thought of as chromosomes) is then run with a 'fitness' algorithm to determine how well it performs; the higher the better. The top 2 performing chromosomes are used to 'breed' the next generation. To create the children, a random number between 0 and 243 is chosen which represents the character at which we splice the two parents together. Much like in organic DNA replication, a small chance of mutation occurs. At each character, I specified a 1-in-200 chance of random mutation. Each child is then run for fitness and the pattern repeats itself until we hit the specified number of generations, arbitrarily specified as 1000. In order to minimize the chance that Robby is learning a single board, the fitness for each chromosome is calculated as the average score over 50 randomly generated boards, all starting at (5,5).

(Left) Shows a sample board in which the star is Robby. Roughly half of the positions on the board are occupied by cans in my code. (Right) Shows the results for the genetic algorithm. The maximum fitness score was plotted for each generation. Early generations yield poor results, suggesting poor optimization on any given board-- this is expected however, due to randomly initialized paths. As each generation passes, subsequent optimization improves to a maximum ~260 points. This data was collected using 1000 generations of 200 members. In contrast, the naive (recursive) method reports an average score of ~14 over the course of 1000 boards. You can view the code here on my github.

Secret Spot (Formerly named Forage App) is an application developed by me and two other students at Portland State University. The application was developed as a method for people to organize their foraging locations -- think mushrooms, berries, etc. Users can create new location markers specified by a name, species found, additional comments, and a latitude/longitude. Centering on a stored location also displays the local weather forecast to allow planning for foraging trips. APIs used include Google Map API and OpenWeather.

The idea of the point calculator was to serve as a simple tool for evaluating resident costs at a Portland based resident care facility. The point calculator was developed in Visual Studio 2019 in C++. Users could check services which had an associated point and cost, with running totals displayed on the bottom right. Users would have the added option to print a physical copy.

This application was developed as part of a course at PSU, created with Android Studio in Java. It is designed to be phone call logging app which allows users to (1) create phone bills, (2) add calls to existing phone bills, and (3) search for calls. Some notable features of the app are logic checks for user-entered dates (eg. ensuring that the end time is indeed after the start time) and persistence-- the app's data is preserved even when interruptions occur. My focus was on utility and not on the aesthetics. However, making the app look nice could be done simply with Android Studio.

During my time at OSU, I studied and briefly conducted research on thermoelectric (TE) materials. TE modules are always sold in pairs of semiconductors. If we apply heat (and a heatsink to dissapate the heat) to one side and keep the other side cool, we can actually observe a voltage. Whats more is that the reverse can also be manipulated-- if we apply a voltage to the TE module, we can draw heat away from one side. These effects are named the Seebeck and Peltier effects, respectively. I bought a knockoff Arduino Uno that I'm trying to set up with a TMP36 temperature sensor and a thermoelectric module. The goal here is to create a small functioning fridge.

Today is 6/9/2020 and I'm waiting on the packages to arrive. Stay tuned for more updates.

Today is 6/20. Summer courses start in 2 days, which doesn't give me enough time to order the TE module then install and test. So I am putting this onto the backlog. However, the temperature sensor arrived on 6/16. I assembled the device such that if the temperature sensor detects a temperature above 25C, an attached LED goes off. We could switch out the LED with any load (including a TE module). This is where the project will stand for a while.

This is a class project for CS300 at Portland State University. The basic idea is that we followed the Agile design process to produce a functional chat application. I designed the app to work locally with Google Firebase, written in Javascript. The free period has ended so the project is defunct. It features e-mail authentication and uses the Firebase real-time database to store messages. The user can chat and create/destroy chat rooms. See more here

I developed this website following multiple YouTube videos and various tutorials. I found the most informative resource to be the MDN website. It was a lot of fun to learn HTML, CSS, and JS from scratch. I hope to continue learning JavaScript in order to add functionality and make my website design more efficient.

I recieved a Raspberry Pi 3.5 as a gift and decided to use it to block known ad domains at the router level by DNS filtering. For anybody unfamiliar, the Raspberry Pi is a microcomputer (5.5" x 5.2" x 2"), virtually identical to any Linux based machine but is limited by underpowered hardware and possible thermal complications. For the curious, you can read about the Raspberry Pi on the company website. We can mimic an embedded system by having the computer run code upon startup.

I followed a tutorial that guided me through the process. This project helped me learn and understand how DNS filtering works. Most resources liken the DNS to a phone book or directory. If a known ad-domain tries to dial in, we can reject communication. This is essentially caller-id blocking between computers. The functional piece of the ad-blocker is Pi-hole, software originally developed by Jacob Salmela. This takes care of DNS filtering for us.

Individual websites handle display after the ad is blocked. On Bloomberg.com, the space is removed entirely. On other sites, a patch of blank space remains. You can see the difference with DNS filtering below:

Uno was one of the earliest programming assignments I had ever worked on. Although it may not be so glamorous, I thought including it here would be a cool way to show how far I've come. This was an assignment for class to demonstrate object oriented programming. The hardest part of writing this program was coming up with functions for each object. At the start, this seemed like such an open-ended question. I overcame this barrier by listing out the way these types of objects should work in real life. For example, we can deal a deck of cards, so the 'deck' object should be able to deal to each player. Mapping out the interactions between each object via UML diagram made creating the program much easier. int player::add_card(card *to_add){ /*This adds a card to the player's hand. Takes in one argument, a card from a deck*/ if(!hand) { hand = to_add; hand->next_null(); return 1; } else { to_add->set_next(*hand); hand = to_add; return 2; } }

In the snippet of code (right), each player of the "player" class has this function which adds a card to their hand. One card-object pointer is passed and the card is stored into the player's linked list. Since the number of cards in a players hand will never exceed the size of the deck (< 100), a linked list is an acceptable container. One of the requirements of this assignment was to use virtual functions. Since each card type has a defined ability (wild +4, wild, reverse, etc.), the card types were split into different classes with information stored in the base class. Using a virtual function, the card class would determine which ASCII art function would be invoked.

This research was conducted under the Subramanian group at OSU. I am proud of my efforts in these projects but understand that to most people, it is useless and boring. I will refrain from writing yet another chunk of text but I invite you to read my work.