arcvega/beach_house

A project which aims to simulate the environment stemming from the "Beach House Theory" proposed by Matthew Colbourne

Beach House

Synopsis

The Beach House theory proposes the notion that an individual who is unable to throw an american football in a spiraling motion, has a drastically reduced probability of reproducing. Furthermore the theory is founded on the notion that, the male leader of a family structure can be though of as a great filter which dictates if an individual will be accepted or rejected from the collective. The Beach House theory was proposed by Matthew Colbourne on June 11th 2020.

Proposal Paper Abstract excerpt

In this paper we discuss the potential of the combined effects of convergent evolution, and the “great filter” (an event which precludes the continuation of individual genes that lack specific characteristics) effect on the human species, especially with relation to filial involvement in reproductive selection. We propose a primary “great filter” of filial decision, originating from the male leader of the family unit, and based on the cultural markings of adequate levels of masculinity as an indicator of survivability of potential mates for the females of breeding age within the unit. We use a statistical model to predict the amount of time necessary for this convergent evolution to entirely replace the current gene pool of potential mates with those predisposed to the cultural markings of masculinity (namely sports interest).

Running

The project uses Gradle as its dependency manager. To download the dependencies, run gradle build. This will generate a jar which can easily be run using gradlew :run.

An alternative way would be to run the project using one of the main entry points straight from an IDE. These are located at com.arcvega.simulation.config.Simulation or com.arcvega.simulation.config.SimulationWithUI.

Helpful Resources

We used IntelliJ in conjunction with gradel to build this project. You should be able to import this project into your IntelliJ IDE and just run it as specified in the section above

Resources to use MASON

• Mason Project Page
• Mason Manual PDF
• Mason Docmentation
• Official Mason Repo

Contributing

Thank you for your interest in this project! Please reference the Contributing manual for more information on how you can contribute to this project.

If you have found a bug or just want to propose ideas that you feel would improve this project, please visit the issues section

beach_house's Issues

Network linking for agents

To make the relations between between the three different agents more apparent, it may be a good idea to add a network which will help visualize the relations and connections

Normal distribution of affinity

The affinity that is assigned to the agents should be done in accordance to a normal distribution, rather than equally distributed randomness

Priority queue for blacklist

Having a priority queue may be nice since rejections caused by a Jim could make it harder for the rejected Matt to get off of Caseys blacklist, hence making rejection by Jim more influential

Simulation hyperparameters

Add the ability to tune hyperparameters such as population size for respective agents as a separate class, to prevent meddling with the Simulation class

Casey Blacklist size

Casey is not using her own definition of the blacklist size CASEY_MAXIMUM_BLACKLIST_SIZE, instead MATT_MAXIMUM_BLACKLIST_SIZE is being used which is incorrect

Potential Casey selection

Currently, Matt always picks the most attractive Casey and hence all matts will start to follow a single Casey instance, completely ignoring all other agents

The way the potential Casey is selected may need to be amended since the majority of Casey agents will remain unpaired indefinitely

Maybe the Matt should first stick to a range of Casey agents which are between his own score and the randomized standard

Generic Agent Class

There are several methods in Casey and Matt which do the exact same thing apart from the cast used, ie. Matt casts partner to Casey and Casey casts her partner to the Matt class

Most of this could probably be solved by using Javas generic type and making these methods part of the Agent baseclass to eliminate code duplication

Casey not removing edge

There appear to be cases where Casey doesn't remove the edge between herself and a coupled Matt.

This is probably happening when Casey steals a Matt, she uncouples with him but the graph edge between them is not deleted, so they are free to re-pair with other agents but they have a remnant edge connecting them

Random walk rework

The random walk by the agents is incredibly localized (they don't stray far), it may be worth reworking this to make the exploration factor more extreme

Blacklist Test cases

It may be time to come up with some test cases which can be used to evaluate the correctness of the blacklist since doing this manually is rather strenuous and ineffective

Repulsive force while escaping Jim

It may be nice to introduce a repulsive force that acts on the pair when they escape Jim, so that they don't run towards him as can be the case when using a random walk

Swap chasing behavior for Matt and Casey

Matt should be the one chasing Casey, which is not the case