Fixed typos

docs/future_work.rst

@@ -13,13 +13,13 @@ used during the course of that run. This is inefficient.
 
 A better way to handle this situation is by implementing Abstract Base Classes
 (ABCs), which will be done to improve the quality of the program. The goal is
-to redifine Mutator, Crossover, and Selector classes as ABCs which contain
+to redefine Mutator, Crossover, and Selector classes as ABCs which contain
 some *run* method. Note that the *run* method will not be defined in the ABC
 itself. The current methods for Mutator, Crossover, and Selector will then
 be defined as subclasses of its corresponding ABC. For example, the gaussian
 Mutator method will now become a subclass of the ABC Mutator. Gaussian
 subclass will contain a *run* method which performs the gaussian mutation. Now
-a Gaussian Mutator object can get instatiated instead of a Mutator object as
+a Gaussian Mutator object can get instantiated instead of a Mutator object as
 a whole which contains unnecessary information from the program's point of
 view.
 
@@ -31,5 +31,5 @@ several ways to modify this routine to make it work with the ABC implementation.
 One method is to create a function that takes as input the user's choice for
 mutation, crossover, and selection. The function then instantiates the correct
 objects and returns 3 objects: a specific type of Mutator, a specific type
-of Crossover, and a specfic type of Selector. When a mutation needs to be done,
-the *run* method of the instatiated Mutator object can now be directly called.
+of Crossover, and a specific type of Selector. When a mutation needs to be done,
+the *run* method of the instantiated Mutator object can now be directly called.

docs/lessons_learned.rst

@@ -4,8 +4,8 @@ Lessons Learned
 
 Through this project, we learned numerous invaluable lessons which have ultimately
 made us better programmers. We spent a lot of time up front to think through the
-project as a group before starting to to write any code. During these meetings,
-we designed the interface of our program, organized the class heirarchy, outlined
+project as a group before starting to write any code. During these meetings,
+we designed the interface of our program, organized the class hierarchy, outlined
 the code structure, and divided up the work between the group members. These
 initial design meetings helped us to be organized and avoided merge conflicts.
 
@@ -18,11 +18,11 @@ in other projects outside of this course.
 
 Coding specific lessons to improve the performance of the program were also
 learned. By making mistakes, we learned that vectorization and logical
-indexing area almost always a more efficient alternative as opposed to
+indexing are almost always a more efficient alternative as opposed to
 *for* loops and *if* statements. Furthermore, although we've learned about
 profiling tools and techniques, this project gave us an opportunity to apply
 that knowledge to something substantial. When profiling, it is important to
 begin with the highest level of software architecture. After identifying
-hotspots (i.e. functions where the code spents most of the time), it is
+hotspots (i.e. functions where the code spent most of the time), it is
 important to check which lines in the function call require the most time.
 In this way, the bottleneck can be easily found and fixed.