For the chat, a standalone page was implemented using the socket.io library along with three tables in DynamoDB (Users, Friends, and Chat). In order to have both readability as well as uniqueness for each of the chats, there is both a name (sort key) and a uniqueID (partition key). The name is set by the user at creation time through a popup and the id is automatically generated in the format of: ‘username’ + ‘unix epoch time’. Moving on to the specific tables that were used, the User Tab maintained two lists that were changed with UpdateItem’s ‘list_append’ method as a user either join a chat or is invited to a chat: ChatInvitations and Chats (both of which stored the chatID). The Friends chat is used when inviting others (in conjunction with the User tab to see who is online), as a way to quickly query the friends of any given user. The Chat table maintained the id, name, and a list of JSON stringified messages, each of which held the sender, timestamp, and actual message. The Chat table is sent a message each time the ‘send button’ is clicked, but is only queried when a given user enters the chat because all other messages between users while online are done through socket.io. Creating a chat is done through buttons on either the toolbar or side page of home.ejs. The side page also maintains all current chats and invitations that a user has available to them. 

For the search functionality pertaining to news, an Article Index table is used in order to query for articles based on a particular key word. The results from those would then get sorted based on the number of keywords they matched by storing the articles in a map with the article item as the key and the number of matched terms as the value. The map was built into a sorted array. Then, there is a lookup for all the recs for a given user and there is storage for all of the article recs that have a weight. These weights are then scaled and the list of articles is sent back to the front end for display. An AJAX call is used to give a user’s article recommendations daily. This is done by first obtaining the user’s recommendations, and then cross-referencing these with articles that the user has already been recommended. This involves an Article Recommendations Table and a Given Recommendations table that both have username as a partition key and a list of article IDs as a sort key. Once the most recommended article that is not in a user’s given recommendations is retrieved, then the site will update the current user’s list in the Given Recommendations table or make a new item for them if nonexistent. This recommendation then is sent back to the page and displayed on the front end. Additionally, inside the function call there is a check at the beginning that determines whether an hour has elapsed before making a command line call to run the adsorption algorithm.

When a user creates an account, they must fill out all of the provided fields (and they get an alert if they try to submit without doing so). This includes selecting at least two topics they are interested in. A hashed version of the user’s password gets stored in the “users” table; when the user logs in, the hashed version of the input is compared to the version in the table associated with that username. Once logging in, the user’s username is stored as a session variable. If the user attempts to visit a different page without being logged in, they will be redirected to the login page.

On the home page, the logged-in user can see their incoming friend requests, new friends, current chats and chat invitations, and a feed of articles and user-created posts sorted by time. Posts, likes, and comments are all dynamically updated every thirty seconds; if another user were to create a post, comment on a post, or like a post, then the feed would update accordingly. Comments that are displayed also feature the commenter’s profile picture. Retrieving the posts requires calls to multiple DynamoDB tables, including a Posts table, Comments table, Likes table, Article Likes, and Users table. Posts are kept track of with a unique post ID, users are kept track of with a unique username, and comments are kept track of with their timestamp. The home page (as well as all the other pages) is rendered with Bootstrap 5 and uses AJAX calls with JQuery to dynamically update the content. Friend requests immediately disappear once they are responded to, and if a request is accepted the new friend will show up under the New Friends section. The home page also allows the user to enter existing chats, respond to chat invitations, and create new chats.

The wall mainly relies on the “Users” and “Posts” tables in DynamoDB, as well as an S3 bucket titled “g02.posts” to store profile pictures. When rendering the “About Me” section, a call was made to the “users” table that queried based on the current session username, retrieving information like name, affiliation, email, and a list of interested topics. During this call, the user’s profile picture is also retrieved from the S3 bucket, and in the case that the user has not set one, an image of an anonymous user will be displayed in its place. If the user clicks the “Add Profile Picture” button, they can navigate their files and choose a file of size less than 70kb. If the user clicks the “Update Account Info” button, they can change their email, password, affiliation, and interested topics, where their current information (besides password) is already filled in. Changing affiliation or interests will automatically create a status update for the change. Saving changes will use an AJAX call to update that user’s information in the “users” table.

Once on their wall, the user has the option of creating a new post with/without media and to their wall or a friend’s wall. If the user chooses to post on their friend’s wall, a modal will appear with a list of their current friends, allowing them to choose one. The wall will dynamically update once a post has been added, and a call will be made that adds the post to our “posts” table.

The visualizer tool in this project is a way to see the connections of an individual beyond the strict follower/follow relationship. As seen to the right (demonstrating the connections of Main User), we are able to see a certain number of our friends friends and can visually see which of these are connected. This tool serves to show a demonstration of how I create friend recommendations (those who are more intertwined with an individuals network are more likely to be presented as a potential friend).

We create a few linear regression graphs to demonstrate the strong (positive or negative) correlations between Time vs Number of Ethereum Transactions, Number of people who own $10 million to $100 million USD worth of Etherium, and Average Fees. Note the Dates are one-hot encoded into integers, with the integer corresponding the the number day since the first date entry in our dataset (August 2016). For example, Date of 200 stands for 200 days since August 2016. The resulting graphs show that each of the graphed features are positively correlated with time elased, validating our claim about how time has a direct correlation to wealth inequality and popularity of a given cryptocurrency.

