Course:CPSC312-2016-Project1-TeamBuilderPro

Authors

Austin Rothwell, Torin O'Regan-Latarius

What is the problem?

When joining a fantasy hockey pool, the hardest task is choosing appropriate players for your fantasy team. There are many different statistics that you can use to select players, including goals, assists, games played, penalty minutes and many more. Instead of spending hours sifting through hockey data to find players with the best statistics, how about just letting a computer do it for you?

Our program will allow users build a fantasy hockey team with ease. To create a custom team, users simply have to run the program and specify the parameters that they think are important for their fantasy team. For example, perhaps a user values goals, hits and low penalty minutes when building a fantasy team. Our program will search through NHL data to build the best team to suit your needs.

What is the something extra?

While it would be simple to sort through players to find the one with most goals, our program will allow for team building with multiple complex parameters that will all be taken into account when creating the team. In addition, users will be able to weigh each specified parameter to ensure the team is built to the user’s exact specification.

What did we learn from doing this?

Overall, we thought that logic programming wasn't the best way to solve our problem. Building an optimized hockey pool team from a data table involves searching for and comparing players and values. Writing searching code like this with Prolog meant that any kind of conditional had to be handled by writing a whole other predicate for every condition, whereas in other programming languages, you can use IF statements. Specifically, in our functions that searched for the player with the most of some trait, we had multiple outcomes that had to be handled by separate functions, leading to dense and repetitive code. Also, the lack of a return statement makes it confusing to order and keep track of all the arguments in the head of the predicates. For example, some of our predicates had over 10 parameters, many of which were not utilized in the function, but simply passed on to helper functions. Keeping track of these parameters throughout our program became difficult.

However, there are some aspects of Prolog that are beneficial. The very clear and obvious logic of prolog made it easy to understand, build, and debug recursive functions. In addition, if we had somehow found a way to store all the csv data as triples, it may have been more time efficient to use Prolog as we would have just had to look up the triple to get data for some player as opposed to searching through the whole list of a player's values multiple times.