Updated README.md

README.md

@@ -21,6 +21,7 @@ by your model.
 
 ## Available Solvers
 
+- [simplex](https://github.com/MatProGo-dev/simplex)
 - [Gurobi](https://github.com/MatProGo-dev/Gurobi.go)
 
 ## Modeling the Mathematical Program Above
@@ -66,19 +67,11 @@ p1.Objective = *problem.NewObjective(
 
 ## FAQs
 
-> Why are the solvers not bundled into the interface?
+> Why are the solvers not bundled into `MatProInterface.go`?
 
-The solvers are separated into separate repositories to avoid compilation issues.
-A compilation issue would arise, for example, if Gurobi bindings were built into this interace,
-but your computer did not have Gurobi installed on it. The same can be said for a number of other
-solvers as well. To avoid such issues, ALL SOLVERS should be included in separate pacakages
-that implement the `solver` interface in this package.
+The solvers are not bundled into this module to avoid having a large number of dependencies. In other words, to avoid including a large number of solvers in the dependencies (e.g., Gurobi, SNOPT), we will require developers to implement those in separate modules. This should hopefully keep this module "lightweight".
 
-With this in mind, you should be able to use any solver by installing its associated
-MatProGo.dev pacakage and then calling its "Solver" object.
-
-> I feel like things can be done more efficiently in this library.
-> Why did you avoid using things like pointer receivers?
+> Why did you avoid using things like pointer receivers in your implementations?
 
 This project was written to make it easier for first-time Go contributors/users
 to easily understand. For this reason, I've avoided making some optimizations
@@ -93,8 +86,8 @@ ask if this is intentional by creating an issue.
 > Why do most functions return `error` values?
 
 There are two dominant approaches for handling errors/problems
-during numerical Go programs. One is to raise an exception/create a fatal flag which terminates the program.
-The other is to share error messages to the user using Go's build-in `error` type (or extensions of it) during
+in numerical Go programs. One is to raise an exception/create a fatal flag which terminates the program.
+The other is to share error messages to the user using Go's built-in `error` type (or extensions of it) during
 most function calls. In most cases, these error messages will be `nil` indicating
 that no error occurred, but occasionally they will contain valuable information.
 
@@ -103,6 +96,16 @@ and how to use certain functions through a direct message.
 Sometimes, the first method of error handling can point users to unintuitive/difficult to read parts of
 code. Hopefully, this is avoided using this format.
 
+> I have a question for you. How can I ask it?
+
+Feel free to create an issue (see the Issues tab above) in this repository!
+
+> I have noticed an error in the code. What should I do?
+
+You can either:
+- Create an issue describing the error and how to reproduce it (see the Issues tab above)
+- Fork the repository and create a Pull Request
+
 ## Design Philosophies
 
 * Share error information
@@ -112,17 +115,6 @@ code. Hopefully, this is avoided using this format.
 ## To-Dos
 
 * [X] Create New AddConstr methods which work for vector constraints
-* [ ] Mult
-  * [ ] General Function (in operators.go)
-* [ ] Plus
-    * [ ] General Function (in operators.go)
+* [ ] Deprecate the `optim` package
 * [ ] Introducing Optional Input for Variable Name to Var/VarVector
-* [ ] Consider renaming VarVector to VectorVar
-* [ ] Decide whether or not we really need the Coeffs() method (What is it doing?)
-* [ ] Write changes to all AtVec() methods to output both elements AND errors (so we can detect out of length calls)
-* [ ] Determine whether or not to keep the Solution and Solver() interfaces in this module. It seems like they can be solver-specific.
-* [ ] Add Check() to:
-  * [ ] Expression
-  * [ ] ScalarExpression
-  * [ ] VectorExpression interfaces
 * [ ] Add ToSymbolic() Method for ALL expressions