Interestingly, while the amount of weath that Bitcoin addresses with over 1M USD and over 10MUSD went up at the same rate, Ethereum accounts with over 10M USD gained got significantly more wealth than accounts with 1M USD. As a result, we can conclude that while ~1% of Bitcoin and Ethereum addresses own the majority of the wealth, there is an even smaller percentage of Ethereum accounts, those that have over 10M USD, that are significantly wealthier than everyone else.

For data modeling, we will hone in on one popular cryptocurrency among our datasets: Ethereum. This cryptocurreny has served as a well-known name for the blockchain world, so our team in this section trains a model that is able to predict the (ranged) amount of individuals with $1 million to $10 million dollars USD given feature parameters such as fees, number of daily transactions, and mean sum of USD transfered each day. By modeling the amount of individuals who have $1 million to $10 million USD of Etherium currency, we aim to represent the individuals who simulate the top 5% (in terms of wealth) in the Etherium blockchain. In this manner, when given specific parameters, our model can predict how much wealth inequity will result from those parameters. An increased amount of individuals who have $1 million to $10 million USD of Etherium currency correlates to increased wealth inequality (as currency on Etherium is being concentrated among the rich). Contrarily, a decreased amount of individuals who have $1 million to $10 million USD of Etherium currency correlates to increased wealth equality.

This project involved using convolutional neural networks in order to learn which one of the near 50 recognized street signs is mapped to a given image. Note that a typical neural network without the pooling and convoluting layers is typically reserved for non-image data and is not as helpful for unscaled data.

In order to appropriately train and test the accuracy, precision, recall, and mean squared error of the network, I split the data into 80% training and 20% testing. Furthermore, all of the provided images has a corresponding label that is given. For example, this could be titled “Stop Sign” or “Yield Sign” or “Pedestrian Crossing Sign”. The goal is to output one of these titles when we are fed any new image and I was ultimately able to get an accuracy in the mid 90%’s.

Here, I defined the creation of my convolutional neural network that contains a single sequence of Max-Pooling to Convolution operations on the data as to identify the maximum contrast between edges to recognize the shapes of Street Signs. This was ultimately able to predict (on 25 iterations) which street sign was read after seeing an image of it with an over 95% accuracy.

def construct_conv_net():
  net = gluon.nn.Sequential()
  with net.name_scope():
      net.add(gluon.nn.Conv2D(channels = 20, strides=2, activation='relu'),
              gluon.nn.MaxPool2D(pool_size=4, strides=4),
              gluon.nn.Flatten(),
              gluon.nn.Dense(len(train_dataset_dict)))
  return net

Training the convolutional neural network consisted a series of steps outlined as follows:

• Must define an accuracy metric of some sort (I used mxnet.metric for reference)
• Must train the data on the number of epochs so that the data can become more and more refined to targeting specific features, with my default number of epochs being ten
• Iterate through each of the mini batches within the training data set
• ‘Flatten’ the Channels which means feeding the red, green, and blue channels into a greyscale that can be read as a single number
• Send all information to the Graphics Processor (GPU) so that I can leverage parallel computing at a greater rate than on the CPU (note that this is a physical hardware boundary and that I use as_in_context in order to transfer the data in a single and readable format)
• Compute the models outputs and losses so that we can see the accuracy with with the model trains after each iteration of the training (needed to insure constant improvement)
• Back-propagate so that on the next iteration each of the weights on the features are better optimized

def train_cnn(net, train_loader, criterion, trainer, metric, epochs = 10):
  loss_ave = 0
  for iter in range(epochs):
    loss_s = 0
    sample_s = 0
    metric.reset()
    for mini_batch in train_loader:
      dat = mini_batch[0].
      lab = mini_batch[1]
      dat_to_send = dat.as_in_context(ctx)
      lab_to_send = lab.as_in_context(ctx)
      with autograd.record():
        model_output = net(dat_to_send)
        model_loss = criterion(model_output, lab_to_send)
        metric.update(labels = lab_to_send.as_nd_ndarray()) 
        model_loss.backward()
        trainer.step(dat_to_send.shape[0])
        loss_s += sum(model_loss.as_np_ndarray())
        sample_s += dat_to_send.shape[0]
      loss_ave = loss_s / sample_s
    final_training_accuracy = metric.get()[1]
    final_training_loss = loss_ave.asnumpy().item()
    return final_training_loss, final_training_accuracy

As described above, the purpose of this “Goal Post Detection” project is to identify which images contained a goal post so that the robot can change its current movement trajectory accordingly. Note that this was my project in the field of Machine Learning and was completed in the Winter of my Freshman Year. This project predominantly served as an introduction into the world of Computer Vision and A.I. for me and led to me taking a “Big Data” and “Computer Vision” and “Machine Learning” course later on.

The diagram to the write shows the general progression of the neural network construction. As noted, this project was completed using LuaTorch and was ultimately presented at a symposium for the donors to the program.